Estimativa de desenvolvimento de software: como ler o número
Seu desenvolvedor mandou um número de volta. Estas são as quatro perguntas que o transformam de novo no intervalo que ele realmente é.
O e-mail tinha quatro linhas. Um cumprimento, um obrigado pela call, e então o número: 12 semanas, R$ 900 mil. O founder encaminhou para a gente com uma pergunta em cima. “Isso está bom?”
Estimativa de desenvolvimento de software é a prática de prever quanto tempo e quanto dinheiro vai custar construir um software. Só que o que chega na sua caixa de entrada não é uma previsão. É um intervalo que alguém achatou em um número único, porque um número único foi o que você pediu. Tudo que interessa está no intervalo que jogaram fora.
O founder em questão, ex-diretor de operações de um hospital construindo um produto de agendamento para clínicas particulares, não sabia ler aquele número. A maioria das pessoas com quem trabalhamos também não sabe, e isso não é falta de inteligência. É que todo guia já escrito sobre estimativa de desenvolvimento de software foi escrito para quem produz a estimativa. Pesquise o termo e você vai achar nove artigos ensinando engenheiro a dimensionar tarefa e nenhum ensinando um CEO quais perguntas deixam o número honesto.
Este é o outro tipo de artigo.
O que uma estimativa de software realmente é
Três coisas diferentes são chamadas de “estimativa”, e confundir as três é onde a maior parte do dinheiro morre.
Tem o chute, dado numa call por alguém que conhece o seu problema há quarenta minutos. Tem o orçamento, produzido depois que um time leu os seus requisitos e brigou por causa deles. E tem a promessa, o número que o fornecedor vai ser cobrado e, portanto, vai defender em toda conversa que vocês tiverem nos próximos seis meses.
Chegam na mesma fonte. Significam coisas completamente diferentes.
Embaixo dos três está a mesma máquina: alguém quebra o trabalho em pedaços, dimensiona cada pedaço e soma. O dimensionamento pode ser em dias, em story points, em tamanhos de camiseta. A unidade importa pouco para você. O que importa é que cada um daqueles pedaços foi dimensionado sob incerteza, e a incerteza não sobreviveu à soma.
Por que a estimativa de desenvolvimento de software sempre produz um intervalo, e por que o intervalo fica escondido
Steve McConnell passou uma carreira medindo o quanto estimativas de software erram, e o resultado tem nome: o Cone da Incerteza. No início de um projeto, no ponto em que já existe um conceito acordado mas nenhum detalhe decidido, estimativas feitas por estimadores experientes podem errar por um fator de quatro para cima e por um fator de quatro para baixo. É uma diferença de dezesseis vezes entre a ponta pessimista e a otimista. Não porque o estimador é ruim. Porque o projeto ainda não foi decidido.
O cone estreita conforme o projeto anda, e a maior parte desse estreitamento acontece nos primeiros 20% a 30% do calendário. Mas aqui está a parte que founder erra com consistência: ele não estreita porque o time se esforçou mais. Ele estreita porque decisões foram tomadas. A variabilidade da estimativa é reflexo direto da variabilidade do projeto. Nas palavras de McConnell, “não é possível ser mais preciso; só é possível ter mais sorte.”
O que produz a frase mais útil deste texto:
Você não consegue negociar uma estimativa para baixo. Você só consegue decidir menos coisas para ela ficar incerta a respeito.
Todo founder que já empurrou um orçamento sentiu o fornecedor “apontar o lápis” e voltar 15% mais barato. Nada foi aprendido nesse intervalo. Nenhuma decisão foi tomada. A incerteza não foi para lugar nenhum. Ela só foi realocada, em silêncio, da margem do fornecedor para a sua data de lançamento.
Quais são os quatro tipos de estimativa?
A maioria dos artigos vai classificar estimativas por técnica: análoga, paramétrica, three-point, bottom-up. Essa taxonomia é para quem estima. A que serve para você é outra, organizada pelo que o número de fato compromete.
O chute. Uma ordem de grandeza, não um número. Dado de experiência, antes de qualquer um ler qualquer coisa. Sua única função honesta é responder “essa conversa faz sentido?”. Carregando o intervalo inteiro de dezesseis vezes, ele é inútil para planejar e perigoso dentro de um board deck.
O orçamento. Produzido depois de um discovery de verdade, em que alguém interrogou seus requisitos e achou as partes em que você não tinha pensado. É contra este que você planeja. Ele deveria chegar como um intervalo. Se chegou como um ponto, alguém arredondou por você.
O compromisso. O que o time vai ser cobrado de verdade. Só é honesto depois que coisas suficientes foram decididas para estreitar o cone, o que na prática significa depois que uma parte do trabalho já começou.
O preço de contrato. Um número com consequência jurídica. Ele contém um prêmio de risco, e você paga esse prêmio independentemente de o risco acontecer ou não. É aqui que a estimativa deixa de ser aritmética e vira posição de negociação, e é por isso que o número que entra num escopo de trabalho nunca é o número da primeira call.
Não são quatro técnicas. São quatro níveis de promessa. E o erro fatal, que a gente vê founder cometer o tempo todo, é tratar um chute como se fosse um preço de contrato e depois se sentir traído quando a realidade aparece.
As quatro perguntas que devolvem o intervalo
Quando um número chega, você tem uma janela curta em que fazer perguntas duras ainda é normal e ainda não virou hostilidade. Use essa janela. Estas quatro perguntas trabalham mais do que qualquer negociação.
1. “Qual é o pior caso, e o que precisa dar errado para chegar nele?”
Os melhores estimadores já acompanham isso. Jacob Kaplan-Moss, cocriador do Django e autor do guia prático mais claro sobre capturar incerteza junto com tempo, defende que qualquer estimativa que preste carrega as duas coisas. “Dez a quinze dias” te conta algo que “dez dias” esconde ativamente.
Se o seu fornecedor não consegue produzir um pior caso, ele não pensou no assunto, e você acabou de aprender de graça uma coisa cara.
2. “Qual linha aqui é a que você tem menos certeza?”
Variância quase nunca se espalha de forma uniforme por um projeto. Ela se concentra. Uma tarefa, geralmente a que ninguém nunca fez antes, responde pela maior parte da dispersão do plano inteiro. Ache essa tarefa e você achou o seu risco de verdade, junto com o único lugar onde gastar dinheiro cedo tem retorno real.
No agendador para clínicas, nunca foi o calendário de marcação. Foi a checagem de elegibilidade do convênio, uma integração com um sistema cuja documentação era um PDF de 2016.
3. “O que você assumiu que eu teria pronto, e para quando?”
Enterrado em toda estimativa existe um conjunto de premissas sobre você. Que você vai aprovar os layouts em dois dias e não em duas semanas. Que você vai conseguir as credenciais com o seu provedor de pagamento. Que você vai decidir o modelo de preço antes de as telas de cobrança serem construídas. Que você vai achar uma clínica de verdade disposta a testar com pacientes de verdade.
Na nossa experiência, a causa mais comum de uma data perdida não é a engenharia. É um founder que também está tocando vendas, captação e contratação, e que virou o gargalo de onze decisões que ninguém avisou que eram dele.
4. “O que não está dentro deste número?”
Pergunte sem rodeio. Migração dos dados da planilha que todo mundo ainda usa. Ferramenta de admin para o time de operação. A segunda rodada de revisão de design. Teste de carga. Revisão da app store. Duas semanas de correção de bug depois do lançamento, que não são opcionais e nunca aparecem na estimativa.
Tudo que não for dito vira uma solicitação de mudança depois, a um preço que ninguém negociou sob pressão competitiva.
O que é a regra 80/20 no desenvolvimento de software?
As pessoas pesquisam isso, então vamos responder e depois corrigir.
A versão que engenheiro conta para engenheiro é a de Tom Cargill, do Bell Labs, e é mais engraçada e mais verdadeira: os primeiros 90% do código levam 90% do tempo, e os 10% restantes do código levam os outros 90% do tempo.
É uma piada sobre um fenômeno real. Software fica com cara de pronto muito antes de estar pronto. A demo da sexta semana é linda. Ela se move, ela clica, ela faz o seu board se inclinar para a frente. O que ela não faz é lidar com duas recepcionistas dividindo o mesmo login e marcando dois pacientes no mesmo horário das 15h. Nem com um cartão recusado. Nem com um paciente que cancela duas vezes e é cobrado assim mesmo. Nem com os trinta estados tediosos entre o “caminho feliz” e a produção.
Essa distância entre demo e pronto é onde as estimativas vão morrer, e é por isso que um fornecedor que te mostra algo impressionante na semana seis e depois some não está necessariamente atrasado. Pode ser que ele só tenha chegado no trabalho de verdade.
Como estimar o custo de um software quando é você que paga
Você não prevê. Você limita. Três movimentos, em ordem de quanto valem.
Compre uma decisão, não um desconto. Se uma linha concentra a maior parte da incerteza, pague por uma investigação curta e com prazo fechado exatamente daquilo antes de se comprometer com a obra inteira. Duas semanas pagas em cima da integração do convênio saem drasticamente mais barato do que o prêmio de risco que você pagaria num preço fechado de doze semanas, e mais barato ainda do que descobrir o problema na semana nove.
Orce o pior caso, planeje com o caso esperado. Leve o intervalo a sério nas duas pontas. Coloque o número pessimista no modelo que você mostra para o board. Toque a empresa no número esperado. Um founder que já contou o número otimista para o investidor destruiu a própria capacidade de tomar boas decisões depois.
Entenda o que o modelo de preço faz com a sala. Preço fechado te compra previsibilidade e você paga por ela duas vezes: uma no prêmio de risco embutido no número, outra num parceiro que agora ganha dinheiro toda vez que diz não para você. Time and materials costuma ser mais barato no total e exige que você preste atenção de verdade. Nenhum dos dois está certo no abstrato. Já escrevemos em separado sobre o que puxa o preço de um aplicativo, e a versão curta é que a variável maior nunca foi o valor da hora.
Quando o número é maior que o orçamento
O primeiro instinto de quase todo founder é empurrar o número. É a alavanca errada, e é a que tem mais chance de produzir um fornecedor que diz sim e um projeto que apodrece em silêncio.
Empurre as decisões. Cada hora de incerteza na estimativa está grudada em alguma coisa que ninguém decidiu ainda, e você tem o direito de decidir. Corte o que você não consegue defender. Adie a integração que serve 8% dos usuários. Lance a versão que funciona para uma clínica em vez da versão que funciona para todas. Estreitar o escopo de projeto é o único movimento que diminui o número sem empurrar a dor para um lugar onde você não consegue ver.
O agendador saiu de doze semanas para sete. Não porque alguém apontou o lápis, mas porque a integração de faturamento com convênio, a maior fonte de incerteza do plano, foi tirada da v1 e trocada por uma exportação em CSV que uma pessoa rodava às sextas. Era feio. Entrou no ar a tempo do cliente âncora. A integração foi construída quatro meses depois, direito, por um time que a essa altura já sabia como os dados realmente eram.
A pergunta que se deve fazer no lugar
“Isso está bom?” não tem resposta, e o founder que pergunta isso normalmente está torcendo para alguém absolvê-lo de uma decisão que é dele.
A versão com resposta é esta: o que vocês ainda não sabem, e quanto vai me custar descobrir? Uma estimativa que não responde isso não é uma estimativa. É um desejo com casas decimais.
Perguntas frequentes sobre estimativa de desenvolvimento de software
O que é estimativa no desenvolvimento de software?
É a prática de prever o esforço, o tempo e o custo necessários para construir um software. O resultado é genuinamente um intervalo, porque o trabalho ainda não foi todo decidido. Quando você recebe um número único em vez de um intervalo, alguém tomou por você a decisão de qual ponta daquele intervalo te mostrar.
Quão precisas são as estimativas de software?
As iniciais erram muito, e isso é medido, não anedótico. Na fase de conceito, estimativas feitas por estimadores experientes carregam um erro de cerca de quatro vezes para cada lado. A precisão melhora conforme decisões são tomadas e o escopo para de se mexer, não conforme o estimador se concentra mais.
Como estimar o custo de um software sendo um founder não técnico?
Você não estima. Você limita. Peça um caso esperado e um pior caso, orce contra o pior caso, identifique a única linha que concentra mais incerteza e pague por uma investigação curta e com prazo fechado só daquilo antes de fechar a obra inteira.
O que perguntar quando recebo uma estimativa de software?
Quatro coisas: qual é o pior caso e o que o provoca, qual linha o time tem menos confiança, o que a estimativa assume que você vai entregar e quando, e o que foi deliberadamente deixado de fora do número.
Por que projetos de software sempre estouram o prazo?
Em geral não é porque a engenharia foi lenta. É porque o escopo continuou se mexendo, porque decisões que eram do founder chegaram tarde, ou porque trabalho que todo mundo assumiu que estava incluído (migração de dados, ferramenta de admin, correção de bug pós-lançamento) nunca esteve dentro do número.