Gerenciando Projetos de TI

Cristiana Oliveira Perez

Analista de Sistemas pós-graduada em Gestão de Projetos pelo IETEC

Com a evolução tecnológica das últimas décadas surgiram inúmeras linguagens de programação, sistemas operacionais, bancos de dados, servidores de aplicação, infra-estrutura de rede e diversos outros componentes que devem ser levados em consideração no desenho da solução de um sistema de TI.

A maioria dos especialistas em TI acreditam que sendo um bom técnico e conhecendo todos esses componentes os riscos de erros nos sistemas a serem desenvolvidos são mínimos ou até mesmo quase inexistentes.

No entanto essas mesmas pessoas esquecem de diversos fatores que podem influenciar positivamente ou não os sistemas desenvolvidos hoje em dia, que são justamente as disciplinas apontadas no PMBOK. E é devido à essa falha já de conhecimento da maioria dos profissionais de informática que existe uma grande necessidade não só da presença e atuação do gerente de projetos, e sim da maturidade de todos esses profissionais de assumir essa necessidade.
Mas todos sabemos que falar é fácil, por isso vou citar alguns exemplos práticos onde essa necessidade torna-se mais clara.

Hoje temos a UML para documentação e especificação de sistemas, e o RUP que é um processo unificado que se baseia na própria UML. No entanto, será que só isso é suficiente para se alcançar o sucesso do seu projeto ?

Vejamos a primeira fase do RUP, que é a análise de negócios. Nesta fase são identificados os principais atores que utilizarão o sistema a ser desenvolvido, além dos requisitos de negócio. Nesse momento já é possível identificarmos os principais pacotes de sistemas a serem desenvolvidos. Do ponto de vista da análise de sistemas já teríamos percorrido um dos principais caminhos da especificação do projeto. No entanto onde poderíamos estar falhando ? Analisando o trabalho realizado até esse ponto já podemos identificar diversas falhas no processo, como segue:

-Os atores do sistema podem ser considerados todos os stakeholders do projeto ? Evidentemente que não, por exemplo: se a diretoria de uma empresa encomendou um projeto B2B para facilitar a interface com seus fornecedores, apesar de os atores serem os próprios usuários do sistema B2B, os principais stakeholders seriam os próprios diretores e sponsors do projeto. No entanto eles certamente não estarão identificados na documentação dos atores do sistema realizado pelo melhor analista de sistemas do projeto.

-E quanto aos requisitos de negócio ? Por serem os principais stakeholders do sistema, os diretores da empresa contratante deveriam participar ativamente da definição dos requisitos de negócios, uma vez que são eles que sabem o que eles querem de informação de seus fornecedores. No entanto, do ponto de vista do sistema, quem participaria ativamente dessa fase do projeto geralmente seriam os próprios fornecedores, que identificariam apenas o que eles querem que o sistema faça por eles. Vejam que a opinião dos fornecedores é extremamente importante, principalmente porque eles podem dar idéias de melhorias no sistema que o contratante nem pensou em fazer, além de serem de vital importância na definição dos requisitos de interface, pois é a partir deles que teremos uma definição da navegabilidade do sistema. Mas será que isso basta ?

-Além disso, identificando os requisitos de negócio que devem ser atendidos a pedido do contratante começamos a entrar em diversas outras questões referentes a riscos, comunicação, aquisições, custos, escopo, prazo e outras. Enfim, já temos que estar atentos para elaboração de todos esse planos. E isso faz parte do trabalho do Gerente de Projetos, e não do analista de sistemas. Essa é a grande diferença.

-Muitos especialistas da área de TI podem estar pensando que ainda não há muito o que fazer nesse momento do projeto, no entanto seguem algumas questões:

1-Já identificamos e documentamos o escopo do nosso sistema e solicitamos a aprovação de nossos sponsors ? Se não fizermos isso nesse momento, as chances que temos de começarmos a divagar sobre o sistema e acabar fugindo completamente do escopo inicial solicitado pelo cliente é infinita neste momento, pois se chegarmos lá na frente da definição sem delimitarmos nosso projeto, teremos grandes dificuldades em "cortar as pernas" do sistema após o cliente achar que receberá tudo o que foi especificado. Podemos até conseguir, mas estaremos gerando um stress totalmente desnecessário no projeto. Mais uma vez vale reforçar que essa tarefa é do gerente do projeto, e não do analista como costuma ser feito em muitas empresas do setor.

2-Baseados no escopo já delimitados, já conseguimos fornecer um horizonte de prazo e custo para nosso cliente ? Novamente, se isso não for feito nesse momento, podemos perder grandes esforços e tempo de várias pessoas para no final criarmos um "monstro" tão distante das reais expectativas de prazos e preços de nosso cliente que, no mínimo, ele vai sair correndo para nunca mais voltar.

3-E as aquisições ? Será que baseados em nosso escopo já elaborado já não podemos avisar nosso cliente de que ele precisará adquirir equipamentos novos, ou talvez uma infra-estrutura de rede mais robusta que seja capaz de suportar um sistema on-line 24 horas por dia com um centena de usuários "plugados" ao mesmo tempo ?

4-Claro que nem chegamos na comunicação que, por experiência própria como analista de sistemas, é um dos principais "furos" das especificações atuais. Afinal, com quem o novo sistema tem interface ? Quais são os sistemas impactados ? Quem são as áreas que devem estar envolvidas no processo de identificação de barreiras e/ou necessidades para absorverem as novas informações que estarão disponíveis para a empresa ? O que elas precisariam fazer para disponibilizar as informações no formato que os sponsors esperam ? É justamente nesse momento que o analista de sistemas diz: "não fui contratado para colocar as diferentes áreas da empresa em uma sala e fazer com que todas se entendam, por isso esse problema não é meu". E eu diria que ele está certo, pois isso é trabalho do gerente do projeto. É ele quem deve promover esses encontros e fazer com que todos se entendam e falem a mesma língua, caso contrário estaremos desenvolvendo um sistema que irá ficar "ilhado" no meio de vários outros e não será capaz de fornecer as informações que realmente são relevantes para o sucesso do projeto.

Diante dos fatos citados e da clara impossibilidade do analista de sistemas ser responsável por todas essas atividades por não fazer parte do seu escopo de trabalho, torna-se imprescindível a presença e atuação de um gerente de projetos que, não só assuma, mas também realize todas essas etapas e processos tão necessários para o sucesso de todo e qualquer projeto onde quer que o mesmo esteja ocorrendo.