O prazo que ganha o contrato costuma ser o que mais atrasa

Todo orçamento de software que promete uma data exata está vendendo, não estimando. Já perdi contrato por dar o número honesto e vi o barato chegar mais tarde e pela metade. Por que o menor prazo quase sempre é o que mais atrasa, e o que olhar antes de assinar.

Todo orçamento de software que promete uma data exata está vendendo alguma coisa. Não necessariamente mentindo, mas vendendo. A data exata é a parte do documento feita pra você assinar, não pra ser cumprida.

Digo isso do lado de quem escreve proposta. Já perdi contrato por cravar um número maior que o do concorrente, e já assinei, lá no começo, prazo que eu sabia otimista só pra não ficar de fora. Aprendi a olhar estimativa com desconfiança porque estive dos dois lados do balcão.

Se você é o founder que enfileira três orçamentos numa planilha e tende a marcar o mais barato e mais rápido, este texto é sobre o que esse número esconde.

Por que o número mais baixo quase sempre ganha

A dinâmica é simples e um pouco viciada. Você pede orçamento pra três fornecedores. Um diz seis meses, outro diz quatro, o terceiro diz três. Sem informação técnica pra julgar quem está certo, sobram os dois critérios mais fáceis de comparar: preço e prazo. O menor ganha.

Só que o menor número raramente é o mais honesto. É o mais otimista, ou o mais desesperado pra fechar. Quem estima curto não está sendo mais competente; quase sempre está só contando com tudo dando certo: sem bug, sem retrabalho, sem aquele requisito que ninguém falou na reunião de venda. E software nunca dá inteiramente certo.

Ano passado a gente perdeu um projeto de agendamento pra uma rede de clínicas por causa disso. Orçamos cinco meses; um concorrente prometeu dois e meio pela metade do preço. O founder foi no dois e meio, claro. Cruzei com ele num evento uns sete meses depois: o sistema tinha acabado de entrar no ar, com metade das telas que estavam no escopo, e o fornecedor já pedia aditivo. Ele pagou mais caro que os nossos cinco meses e chegou depois. Não conto isso pra parecer vidente. A amostra é torta, eu só fico sabendo dos casos que deram errado e voltaram pra conversar. Mas esse padrão eu vejo com uma frequência que já parou de me surpreender.

Alguns dos projetos que a gente pegou depois de um prazo otimista estourar estão em revin.com.br/pt/cases, agora com produto no ar em vez de aditivo na mesa.

A data que você circulou no calendário na assinatura raramente é a data em que o produto entra no ar.

A regra dos noventa e noventa

Existe uma piada velha de engenharia, atribuída ao Tom Cargill, dos Bell Labs, que descreve isso melhor que qualquer gráfico: os primeiros 90% do código tomam 90% do tempo, e os 10% finais tomam os outros 90% do tempo. Some, dá 180%. É piada, mas todo mundo que já entregou software ri torto, porque é exatamente assim que a conta fecha.

O motivo é que a parte visível do trabalho, a que dá pra demonstrar numa tela bonita, é a que anda rápido. O que trava é o resto, que ninguém coloca no orçamento porque não aparece na demo:

• Os casos de erro: o que acontece quando o pagamento falha, quando a conexão cai no meio de uma requisição, quando o usuário faz o que você jurou que ninguém faria.
• A migração dos dados velhos, que sempre chegam mais sujos do que o cliente admitiu na venda.
• O endurecimento pra produção: performance sob carga, permissão, log, o comportamento em pico que a máquina do dev nunca viu.

Numa conta grosseira dos projetos que a gente herdou pela metade, esses 10% finais consumiram algo perto de 40% do esforço total. É um número que eu seguro com pinça: sai de uma amostra pequena e de produtos que já chegaram doentes, então provavelmente está inflado. Mesmo assim, a direção nunca muda. O fim custa muito mais do que o meio parece prometer.

No papel o plano parece inteiro. Os quadradinhos que ninguém desenhou são justamente os que seguram a entrega.

Estimar não é cravar uma data

A saída não é estimar tão bem a ponto de acertar a data no cravo. Ninguém acerta. A saída é parar de tratar estimativa como promessa e passar a tratar como faixa. Quando um cliente me pergunta quando fica pronto, a resposta honesta tem três números, não um: o cenário bom, o provável e o ruim. Se a distância entre o bom e o ruim é enorme, ela está medindo o tamanho do que ainda não se sabe sobre o problema, e é justamente esconder isso atrás de um número único que seria desonesto.

O que a gente faz pra encolher essa distância é fatiar o trabalho em pedaços que rodam. Em vez de sumir por três meses e reaparecer com "o produto", a gente entrega algo demonstrável toda semana: pequeno, às vezes feio, mas de pé e testável por gente de verdade. O número em que você pode confiar é sempre o que está grudado em alguma coisa que você já viu funcionando. O resto é chute com fantasia de compromisso.

Quando a gente entra num projeto pelo Diagnostic Sprint, boa parte das primeiras conversas é justamente recalibrar a estimativa que alguém vendeu curto: separar a bagunça de superfície do buraco de verdade no cronograma.

Quando o prazo curto é honesto

Preciso ser justo, senão isso vira desculpa pra todo atraso. Nem todo prazo apertado é mentira. Existe a data que o mundo impõe: a regulação que entra em vigor, a rodada que fecha, a feira do setor que não vai mudar de mês porque o seu backend atrasou. Nesses casos o prazo curto é uma restrição real que veio de fora, e um bom time trabalha dentro dela cortando escopo à vista de todos, sem cortar teste escondido.

A diferença entre os dois é o que some quando aperta. Prazo honesto encurta a lista de features e avisa. Prazo vendido encurta a qualidade e cala. Você só descobre qual dos dois comprou quando já está em produção.

O prazo honesto sai mais caro na proposta

No fim, a escolha do founder não é entre caro e barato. É entre pagar a diferença na assinatura ou pagar depois, com juros de aditivo, retrabalho e um produto que chega tarde e pela metade. O orçamento honesto quase sempre parece o pior negócio na hora de decidir. Costuma ser o único que ainda respeita o seu caixa doze meses depois.

Se você está com três orçamentos na mesa e o mais barato parece bom demais pra ser verdade, vale meia hora com quem já viu esse filme dos dois lados antes de você assinar.