Roadmaps falham por dependências perdidas, não por estimativas

O prazo perdido

Uma empresa de software da Série C, com 60 engenheiros, prometeu lançar seu produto na União Europeia até 30 de junho. Três contratos empresariais, no valor de US$ 4,2 milhões anuais, dependiam da data. O responsável por engenharia organizou nove frentes de trabalho, estimou cada uma, aplicou margem de 20% e projetou o fim para 12 de junho. As estimativas se confirmaram: uma frente levou as 11 semanas previstas, a infraestrutura terminou antes e dois atrasos de uma semana foram absorvidos pela margem. Ainda assim, o produto só chegou a Frankfurt em 4 de fevereiro do ano seguinte, sete meses depois do prazo, e um cliente assinou com um concorrente.

No fim de abril, um engenheiro descobriu que o provedor de identidade operava sob um contrato de região única. A expansão exigia um acordo empresarial que o fornecedor não assinaria em menos de 90 dias. A data já estava inviável desde janeiro, mas a equipe levou quatro meses para perceber. A conclusão é que o plano não falhou por estimativas ruins, e sim porque faltava uma etapa: uma condição externa que precisava ser verdadeira para o lançamento acontecer.

O erro estrutural

Estimativas, pontos de história, velocidade e margens respondem quanto tempo uma tarefa conhecida pode levar. Esse erro é limitado e pode ocorrer para mais ou para menos; em um conjunto de tarefas, desvios podem se compensar. Uma etapa ausente, porém, só acrescenta tempo e pode ser muito maior que o restante do plano. Um ciclo de fornecedor de 90 dias inserido em um programa de 24 semanas representa um excesso de 54%, e nenhum método de estimativa o detectaria se a tarefa nunca tivesse sido registrada.

Os dados citados reforçam a diferença. A base de Bent Flyvbjerg, com mais de 16 mil projetos em duas décadas e 20 setores, aponta que 47,9% ficaram dentro do orçamento, 8,5% ficaram dentro do orçamento e do prazo, e apenas 0,5% cumpriram orçamento, prazo e promessa de entrega. Em um estudo da McKinsey e da Universidade de Oxford com 5.400 grandes projetos de tecnologia da informação, os custos excederam as previsões em 45%, os prazos em 7% e o valor entregue ficou 56% abaixo do previsto. A pequena derrapagem de cronograma combinada com a grande perda de valor é apresentada como sinal de planos executados corretamente, mas incompletos.

Planejar de trás para frente

O planejamento tradicional começa no presente e lista ações que a equipe consegue executar. Trabalhar de trás para frente começa pelo resultado e pergunta o que mais precisa ser verdade para que ele aconteça. A resposta reúne tarefas e condições, inclusive as que pertencem a fornecedores, jurídico, finanças, reguladores ou clientes. A decomposição deve continuar até que cada elemento esteja verdadeiro hoje ou seja um trabalho que uma pessoa nomeada possa iniciar na segunda-feira com os recursos disponíveis. Obter aprovação jurídica é vago; enviar uma minuta de DPA ao advogado externo, com responsável e orçamento aprovados, é acionável.

Esse método produz um grafo de dependências, em vez de uma sequência escolhida por opinião. Dele podem surgir o caminho crítico e a folga de cada tarefa. Também revela condições sujeitas a relógios externos, como compras, auditorias, testes de segurança e períodos de aviso, além de conflitos de recursos que o número total de funcionários esconde. Quatro tarefas críticas que dependam das mesmas duas pessoas podem alongar o prazo real.

Custo, incentivos e limites

A antecipação da descoberta é barata: no exemplo, três semanas de planejamento para oito pessoas custam US$ 165 mil, contra US$ 55 mil por uma semana no plano tradicional. Mas encontrar o contrato no quarto mês gera US$ 482 mil de retrabalho, adia US$ 2,1 milhões em receita e pode custar um contrato de US$ 1,6 milhão; a exposição total chega a US$ 4,237 milhões, contra US$ 165 mil no planejamento antecipado. O trabalho não muda: muda apenas quando a dependência se torna visível.

Equipes continuam planejando para a frente porque resultados específicos permitem fracasso público, exigem compromissos de outras áreas e expõem quem está no caminho crítico. O método não é cascata: fixa o resultado, não a solução, e o grafo deve ser revisado conforme surgem fatos. Ele também não serve para pesquisa ou descoberta genuína, quando o objetivo ainda não pode ser descrito; nesses casos, é preciso explorar. Para testar o método, basta descrever o maior compromisso do trimestre e decompor suas condições até cada folha ser verdadeira hoje ou iniciável na segunda-feira por alguém identificado. A tese final é que o grafo pode revelar na primeira semana o que muitos times só descobrem no quarto mês.