Este artigo tem o objetivo de mostrar a você, leitor, o caminho para obter sucesso em seus projetos. "Lá vem mais uma série de modismos ou passo-a-passo prontos que nunca dão certo na minha realidade!". Não, não é isso que você está pensando. Não vou passar "receita" ou "fórmula mágica"; vou passar um conhecimento, uma atitude! Se o conhecimento apresentado aqui nortear suas atitudes e decisões em projetos, suas chances de ser bem sucedido serão muito maiores. Você vai se surpreender. Vamos iniciar a viagem?
Vamos iniciar essa série de artigos com a seguinte questão: por que os projetos fracassam? Por que não atendo ao que o meu cliente deseja? Falando especificamente dos projetos de software, vocês podem responder: "os projetos fracassam porque os prazos estouram, ou seja, o projeto é entregue dias ou meses depois do previsto"; ou ainda "porque foi prometido que ia ser entregue um sistema com diversas funcionalidades e no final foi entregue um produto sem ter o que o usuário necessitava ou algumas não funcionavam adequadamente"; ou até mesmo "eu havia previsto gastar Y e gastei Y x 4".
Nesses 5 anos de estudos e vivência nessa ciência inexata (gerenciar projetos e conduzir pessoas) e diante dos diversos motivos que poderíamos elencar que fazem com que os projetos fracassem, aponto que, na minha leitura, a fronteira entre o sucesso e o fracasso de um projeto pode ser resumido em uma única palavra: EXPECTATIVA.
Você deve estar pensando: "esse cara está maluco! Eu aqui estudando como fazer um bom cronograma, como definir estimativas de tempo adequadas, como estimar o custo correto do produto, a qualidade, os recursos humanos envolvidos, entre outras áreas, e você vem me dizer que um projeto que satisfaz o cliente é aquele que eu administro bem as expectativas?! Está de brincadeira...". Pois é! Vejamos: se pararmos para analisar as causas dos insucessos relatados em projetos e outras que existirem, todas elas convergem para a seguinte afirmação: os projetos fracassam quando alguma expectativa do cliente foi frustrada! Concorda? Se ainda não concordou, não se preocupe. Ainda temos um longo caminho pela frente e espero conseguir fazer você pensar melhor nisso?
Daí vem uma outra questão: mas como atender as expectativas dos clientes, considerando que existem diversas variáveis envolvidas (tempo, custo, pessoas, qualidade, escopo, etc.)? Se observarmos, o que todo cliente deseja é um sistema com todas as funcionalidades que ele necessita (escopo), que seja feito e entregue o mais rápido possível (tempo) e no preço mais baixo (custo). Isso é impossível, não acha?
Isso mesmo. Isso não é possível! Como tudo em informática, se eu quiser ter esse benefício de um lado, vou perder de outro. Por exemplo, se eu quiser ter mais desempenho nessa aplicação, vou perder em segurança e vou ter um custo maior. Se eu quiser ter mais segurança, vou perder em desempenho.
Assim como na informática, as variaveis TEMPO, CUSTO e ESCOPO no gerenciamento de projetos sao conflitantes! O que isso quer dizer? Isso significa que, se optarmos por uma, teremos que abrir mão de outra. Isso é chamado de trade-off. Daí, somos apresentados ao conceito denominado "restrição tripla"*.

