Ok, então vou prosseguir e dizer:
É impossível estimar com precisão um projeto de software de qualquer importância.
Agora, um número nada trivial de vocês vai ler essa frase e pensar que estou maluco. E talvez eu esteja. Mas alguém precisa apenas dizer o que todos sabemos ser verdade, mas não queremos admitir.
Veja, inúmeros livros foram escritos, inúmeras conferências foram realizadas, inúmeras horas de consultoria adquiridas e inúmeras postagens em blogs escritas sobre como ser melhor na estimativa de projetos de software. Entendo. Todos nós trabalhamos arduamente para dar o nosso melhor na tentativa de aplacar chefes famintos que querem saber quando um novo recurso estará pronto. Todos nós definimos prazos com base na data da conferência e não quando o software estará realmente pronto.
Mas o resultado final é que simplesmente não podemos fazer isso. Bem, podemos fazê-lo — na verdade, fazemos isso o tempo todo — mas não podemos fazê-lo bem. Em outras palavras, estamos sempre errados.
Quer dizer, continuamos gastando dinheiro, indo a seminários e lendo blogs e livros. Trazemos consultores bem pagos que agem como se soubessem do que estão falando. Mas nunca melhora. Somos péssimos nisso e continuamos pensando que podemos melhorar e que a próxima moda realmente será a bala de prata. Mas não admitimos para nós mesmos o que sabemos ser verdade: não podemos estimar projetos de software com muita confiança.
Todos nós já fizemos projetos que pensávamos que levariam um determinado tempo e depois acabaram demorando duas ou três vezes mais. Você pode ter se envolvido em um projeto que terminou na metade do tempo esperado. Mas é um projeto raro e estranho que termina dentro de uma janela estreita em torno da estimativa original real. E então, quando aplicamos a lei de Hofstadter (“Leva sempre mais tempo do que se espera, mesmo quando se leva em conta a Lei de Hofstadter”) e duplicamos a estimativa, isso também se revela errado.
Existem razões para este ser o caso. O mais proeminente, e aquele com o qual acho que a maioria das pessoas tem mais dificuldade, é que cada projeto de software é único, com sua própria longa lista de “incógnitas desconhecidas”. Você pode planejar, criar estratégias, fragmentar, dobrar, girar e mutilar um projeto por incontáveis horas de trabalho, e ainda assim não saberá as dificuldades que o aguardam para realmente escrever o código. Algumas coisas que você acha que serão desafiadoras acabarão sendo fáceis. Mas na maioria das vezes você subestimará dramaticamente o desafio que algum aspecto específico do projeto representará.
É claro que isso acontece porque o gerente de software médio sempre acreditará que o caminho percorrido será uma rodovia plana e reta, com clima agradável, até o destino. E isso simplesmente nunca é o caso. Os requisitos mudam, nunca tornando o projeto menor. As pessoas tomam tomada de força inesperada. Outros projetos ou prioridades interferem. O departamento de vendas precisa desse pequeno ajuste para fechar um negócio importante. Nada são bons ventos e mares acompanhantes do início ao fim. Sempre.
Tenho um amigo com um excelente diploma em engenharia da computação que fica muito bravo comigo quando digo isso, mas o verdadeiro problema é que o desenvolvimento de software não é uma disciplina de engenharia. Em vez disso, é um processo atolado na mudança dos desejos humanos, na interação de personalidades e dinâmicas, na mudança da compreensão do cliente e em soluções não científicas. O desenvolvimento de software é um processo criativo, não científico, e os esforços criativos não podem ser reduzidos a etapas cognoscíveis e a um sistema repetível.
Ei, entendo que isso é difícil de ouvir. As empresas – e com isso quero dizer os clientes – não querem ouvir “Bem, realmente não temos certeza de quando teremos isso para você”. Eles procurarão fornecedores que lhes dirão o que desejam ouvir, mesmo que seja uma bobagem completa. As empresas têm de ganhar dinheiro e, para isso, precisam de produzir valor mais cedo ou mais tarde. Essa demonstração do novo recurso realmente precisa acontecer naquela conferência naquela data específica.
E precisamos descobrir como aceitar e conviver com isso. Digo isto porque penso que, como indústria, temos estado numa busca de décadas pelo Santo Graal da estimativa de software, e sempre estaremos. Mas nunca vamos descobrir. Nós simplesmente não vamos. Até chegarmos a um acordo com isso, lutaremos e nos debateremos e continuaremos a dizer a nós mesmos algo que sabemos que simplesmente não é verdade.
Não tenho uma solução e duvido que exista uma solução. Aceitar isso é o primeiro passo para enfrentar um problema que simplesmente nunca irá desaparecer.
