Estimativa de um protótipo
Como avaliar um protótipo: trata-se de um produto desenvolvido com o objetivo de aprender, não para ser utilizado. Como evitar que o protótipo se transforme no código de produção que ninguém havia planejado.
A história cujo resultado é “agora sabemos o que construir”, e não “já construímos”.
Um protótipo é concebido para o aprendizado, não para o uso. O objetivo é responder a uma pergunta — essa interação parece adequada?, essa abordagem é escalável?, essa API vai se sustentar? — com rapidez suficiente para que você possa mudar de direção antes de se comprometer com ela. Equipes que estimam protótipos da mesma forma que estimam funcionalidades chegam a um número que financia um tipo de trabalho inadequado.
O outro tipo de falha é o oposto: estimar um protótipo pequeno, lançar algo que “simplesmente funcione” o suficiente e, em seguida, levar essa versão para produção porque o cronograma já avançou. O protótipo que se torna o produto é o código mais caro da base de código, porque ninguém planejou as partes que não estão lá.
O que se fala na sala
Engenheiro: “Posso montar algo em alguns dias.”
Introdução: “Qual é a pergunta que estamos tentando responder?”
PM: “Isso vai ser divulgado aos clientes ou é apenas para uso interno?”
Líder: “Se a resposta for sim, jogamos fora e recomeçamos do zero?”
Engenheiro: “Nunca jogamos isso fora.”
Perguntas que vale a pena fazer antes de votar
- A que pergunta o protótipo está respondendo, e como saberemos que temos uma resposta?
- Apenas para uso interno ou na presença dos clientes?
- Descartável por padrão — e a equipe está comprometida com isso?
- Qual é o prazo, e o que acontece quando ele terminar?
- Se funcionar, qual é o caminho do protótipo até o código de produção?
A mentalidade do engenheiro de que “nunca jogamos nada fora” é o verdadeiro risco: reserve um orçamento para o protótipo da solução e trate a versão de produção como um projeto à parte, para que a ideia de “descartar” não seja adotada por padrão.
Defina o tamanho de um protótipo com base na resposta, não no produto final — e planeje a reformulação antes que o cronograma o faça por você.
Assim como estimar um pico de pesquisa, o resultado esperado é o conhecimento; trate-os da mesma forma. Consulte erros comuns no Planning Poker sobre a investigação se infiltrando na história e os outros exemplos práticos de estimativa.