* Gostaria de deixar claro que, alguns autores citam cinco restrições, ao invés de três: escopo, tempo, custo, qualidade e satisfação do cliente.
Nosso objetivo será detalhar um pouco mais o que é gerenciar essa tripla restrição. E nesse gerenciamento é onde entra a nossa famosa palavrinha: expectativas.
Quando iniciamos o planejamento de um projeto de software, a partir de um entendimento do problema com o cliente, definimos a solução informatizada que irá atender as necessidades dele. Ao ter essa visão macro das funcionalidades que o produto final deverá conter (nesse caso, o sistema de informação), temos o escopo desse projeto. Após essa fase, partimos para a definição dos recursos humanos (e materiais) necessários para o desenvolvimento desse produto definido. Após conhecer o número de pessoas que serão alocadas, estruturamos o escopo numa sequência de atividades e, para cada uma delas, definimos os responsáveis e a estimativa de tempo necessária para execução. Depois de ter definido isso para todas as atividades do projeto, teremos a nossa primeira versão do cronograma do projeto. Nesse cronograma, visualizamos as atividades que serão necessárias para construir o produto, os recursos que serão responsáveis pela execução de cada uma delas e o tempo que foi estimado para essa execução. Portanto, nesse ponto temos o ESCOPO (atividades), o CUSTO (valor dos recursos humanos e materiais a ser utilizado no período do projeto) e o TEMPO (a data inicial e final do projeto).
Vamos a um exemplo prático:
Um cliente necessita administrar melhor seus projetos e contrata uma empresa de software para desenvolver uma ferramenta para automatizar o controle dos projetos.Após a reunião de definição de escopo e a elaboração do cronograma, temos o seguinte cenário:
Escopo do Produto:
Recursos a serem alocados nesse projeto (stakeholders principais):
VT - Cliente/SponsorAB - Gerente de Projeto / Analista
TA - Arquiteto / DesenvolvedorCusto Inicial do Projeto: R$ 43.680,00
Duração Total do Projeto: 60 dias (início: 02/06/2008 e término: 22/08/2008)Cronograma do projeto:
EAP (WBS) do Projeto:
EVA* do Projeto:

* esse gráfico é gerado com o número de atividades a serem concluídas em cada período de tempo do projeto (nesse exemplo, período mensal).
Após esse planejamento inicial do projeto, temos o escopo do projeto definido acima, o custo do projeto (considerando os recursos alocados) e o tempo (o prazo estimado para conclusão do projeto). Nesse ponto, temos as nossas três variáveis definidas com esses parâmetros iniciais e formamos a primeira EXPECTATIVA do nosso Cliente! Observem o que o cliente falou após esse planejamento: "Que ótimo! A partir do dia 25/08 (primeiro dia útil após a conclusão desse projeto), já iniciaremos a utilização do novo sistema! Já vou mobilizar a equipe e prepará-los para essa nova forma de trabalho nessa data com o novo sistema! Também vou gastar esse valor definido para esse projeto e já vou alocar a verba necessária". Fique atento a essa expectativa dele. Ela terá que ser gerenciada!
Agora, o projeto está prestes a começar a ser executado... E em projetos de software (como em qualquer outro projeto de outra área de negócio), existe uma coisa que é inevitável e temos que administrá-la: MUDANÇA! Sabemos que Murphy é cruel, ele não perdoa, e quando algo pode dar errado, tenha certeza que vai dar errado! Portanto, achar que esse planejamento inicial vai ser seguido até o final do projeto é se enganar! As coisas vão mudar: o cliente vai alterar o escopo, algum recurso vai ficar indisponível, alguma estimativa de tempo não vai ser cumprida e tarefas irão atrasar. Enfim, tudo pode mudar! Concorda que qualquer mudança dessa vai impactar diretamente na EXPECTATIVA do meu cliente?
Na próxima parte desse artigo, vamos procurar simular algumas situações reais de mudanças no projeto e qual a atitude que deveremos tomar para manter os objetivos do projeto e gerenciar as expectativas do meu cliente/sponsor para que elas sejam atendidas e o projeto seja bem sucedido.
Não percam as cenas do próximo capítulo!
Parabéns!
Gostei muito do artigo, vou estar acompanhando até o final!
Os textos publicados neste espaço são de responsabilidade única de seus autores (colunistas e leitores) e podem não expressar necessariamente a opinião do iMasters.
Alercio Bressano é Gerente de Projetos e Professor Universitário. Possui 8 anos de experiência em desenvolvimento de projetos de TI. Atualmente, é líder do PMO da área de TI de um grupo empresarial. Leciona disciplinas de Engenharia de Software. Formação acadêmica: especialista em Melhoria de Processo de Software pela UFLA-MG, MBA Executivo em Gestão Empresarial pela FGV-RJ e graduado em Processamento de Dados pela UNIT-SE. Blog: http://alercio.spaces.live.com
2001 - iMasters FFPA Informática Ltda - Todos os direitos reservados.