A importância da estimativa no desenvolvimento de software é inquestionável. Mas, também, é inegável que essa é uma das atividades mais odiadas pelos desenvolvedores de software (junto com testes unitários automáticos). Basta tocar no assunto e algo de ruim acontecerá.
Alguém já passou um briefing de um projeto e junto um cheque em branco com uma carta “Não preciso saber o quanto vai custar. Podem fazer!”? Eu particularmente nunca vi isso. Do ponto de vista do projeto é fundamental que se entenda, mesmo que ainda sem muita precisão, qual será o custo geral daquele projeto.
Já olhando para o lado tático da coisa, vemos que as estimativas desempenham um papel fundamental no sucesso ou não do projeto. E vamos usar o Agile como exemplo. O Product Owner apareceu como figura fundamental na execução do projeto, certo? Ele veio suprir aquela outra reclamação que o cliente nunca sabia o que queria e sempre estava longe da equipe de desenvolvimento. Pois bem, agora ele está ali o tempo todo (ou deveria estar). Mas qual é uma das maiores funções dele no Agile? Ajudar com dúvidas sobre o entendimento do escopo e fazer com que ele se realize naquele intervalo de tempo. Do sprint ao projeto. E como ele toma as decisões? Baseado no custo de cada estória do usuário (de maneira simplificada). Mais uma vez caímos na importância das estimativas.
Agora vamos fazer uma analogia com um bolão de futebol. Uma brincadeira que fica ainda mais em evidência em época de Copa do Mundo. Qual é o objetivo? Acertar o placar do jogo. E o que usamos para tentar acertar? O nosso conhecimento do futebol e das equipes. Ah, tudo bem, alguns entram só para fazer parte da brincadeira e nada sabem sobre futebol. E a participação deles é muito importante também: geram massa crítica para que os verdadeiros “palpiteiros” tenham um benefício com a vitória, seja financeiramente ou no status, afinal, todos estão vendo o que está acontecendo. Outro ponto importante dos bolões: conforme o campeonato se desenvolve, aumenta-se o conhecimento sobre os times e as taxas de acerto aumentam. Depois de um tempo, já sabemos que um determinado time montou uma equipe bem mais entrosada do que a outra, facilitando o nosso palpite. E, finalmente, para quem já participou, vai outro argumento inegável: participar de um bolão é muito divertido.
E voltamos para o mundo das estimativas. Ora, ali também o objetivo não é “acertar o placar”? E não dependemos do conhecimento sobre o que estamos “palpitando”? E também não é inegável que o conhecimento aumenta conforme os sprints vão se passando? Tudo bem errar um pouco mais no início, onde ainda deveríamos ter um buffer no projeto para acomodar estas incertezas. Agora, já com relação ao último argumento, os bolões e os processos de estimativas não tem nada em comum: estimar é chato!
Poderíamos transformar o processo de estimativas de uma empresa em um bolão de verdade? E deixar de ser chato?
Gamificação é isto. Fazer algo que deve ser feito, mas de forma divertida.
