Por que projetos de software falham: 5 razões que se repetem

Em 2005, o mundo gastava US$1,7 trilhão por ano com tecnologia da informação. Em 2025, já em dólares corrigidos, o número chegou a US$5,6 trilhões. Segundo reportagem de Robert N. Charette na IEEE Spectrum, publicada em 23 de novembro de 2025, a taxa de sucesso dos projetos de software não melhorou de forma visível nesse período.

Charette acompanha falhas de software há duas décadas. A conclusão dele é desconfortável: os projetos não falham por causa de tecnologia nova ou difícil. Falham pelos mesmos motivos de sempre. Nas palavras dele, “esperança não é uma metodologia”.

O tamanho do problema

Os exemplos da reportagem são de órgãos públicos e grandes empresas, mas a lógica serve para qualquer founder.

• O sistema de folha de pagamento Phoenix, do governo do Canadá, foi orçado em CA$310 milhões e entrou no ar em 2016. Já custou mais de CA$5,1 bilhões. Cerca de 70% dos 430 mil servidores tiveram erro no contracheque em nove anos.
• O sistema de licenciamento de veículos de Minnesota foi planejado em US$41 milhões e cancelado em 2019, depois de custar US$100 milhões.
• A Lidl abandonou um ERP de €500 milhões depois de três anos e voltou para o sistema antigo.
• Nos Estados Unidos, o CISQ estimou em US$260 bilhões o custo das falhas de desenvolvimento de software só em 2022.

Nenhum desses projetos começou com a intenção de falhar. Todos tinham orçamento, equipe e cronograma.

As 5 razões pelas quais seu produto nunca foi ao ar

A IEEE Spectrum lista mais de dez causas. Juntamos as que mais aparecem em produtos digitais de founders em cinco grupos.

1. A meta nunca foi escrita

Charette aponta “metas irreais ou não articuladas” como causa recorrente. Em produto digital, isso aparece assim: todo mundo concorda que o app precisa “resolver o problema do cliente”, mas ninguém escreveu qual problema, para quem e como medir. Sem meta escrita, cada reunião muda a direção.

2. O escopo cresce sem dono

Scope creep é o item mais conhecido da lista. Cada funcionalidade nova parece pequena. Somadas, empurram o lançamento por meses. O sinal é simples: se ninguém tem autoridade para dizer “isso fica para a versão 2”, o escopo vai crescer até o dinheiro acabar.

3. Prazo e custo foram chutados para baixo

A reportagem cita “premissas otimistas demais de custo e prazo”, como cortar teste e pular piloto. No caso Phoenix, o projeto foi orçado em menos de 60% do valor da proposta do fornecedor. Quando o número cabe no desejo e não no trabalho, a diferença aparece depois, com juros.

4. Teste ficou para o fim

“Teste inadequado” está na lista. Em produto pequeno, teste costuma ser a primeira coisa sacrificada quando o prazo aperta. O resultado é um lançamento que trava no primeiro dia de uso real e queima a confiança dos primeiros clientes, que são os mais difíceis de conquistar.

5. Ninguém responde pelas decisões

Charette fala em falta de responsabilização das decisões de gestão e em política interna que esconde problemas. Para um founder com fornecedor externo, isso tem cara conhecida: o estúdio diz que o atraso é culpa da mudança de escopo, o founder diz que é culpa do estúdio, e o produto continua fora do ar.

A armadilha de achar que o seu caso é diferente

Um ponto da reportagem merece destaque: a “armadilha da singularidade”, quando gestores descartam lições de falhas passadas porque acham que o seu projeto é único. Charette resume: repetir os mesmos erros esperando outro resultado não é aprender.

Todo founder acha que o seu produto é diferente. O produto pode ser. O jeito de fazer ele falhar quase nunca é.

O que isso muda para você

Antes de começar ou retomar um projeto, responda por escrito:

1. Qual é a meta da primeira versão, em uma frase e com um número?
2. O que fica de fora, de forma explícita?
3. Qual é a data, e quem pode mudar essa data?
4. Quando e como o produto vai ser testado com gente de verdade?
5. Quem responde pelo resultado, do seu lado e do lado do fornecedor?

Se alguma resposta for “a gente vê depois”, você já sabe onde o projeto vai travar.

Como fazemos no Studio

Começamos por um diagnóstico. Só depois dele damos preço, e o preço é fechado. O prazo vai escrito no contrato, e o escopo é cortado para caber nessa data, não o contrário. Foi assim que a LCX, empresa de turismo com operação em mais de 10 países da América do Sul, trocou um sistema por país por um sistema só, no ar em 29 dias.

Depois do lançamento, todo sistema sai com um agente de IA que roda todo dia, aponta falhas, sugere melhorias e confere se os dados fazem sentido. É o teste que não termina quando o projeto termina.

Se você quer tirar um sistema ou SaaS do papel sem repetir essas cinco razões, é exatamente esse o trabalho do nosso serviço de sistemas e SaaS.