"Quanto tempo leva?" era a pergunta errada — e a IA só deixou a conta mais cara

Responda com faixa, o que ainda não foi medido e a data em que você volta com número menor. Por que "quanto tempo leva?" falha e o que medir antes de prometer.

Ninguém orça a fundação antes de furar o terreno. Em software, a sondagem é abrir o pedaço que ninguém olhou ainda.

Quando te pedirem uma estimativa, responda com três coisas na mesma frase: uma faixa, o que ainda não foi medido e a data em que você volta com um número mais apertado.

Em voz alta fica assim: "entre três e cinco semanas. O pedaço que conversa com o ERP ninguém aqui abriu ainda. Me dá até quinta, eu meço aquele trecho e volto com uma faixa menor." É menos bonito que um número seco e sobrevive muito melhor ao mês seguinte. Porque quem pergunta "quanto tempo leva?" quase nunca quer uma data. Quer saber se pode assumir um compromisso com outra pessoa, e por quanto tempo esse compromisso fica de pé.

A pergunta que eu fazia, e o quadro branco que não ajudava em nada

A faixa não sai do chute. Ela sai de meia hora aberta dentro do módulo que ninguém toca desde 2021.

Na minha primeira startup, de locação de equipamento para construção, eu contratei desenvolvedores sem entender com profundidade o que eles diziam. Meu ritual era sempre o mesmo. Eu perguntava quanto tempo levava, o dev falava um número, eu anotava no quadro e saía vendendo aquela data para cliente e sócio. A sprint terminava sem a entrega. Toda vez.

Levei perto de um ano para aceitar que o problema não estava no dev. Ele respondia exatamente aquilo que eu tinha perguntado. Pedi um número, recebi um número. O que eu precisava era da outra parte, a que ele ainda não tinha como saber, e eu nunca abri espaço na conversa para isso aparecer. Pior: do jeito que eu perguntava, dizer "não sei ainda" parecia incompetência. Então ninguém dizia.

Esse desenho não é raro. A pergunta "how to respond when you are asked for an estimate" está no Software Engineering Stack Exchange com score 717, 17 respostas e mais de 251 mil visualizações. Ninguém acumula esse tanto de leitura em cima de um problema que já foi resolvido.

Ninguém orça fundação antes de furar o terreno

Antes de trocar viga por query lenta, eu respondi tecnicamente pela montagem de estruturas metálicas. Em obra existe um ritual que em software virou luxo: antes de qualquer orçamento de fundação, alguém vai ao terreno e fura o solo em alguns pontos. Chama sondagem. Custa uma fração ridícula da obra e reordena o projeto inteiro. Se der areia fofa até uns oito metros, a sapata vira estaca e o preço muda de faixa.

Nenhum cliente de construção acha isso ofensivo. Ninguém liga para o engenheiro exigindo o preço da fundação antes de furar o terreno. Em software, esse mesmo pedido chega todo dia na caixa de entrada e ainda vem com "é só uma estimativa grosseira, não vou cobrar". Vai cobrar. O número dito na quarta-feira em uma call vira linha de um plano de lançamento na semana seguinte.

A versão de sondagem no nosso mundo é barata do mesmo jeito. Meia hora abrindo o módulo que ninguém tocou desde 2021. Uma tarde subindo o ambiente do zero em uma máquina limpa para ver quantos passos faltam no README. Uma consulta ao log de erro do último mês. Isso não é estimativa, é medição. E é ela que encolhe a faixa.

Três perguntas de risco no lugar da pergunta de prazo

A data que sobrevive é a que tem uma revisão marcada no calendário desde o primeiro dia.

Quando alguém do time me dá uma data, eu devolvo três perguntas. Elas mudam mais o resultado do que qualquer técnica de pontuação de card:

• O que ninguém aqui abriu ainda? Todo escopo tem um pedaço que o time citou de boca e não olhou por dentro. É de lá que sai a maior parte do estouro.
• O que depende de gente que não senta com a gente? Aprovação de terceiro, credencial de fornecedor, ambiente de homologação de cliente. Prazo não estoura só por código, estoura por espera.
• O que precisa estar medido antes de eu apertar essa faixa? Se a resposta for "nada", ou o time já mediu, ou está chutando com voz firme.

