Chegou a hora de começar o projeto e o gerente pede uma estimativa em horas. E como bons funcionários que somos, analisamos os requisitos, geramos as especificações, quebramos em partes tangíveis e calculamos cientificamente o prazo de cada item do nosso WBS (ou qualquer outro nome que você dê a isso) para então conseguir o tempo ideal.
Óbvio que depois disso você acorda, toma um banho frio e vai pro trabalho. Você provavelmente vai iniciar um projeto ainda participando da manutenção de outros sistemas paralelos, o gerente solicita um “cornograma” pra ontem.
Aliás, não temos todos os requisitos e geramos especificações que sabemos que não são reais, através de um WBS com estimativa de horas completamente furadas.
O problema com a estimativa
Mas o projeto tem que andar, alguém tem que dar o primeiro chute na bola correto? Errado.
O problema é que na maioria das vezes esse chute é contra o seu time. Gerar estimativa em horas é sempre uma tarefa difícil, que funciona muitos mais como aquela brincadeira da “batata-quente” do que com uma métrica técnica.
Todos que participam da brincadeira sabem que é tudo um jogo de faz de contas, mas temos que arranjar alguém pra passar a bomba adiante.
Principalmente em modelos waterfall, onde já vi casos do time ter até mesmo dois cronogramas: um para os clientes/supervisores (que provavelmente viaja na maionese) e outro para o time de desenvolvimento (com os diagnósticos menos utópicos). Magicamente, os dois cronogramas acabam batendo no prazo final.
Eu entendo o desespero dos gerentes de projeto, que precisam ter algum recurso tangível para medir o progresso do grupo, mas questiono seriamente a forma maquiavélica como isso é feito.
O livro The Pragmatic Programmer traz uma sessão falando sobre esse problema que é tão velho quanto o desenvolvimento de sistemas:
How Accurate is Accurate Enougth ?
To some extent, all answers are estimates. It’s just that some are more accurate than others. So the first question you have to ask yourself when someone asks you for an estimate is the context in which your answer will be taken. Do they need high accuracy, or are they looking for a ballpack figure?
– If your grandmother asks when you will arrive, she’s probably wondering whether you lunch do dinner. On the other hand, a diver trapper underwater and running out of air probably internested in an answer down to the second.
– What’s the value of π ? If you’re wondering how much edging to buy to put around a circular flower bed, then “3” is probably good enought. If you’re in school, then may be “22/7” is a good approximation. If you’re in NASA, then maybe 12 decimal places will do.
One of the interesting things about estimating is that the units you use make a diference in the interpretation of the result. If you say that something will take about 130 working days, then people will be expecting it to come in pretty close. However, if you say “Oh, about six months” then they know to look for it any time between five and seven months from now. Both numbers represent the same duration, but “130 days” probably implies a higher degree of accuracy than you feel.
Fonte: The Pragmatic Programmer
Conclusão
Trabalhar com estimativas em horas é muito mais empírico do que matemático.
Por isso acredito que os processos ágeis trazem soluções mais proveitosas para todas as partes envolvidas no processo de desenvolvimento: do cliente, que recebe prazos mais reais e o ROI mais cedo, ainda que tenhamos que pensar nos moldes de iterações, o desenvolvedores que vão trabalhar mais focadamente (tendo como tarefa principal fazer só o seu trabalho) e o gerente, que vendo ambas as partes felizes, vão poder dormir mais tranqüilos.
Por fim, deixo a sugestão de leitura do incrível artigo Agile Requirements Change Management