Por que projeto de software atrasa: as cinco causas que se repetem

Projeto de software quase nunca atrasa de uma vez. Atrasa em pedaços de dois dias que ninguém soma enquanto estão acontecendo, e que aparecem juntos na última semana.

Depois de muitos projetos, as causas se repetem. Nenhuma delas é "a equipe não é boa".

1. O escopo cresceu e ninguém decidiu que cresceu

É a causa número um, com folga. Não é mudança de escopo formal — essa pelo menos é discutida. É o acréscimo pequeno: "já que você está mexendo nessa tela, dá para incluir o campo X?"

Cada pedido isolado é razoável e custa meio dia. Trinta pedidos razoáveis custam três semanas que não estavam no plano.

O que resolve: registro de pedido, mesmo o pequeno, com o custo em horas ao lado. Não para dizer não — para que a decisão de incluir seja uma decisão, e não uma gentileza. Quando o cliente vê "este pedido move o Go Live em dois dias", metade dos pedidos some sozinha.

2. A dependência que ninguém mapeou

O desenvolvimento termina e o projeto para, porque falta:

• o acesso ao ambiente que o cliente ia providenciar
• a definição de regra de negócio que depende de uma área que não está na reunião
• o layout do arquivo que o parceiro externo ia mandar
• a homologação de alguém que não sabia que seria chamado

Nenhuma dessas é tarefa de desenvolvimento, e por isso nenhuma está no cronograma de desenvolvimento.

O que resolve: listar as dependências externas no início, cada uma com nome, data e o que acontece se atrasar. É uma reunião chata de uma hora que economiza semanas.

3. A aprovação que não estava na agenda de ninguém

O cronograma diz "homologação: 3 dias". Na prática, a pessoa que homologa tem outro trabalho em tempo integral e vai olhar quando der. Três dias viram duas semanas, e não é má vontade.

O que resolve: marcar a homologação na agenda da pessoa, com data e hora, no início do projeto. Bloco de duas horas marcado três semanas antes tem chance; "me avisa quando estiver pronto" não tem.

4. A estimativa foi feita por quem não vai executar

Estimativa de gerente é otimista por construção: ele lembra do caminho feliz. Quem vai escrever o código lembra do tratamento de erro, do caso de borda e da migração de dado que ninguém mencionou.

O que resolve: quem estima é quem executa, e a estimativa inclui teste e correção. Se a cultura do lugar pune estimativa alta, você vai receber estimativa baixa e atraso — é aritmética, não caráter.

5. Ninguém mediu até ser tarde

O projeto tem oito semanas. Na semana seis alguém pergunta como está, e a resposta é "quase lá". Na semana oito descobre-se que "quase lá" era 60%.

O que resolve: entrega parcial que funciona, em intervalo curto. Não relatório de percentual — software rodando que alguém consegue abrir. "Está 70% pronto" é opinião; "estas quatro telas funcionam e estas seis não existem" é fato.

É o que faz marco de aceite formal valer: não é burocracia, é o momento em que a realidade entra na conversa.

O padrão por trás das cinco

Todas são a mesma coisa em roupas diferentes: a informação existia, mas não chegou a quem decide enquanto ainda dava para agir.

O escopo cresceu — alguém sabia. A dependência ia atrasar — alguém sabia. A homologação não ia acontecer — alguém sabia. O problema não é falta de informação, é o caminho dela até a decisão.

Por isso o indicador mais útil de saúde de projeto não é o percentual concluído. É quanto tempo leva para uma má notícia chegar a quem pode fazer algo. Em projeto saudável, horas. Em projeto que vai atrasar, semanas — e normalmente chega junto com o atraso já consumado.

Como tratamos isso

Marcos de aceite formal por fase, e risco comunicado na semana em que aparece. Se um marco está em risco, o cliente sabe quando o risco aparece — não no mês em que o prazo estoura.

Não é garantia de projeto sem problema. É garantia de que o problema vai ser discutido enquanto ainda existe escolha.