Como estimar um prazo para uma unidade funcional conhecendo todo o universo que gira em torno do desenvolvimento. Quando questionado sobre prazo para uma função minha cabeça sempre entra em conflito. Afinal como medir aquilo que não é mensurável. Vamos supor que eu tenha que estimar um prazo para fazer a atividade X e que eu tenha estimado cerca de 3 horas (normalmente faço isso baseado na minha experiência, não uso APF* nem UCP**). Então aos 45 minutos do segundo tempo quando eu estava terminando. Bomba, uma outra funcionalidade relacionada à minha é alterada e praticamente aniquila todo o meu trabalho. De repente as 3 horas se tornam 6 senão 8 horas e lá se foi o dia.

Então para que serve a tal da Matriz de Rastreabilidade, se não dizer o quão impactante seria uma alteração em uma funcionalidade em relação às outras, o problema é você encontrar essa tal de matriz em algum lugar dentro da empresa (eu mesmo nunca vi ou ouvi, mas já senti a sua falta). Aí eu vejo gerente de projeto solicitando alteração atrás de alteração o dia inteiro, eu só posso acreditar que ele faz isso para testar a própria sorte, talvez ele tenha lido no horóscopo dele que hoje ele deveria buscar por mudanças no ambiente de trabalho. Numa situação dessas a melhor mudança é do lado de fora do projeto.

Outro problema que afeta a estimativa, comum a projetos novos, é estimar prazo sem levar em consideração aquela arquitetura maravilhosa que provavelmente sofre de crise existencial. Aí você (vulgo programador) pede um dia para terminar uma entrega, mas no dia seguinte você diz que não fez nada por que deu pau no "Contexto de Persistência", mas que hoje você termina. No dia seguinte você vira pro gerente e fala que deu pau na "Persistência", porra meu mas você disse que resolveu isso ontem. Não "chefe" ontem era problema no contexto hoje é na persistência.

E aí o bondoso programador entra na lista negra do gerente. Você pode até achar que eles gostam de você porque só você teve a capacidade de resolver um problema tão maléfico, mas não é o que acontece. Seu foco era iniciar a tarefa X e terminá-la hoje. Se existem pendências que não foram resolvidas e vão impactar na sua entrega responda na lata que você não vai estimar nada. E ponto final. Como eu vou dizer que consigo fazer um bolo em duas horas se não tem gás, o forno às vezes não liga e o fermento não é muito bom. A culpa é minha? Será, e eu repito, será culpa tua se você estimar um prazo de entrega. Por que se você estimou um prazo significa que você conhece tudo o que esta acontecendo ao seu redor.

Por isso à vezes a melhor solução é não estimar nada. Essa resposta é melhor do que um prazo irreal. Já vi a gerência dizendo que você precisa ao menos estimar alguma coisa pra ele por lá no maldito project e enviar pro cliente. Se isso acontecer com você, e isto vai acontecer, chore. Afinal o que responder numa hora dessas.

Será que um gerente de projetos não deveria saber estimar prazo se ele é o responsável pelo projeto? Além disso os projetos já nascem com um prazo total, então podemos assumir que o prazo para desenvolvimento é todo o tempo que restar depois que forem escritos todos os artefatos necessários para iniciar a codificação e esquecer essa mania de querer estimar prazo por funcionalidade, afinal esse tipo de informação vai virar estatística. E por falar em estatística esse é um bom caminho para definir prazo, aparecem aqueles matemáticos de plantão com todos os dados que ele levantou e diz que sabe quanto tempo vai demorar para cada funcionalidade dependendo que quem for fazer. Mas ele não leva em conta que pessoas não são mensuráveis em quantidade, tem dia que ela esta de mau humor, ou desmotivada, ou pior ainda quando já brota dentro dela uma vontade de sabotar o projeto. Então estatisticamente falando essa é provavelmente outra maneira que não vai resolver este nosso problema.

Eu sou a favor de estimar prazos, contanto que seja para um pacote ou então para o sistema inteiro, mas esse lance de estimar pedacinho por pedacinho, na minha opnião é perca de tempo.

*Análise por Ponto de Função **Use Case Point