Porque estimativas são tão importantes?

Vejamos como cada um na equipe enxerga o tempo para se fazer este micro-projeto

Escopo
- Administração de usuário com (operações padrão + login)
- Administração de grupos (operações padrão + associação)
- Permissões (operações padrão + associação)

Estimativas
- Programador: 16h
- Analista Programador: 24h
- Analista de Sistemas: 32h
- Gerente de projetos: 40h Veja as diferenças.

Quando apresentamos as estimativas à cada um deles as explicações foram:
- Programador: “Realmente, esqueci que tem o levantamento, especificação, validação, etc”
- Analista programador: “Tem mais algumas coisinhas pra se fazer, mas acho que mais uns 2 ou 4 dias resolve”
- Analista de Sistemas: “Já tá tudo lá, se tiver mais alguma coisa resolver em um dia. Coloca dois pra garantir”
- Gerente de projetos: “Acredito que esta correto, estimei com APF (análise de pontos por função)” Reparem que apenas o gerente do projeto teve segurança em sua estimativa. Os outros quando questionados mudaram suas opiniões – ah, este caso é real.

O mais comum é “duas semanas”, é incrível como tudo é resolvido em “duas semanas”. Estimar os projetos e atividades é primordial para o sucesso do projeto, pois você sempre deve saber o tamanho das coisas que irá fazer. Adicione ao tamanho o custo, esforço e prazo. Lembre-se que o “dinheiro” para se fazer o projeto não é seu – ou melhor – cuide dele como se fosse seu pois assim você irá zelar por ele e aproveita-lo da melhor forma.

Existem diversas técnicas para dimensionamento de projetos de software como Análise de Pontos por Função, Use Case Point, COCOMO e outras, não importa qual você use, apenas use uma. Selecione uma técnica e faça com que todos na organização saibam usa-la – o conhecimento deve permanecer na empresa e não na cabeça das pessoas.

Uma técnica que recomendo é a Análise de Pontos por Função. Utilizo ela a mais de 10 anos e os resultados até hoje tem sido excelentes. Até acontecem alguns desvios nas estimativas mas eles ficam dentro da variação prevista. Hoje temos certeza de que nossas estimativas refletem a realidade.

Em tempo: A técnica de APF é um modelo de desempenho de alta maturidade – lembre-se disso quando estiver indo para o CMMI nível 4.

* operações padrão: tela, inclusão, exclusão, alteração e consulta

No related posts.

Pesquisas apontam que pelo menos metade dos fracassos em projetos de TI vem da falta de gerenciamento de escopo.

Simplificando, o escopo do projeto, nada mais é do que o que foi combinado fazer.

Vamos à uma analogia: Preciso trocar os pneus do meu carro. Faço um levantamento dos produtos e serviços necessários e verifico que precisarei de:
- Quatro pneus [Produto]
- Troca dos mesmos [Serviço]
- Alinhamento [Serviço]
- Balanceamento [Serviço]

Bom, este é o escopo deste meu projeto “Trocar Pneu” e devo fazer uma gestão efetiva deste escopo, para não gastar mais que o previsto.

Vou na loja, faço o pedido e aguardo. Após meia hora o vendedor (que obviamente quer vender) me fala que seria bom eu trocar os amortecedores também porque estão ruins. Vamos parar um pouco neste ponto.

Trocar os amortecedores tem custo e o vendedor vai cobrar com certeza. Esta troca esta fora do meu escopo inicial e devo decidir se mudarei o escopo ou não.

Reparem que quem decide sou eu, só que esta decisão traz impacto (aumento do custo). Será que vai adiantar alguma coisa se eu chegar ao vendedor e “espernear” falando que isto estava “sub-entendido” na troca e por isso não vou pagar? Com certeza não. Eu ficaria muito feliz se ele fizesse isto de graça, mas isto não vai acontecer pois tem custo pra ele.

Voltando, decido por não trocar pois esta fora do meu escopo inicial e isto ultrapassará o valor que eu tinha previsto.

Se coloquem agora no lugar do vendedor (que é o nosso!) e simulem a mesma situação. Vocês dariam os amortecedores ao cliente?

É isto que não se pode fazer (dar algo não combinado), temos sim é que cumprir o escopo previsto em nossos projetos e sempre posicionar o cliente de possíveis necessidades de mudanças.
Mas lembrando, o escopo não muda, a não ser que alguém permita.
O Gerente do projeto deve sempre ser firme e demonstrar os impactos (esforço, custo, prazo, etc) e nunca permitir o aumento sem que o cliente concorde com os impactos (formalmente). Comunicação é primordial.

Você deve tratar os custos (estimativas em geral) dos projetos como se este dinheiro fosse sair do seu próprio bolso.

Em tempo: Alguns pontos ajudam muito a “definir o escopo” como:
- Uma proposta comercial bem elaborada;
- Deixar claro o que será feito e o que será entregue (tudo);
- Deixar claro o que não será feito;
- Deixar claro suas responsabilidades e as do seu cliente;
- Estimar com uma técnica segura sempre que possível – recomendo APF (melhora significativamente a acertividade);
- Fazer um bom planejamento e gerenciar de verdade o projeto;

Fazendo isto sempre em seus projetos, além de reduzir considerávelmente suas dores de cabeça com o projeto você também estará atendendo boa parte da parte de engenharia do CMMI

Veja também:

1. Plano de gerenciamento de projeto Constantemente quando falamos sobre o Plano de Gerenciamento de Projetos...