Repare que nenhuma delas pergunta quanto tempo leva. As três procuram a variância, que é a coisa que dói. Prazo médio errado a gente corrige na semana seguinte. Prazo com desvio de três semanas destrói um lançamento inteiro.

"Mas eu preciso de uma data para falar com o cliente"

Essa é a objeção honesta, e ela tem razão. Você não vai entrar em uma reunião de conselho dizendo "depende". Só que a faixa com data de revisão te dá algo que o número seco nunca deu: um segundo momento combinado.

"Entre três e cinco semanas, e na quinta que vem eu te digo se é três ou cinco" é uma frase que o cliente aceita. O que ele não aceita, e com razão, é a surpresa na véspera. Todo mundo que já contratou engenharia sabe a diferença entre um projeto que atrasa e um projeto que atrasa em silêncio.

Se o contrato exige preço fechado antes de qualquer olhada no sistema, o caminho é separar a medição da execução. Uma ou duas semanas pagas de diagnóstico, com entregável escrito, e a proposta cheia depois. Quem já comparou quanto custa um squad de desenvolvimento com o custo de um trimestre perdido sabe que a sondagem é a parte barata da conta. Vale o mesmo raciocínio de construir ou comprar: a decisão fica melhor quando alguém mediu, e não quando alguém opinou mais alto.

A IA multiplicou o código e não mexeu na fila

Aqui está a parte nova do problema, e ela pegou muita gente de surpresa neste ano. O time adotou assistente de código, o volume de pull request subiu, a sensação de velocidade subiu junto e a data que o cliente espera continua exatamente onde estava.

Rodei um script nos PRs de um repositório para parar de discutir isso por impressão. A mediana de espera por um humano deu 19,4 horas. Não é o tempo de escrever o código, é o tempo do código parado esperando alguém com contexto para revisar. Escrever nunca foi o gargalo, e quando você acelera o único trecho que já era rápido, a fila logo depois fica maior. É o mesmo padrão que aparece no tempo médio de PR review em times remotos.

O efeito colateral na estimativa é traiçoeiro. Com o assistente, o dev entrega o rascunho da feature em duas horas e fica com a impressão de que o card acabou. A faixa que ele te dá encolhe. O que não encolheu foi a revisão, o teste que ninguém escreveu de verdade, a integração e o pedaço do sistema antigo que o assistente não conhece. A conta fica mais cara porque a promessa fica mais curta enquanto a entrega fica igual.

Uma digressão rápida: já vi assistente gerar 14 testes para um módulo que eu sabia estar quebrado, todos passando. A métrica ficou verde. A garantia não existia. Estimativa apoiada em métrica verde é chute com relatório.

O vilão tem nome, e ele está no contrato

O modelo de contratação que pede prazo fechado antes de qualquer medição é o que produz esse ciclo. Ele obriga o fornecedor a chutar, premia quem chuta baixo e depois cobra do cliente a diferença em escopo cortado, teste que não testa e monitoramento que responde 200 sem monitorar nada.

Quem paga a conta é sempre o mesmo. Fornecedor que aceita bater o preço não descobriu um jeito mágico de fazer mais barato. Ele tirou alguma coisa da entrega, e tirou justamente daquilo que o contratante não sabe avaliar. É por isso que a Revin trabalha com squad embarcado e mede antes de prometer: a faixa que sobrevive ao terceiro mês vale mais para todo mundo que o número bonito da proposta. E é honesto dizer que essa disciplina não te livra de errar, só encurta o erro. Também não sei se ela vale para um time de três pessoas tocando produto próprio, onde o prazo é interno e o custo do desvio cai no próprio colo.

Pega o último projeto que atrasou na sua empresa e procura uma data específica: o dia em que alguém abriu, pela primeira vez, o pedaço mais feio do escopo. Se essa data for bem depois do começo do projeto, o atraso já estava contratado antes da primeira linha de código. Quanto custaria medir aquele trecho antes de assinar a data?