Projeto de software atrasa por motivos conhecidos e repetidos. O que quase ninguém diz na hora de vender é que boa parte desses motivos não está no fornecedor: está do lado de quem contratou. Aprovação que demora duas semanas, decisão que ninguém toma, pedido novo no meio do caminho que entra sem repactuar prazo.
Isso não é para tirar responsabilidade de quem executa. É que saber onde o atraso nasce, antes de começar, é a diferença entre um projeto que entrega e um que vira briga de versão de história.
As causas que estão no fornecedor
Comecemos pelo lado de quem entrega, que é onde a responsabilidade principal mora.
Estimativa otimista para ganhar o contrato. O prazo apertado ajuda a vender e cobra depois. Se a proposta que você recebeu é bem mais rápida que as outras, vale desconfiar em vez de comemorar.
Time insuficiente ou compartilhado. A pessoa que ia trabalhar no seu projeto está apagando incêndio no de outro cliente. Você não vê isso acontecendo, só vê a entrega escorregar.
Descoberta tardia de complexidade. O fornecedor achou que a integração com o sistema antigo seria simples, e não era. Isso acontece de verdade, e é por isso que a fase de levantamento existe.
Falta de método de mudança. Sem um processo para avaliar o impacto de cada pedido novo, o projeto vai inchando sem ninguém somar quanto aquilo custou em dias.
As causas que estão no cliente
Esta parte é desconfortável e é justamente a que muda o resultado.
A aprovação que não vem. O fornecedor entrega uma etapa e fica esperando resposta. Uma semana parada aqui, dez dias ali, e o cronograma escorregou um mês inteiro sem ninguém ter feito nada de errado. Ninguém anota essas esperas, e é por isso que elas somem da conversa quando o prazo estoura.
A decisão que ninguém quer tomar. Duas áreas discordam de como o processo deveria funcionar e o projeto vira refém dessa discussão. Isso não é problema técnico, é problema de mandato interno.
O pedido novo que entra sem repactuar. "Já que estamos mexendo nisso, aproveita e coloca também." Cada pedido desses é pequeno. A soma deles é o que estoura o prazo, e o pior é que ninguém percebe porque nunca foi somado.
A pessoa-chave que não tem tempo. Quem conhece o processo de verdade é sempre quem está mais ocupado. Se essa pessoa não tem horas reservadas para o projeto, o time desenvolve com suposição, e suposição vira retrabalho.
A pressa que cria prazo irreal. Exigir data impossível e escolher o fornecedor que aceitou é uma decisão sua. E ela custa caro, porque o prazo não vira realidade só porque foi assinado.
O scope creep é sempre pequeno
Vale entender por que o crescimento de escopo passa despercebido.
Nenhum pedido isolado parece grande. É um campo a mais, um relatório simples, "só" adicionar um filtro. Cada um custa um dia ou dois, e negar parece mesquinho quando o clima está bom.
O problema é que quinze pedidos de um dia são três semanas de atraso, e essas três semanas nunca foram somadas em lugar nenhum. Quando o prazo estoura, os dois lados olham para trás e cada um lembra de uma versão diferente do que foi combinado.
O antídoto é chato e funciona: todo pedido novo passa por uma resposta escrita com impacto em prazo e custo. Não para dificultar, mas para a decisão ser consciente. Muitas vezes o cliente olha o impacto e diz que não vale, e isso é ótimo para os dois lados.
O que combinar antes de começar
Cinco combinações resolvem a maior parte dos atritos, e todas são baratas de fazer no início:
Quem aprova, com nome. Uma pessoa com autoridade para decidir, não um comitê. Comitê aprova devagar.
Prazo máximo de resposta. Se a aprovação não vier em X dias úteis, o cronograma se desloca automaticamente. Combinar isso antes evita a discussão depois.
Como pedido novo é tratado. Todo pedido fora do combinado vira uma resposta com impacto em dias e valor, antes de virar trabalho.
Quanto tempo do seu time o projeto vai consumir. Reuniões, validações, testes. Coloque isso na agenda de quem vai participar, senão o projeto compete com a operação e perde.
O que significa "pronto". Critério de aceite escrito para cada entrega. Sem isso, a validação vira opinião e o retrabalho vira infinito.
Se o fornecedor não propuser nada disso, proponha você. E se ele resistir a colocar por escrito, isso é informação sobre como o projeto vai correr.
O sinal de que o projeto vai atrasar
Existe um indicador precoce, e ele aparece bem antes do prazo estourar: quando as reuniões de acompanhamento começam a ser desmarcadas.
Fornecedor que está confortável mostra o que fez. Fornecedor com problema evita a conversa. Do lado do cliente vale o mesmo: se a sua equipe está adiando a reunião do projeto porque "essa semana está corrida", o projeto já perdeu prioridade, e projeto sem prioridade atrasa.
Reunião curta e frequente, com o que foi feito e o que está travado, custa quinze minutos e evita o susto de três meses.
E quando o atraso acontece mesmo assim
Vai acontecer em algum projeto, e a forma de lidar define o estrago.
O caminho certo é replanejar cedo, com o número na mesa: o que falta, quanto tempo leva, o que dá para tirar do escopo se a data for inegociável. Isso é uma conversa difícil de uma hora.
O caminho errado é empurrar o prazo semana a semana, com o fornecedor prometendo que na próxima entrega recupera. Isso adia a conversa difícil e transforma um atraso administrável em ressentimento.
Vale como regra para os dois lados: prefira a má notícia cedo à boa notícia duvidosa.
E se você está lendo isso justamente porque desconfia de contratar projeto, a leitura correta não é desistir. É exigir que essas cinco combinações estejam escritas antes de assinar. Fornecedor que topa colocar prazo de aprovação e critério de aceite no papel está assumindo o mesmo risco que você.
É isso que a gente estrutura no diagnóstico da AXIS antes de qualquer proposta: o que precisa ser feito, quanto tempo do seu time vai custar e onde o projeto pode travar. Combinado antes, o prazo tem chance de ser cumprido. Veja as soluções da AXIS ou agende seu diagnóstico, sem compromisso.
Dúvidas comuns
Por que projetos de software atrasam tanto?
Por causas dos dois lados: estimativa otimista, time compartilhado e complexidade descoberta tarde, do lado do fornecedor; aprovação demorada, decisão pendente, pedidos novos sem repactuação e falta de tempo da pessoa-chave, do lado do cliente.
O que é scope creep?
É o crescimento gradual do escopo por meio de pedidos pequenos que ninguém soma. Cada um parece custar um ou dois dias. Juntos, são semanas de atraso que não estavam no cronograma.
Como evitar que o meu projeto atrase?
Defina quem aprova, um prazo máximo para aprovação, como pedido novo é avaliado, quanto tempo do seu time o projeto vai consumir e o que significa "pronto" em cada entrega. Tudo por escrito, antes de começar.
Multa por atraso resolve?
Ajuda a alinhar expectativa, mas não entrega o sistema. E se o atraso tiver causa mista, discutir a multa costuma consumir mais energia do que replanejar. Prevenção vale mais que cláusula.
Como saber se o projeto está atrasando antes do prazo final?
Pela frequência das reuniões de acompanhamento e pela clareza do que foi entregue em cada uma. Quando a conversa começa a ser adiada ou fica vaga, o problema já existe.