Grandes projetos de software ainda fracassam mesmo após receberem trilhões de dólares
(spectrum.ieee.org)- Embora os gastos globais com TI tenham mais que triplicado desde 2005, a taxa de sucesso de grandes projetos de software quase não melhorou
- Em casos como o sistema de folha de pagamento Phoenix, no Canadá, o Post Office Horizon, no Reino Unido, e sistemas de bem-estar social e administração nos EUA e na Austrália, falhas de gestão, organização e ética se repetem
- Ferramentas de IA ou copilots não conseguem resolver esses problemas, e a falta de imaginação humana, metas irreais e falhas na gestão de riscos continuam sendo as principais causas
- Os custos de manutenção de sistemas legados consomem de 70% a 75% do orçamento de TI, e até a adoção de Agile e DevOps apresenta altas taxas de fracasso sem liderança organizacional e mudança cultural
- Erros recorrentes de gestão e fuga de responsabilidade ampliam o custo social, e transparência, ética e design de sistemas centrado no ser humano são apresentados como tarefas essenciais
O problema persistente das falhas de software
- Nos últimos 20 anos, os gastos com TI cresceram de US$ 1,7 trilhão para US$ 5,6 trilhões, mas a taxa de sucesso de software permaneceu estagnada
- As falhas acontecem independentemente de país, setor ou tipo de organização
- O custo social e econômico dessas falhas continua aumentando
- Fica explícito o limite da IA para resolver problemas de gestão
- A IA tem dificuldade para controlar os interesses complexos e fatores políticos de grandes projetos
- Projetos de TI já envolvem muitas decisões irracionais, então faltam exemplos adequados para a IA aprender
- As causas das falhas incluem falta de imaginação humana, objetivos pouco claros, falhas no gerenciamento da complexidade e ausência de controle de riscos
- Os mesmos fatores se repetem há décadas, mantendo o fenômeno do “déjà vu do fracasso”
Sistema de folha de pagamento Phoenix, do Canadá
- O sistema Phoenix, de CA$ 310 milhões, lançado em 2016, fracassou ao tentar integrar 80.000 regras de folha e 105 acordos sindicais
- Para cortar custos, houve redução de testes e de procedimentos-piloto, além da remoção de funções essenciais
- Como resultado, ao longo de 9 anos, 70% dos 430 mil funcionários tiveram erros salariais
- Em março de 2025, havia 349 mil erros ainda sem solução, e mais da metade estava atrasada havia mais de um ano
- Foram relatados até casos de suicídio de funcionários
- O custo total já passa de CA$ 5,1 bilhões, e o órgão de auditoria classificou o caso como “uma falha incompreensível de gestão e supervisão do projeto”
Sistema Post Office Horizon, do Reino Unido
- O sistema Horizon POS, da Fujitsu, adotado em 1999, ocultou erros internos enquanto 3.500 gerentes de agência eram processados por falsa contabilidade e fraude
- 900 foram condenados, 236 presos e mais de 13 cometeram suicídio
- Falhas técnicas, gerenciais, jurídicas e éticas atuaram em conjunto
- Middleware cheio de bugs, expansão de escopo sem controle, testes insuficientes e falta de pessoal
- A diretoria adotou postura hostil contra quem levantava problemas, ocultou evidências e tentou encobrir o caso de forma organizada
- As tentativas de substituição em 2016 e 2021 também fracassaram, e o Horizon ainda segue em uso
- O novo sistema tem orçamento de £410 milhões, com decisão prevista para julho de 2026
Outros grandes casos de fracasso
- Minnesota MNLARS: iniciado em 2016, cancelado em 2019, com custo de US$ 100 milhões
- Modernising Business Registers, da Austrália: orçamento de AU$ 480 milhões subiu para AU$ 2,8 bilhões, cancelado em 2022
- Sistema de registro de veículos da Louisiana: falhas recorrentes em um mainframe de 50 anos levaram à declaração de emergência em 2025
- Jaguar Land Rover: em 2025, um ciberataque interrompeu as operações globais por mais de um mês, com perdas de US$ 1,2 bilhão a US$ 1,9 bilhão
- ERP da Lidl: após o fracasso de um ERP de €500 milhões baseado em SAP, a empresa voltou ao sistema próprio (2017)
- Boeing 737 Max: falha de projeto no MCAS causou 346 mortes, com custo total estimado em US$ 74 bilhões
- Upgrade F-35 Block 4: cronograma atrasado em 5 anos, com custo subindo de US$ 10,5 bilhões para US$ 16,5 bilhões
O custo econômico do fracasso
- Nos EUA, o custo de falhas de software em 2022 foi de US$ 1,81 trilhão, sendo US$ 260 bilhões só em falhas de desenvolvimento
- O total é maior que o orçamento de defesa (US$ 778 bilhões)
- A manutenção de sistemas legados custa US$ 520 bilhões por ano e consome de 70% a 75% do orçamento de TI
- Como a substituição é cara e arriscada, ela acaba sendo adiada
- Relatório 2024 da NTT DATA: 80% das organizações disseram que tecnologias envelhecidas atrapalham a inovação
- A maioria dos executivos reconhece que a infraestrutura legada dificulta a resposta ao mercado
Os limites de Agile e DevOps
- Mesmo com a disseminação do desenvolvimento iterativo e incremental, as taxas de fracasso continuam altas
- Alguns relatórios citam taxa de fracasso de 65% em projetos Agile e de até 90% em DevOps
- Para uma adoção bem-sucedida, são necessários liderança, disciplina organizacional, treinamento e mudança cultural
- Mas a maioria das organizações não consegue sustentar isso
Erros de gestão que se repetem e ausência de aprendizado
- Gestores de projetos de TI muitas vezes ignoram lições de fracassos anteriores por acreditarem que “nosso projeto é diferente”
- O governo canadense repetiu no Phoenix as lições ignoradas do primeiro fracasso de sistema de folha em 1995
- A maior parte dos fracassos vem de erros comuns de gestão, não de tentativas inovadoras
- Está mais para “destruição financeira” do que para “destruição criativa”
- Casos de fracasso em sistemas administrativos baseados em IA
- O MiDAS, sistema de seguro-desemprego dos EUA, e o Centrelink Robodebt, da Austrália, acusaram injustamente centenas de milhares de pessoas com algoritmos errados
- Os governos foram relutantes em reconhecer os erros e compensar as vítimas
A necessidade de responsabilidade, ética e transparência
- A tomada de decisão opaca em sistemas com IA embutida levanta preocupações sobre violação de direitos dos cidadãos
- A UE garante legalmente o “direito à explicação sobre decisões algorítmicas”
- Cresce globalmente a necessidade de estabelecer transparência e responsabilização em sistemas automatizados como um direito humano
- Há discussões sobre leis de responsabilidade de software e licenciamento profissional, mas a viabilidade é baixa
- A alternativa mais realista é reforçar honestidade da liderança, pensamento cético e julgamento ético
- É preciso reconhecer com clareza os riscos e desconfiar de promessas exageradas de fornecedores
- Destaca-se a aplicação de princípios de design centrado no ser humano a todos os sistemas de TI, incluindo IA
Conclusão: hora de parar de repetir os mesmos erros
- O desenvolvimento de software é, por natureza, complexo e frágil, e pequenos erros podem levar a grandes consequências
- Para projetos bem-sucedidos, são indispensáveis recursos suficientes, liderança e responsabilização
- É preciso calcular os custos considerando também os danos emocionais e econômicos causados aos usuários
- Mais de 50 anos após a “crise do software” de 1968, seguimos repetindo os mesmos erros
- “Cometam erros novos”
“Qualquer pessoa pode errar, mas só um tolo insiste no próprio erro” - Cícero, orador romano
5 comentários
Opinião do Hacker News
Senti falta da solução apresentada no fim do texto
Na minha visão, a solução real é começar pequeno e validar em ambiente de produção real
Por exemplo, para criar um sistema nacional de folha de pagamento, primeiro seria preciso testar em uma cidade pequena com cerca de 50 pessoas, corrigir os bugs e depois expandir gradualmente para cidades maiores
Não existe processo de desenvolvimento de software que vá direto para escala nacional sem resolver os problemas em pequena escala antes
O volume de transações era baixo, então, se surgisse algum problema, dava para ajustar manualmente, além de evitar exigências de PCI
Graças a esse tipo de teste antes do rollout nas lojas de verdade, conseguimos cumprir o prazo sem grandes incidentes
Se tivéssemos implantado direto nas lojas dos clientes desde o começo, teria havido uma grande confusão por causa de erros no cálculo de impostos ou problemas de desempenho
A expansão gradual acumula dívida técnica e, no fim, ninguém mais confia no núcleo do codebase, caindo no medo de reescrever tudo
Mesmo um produto simples como o WhatsApp precisa de um projeto de engenharia pensado desde o início para escalabilidade em larga escala
Em sistemas pequenos e bem-sucedidos, é mais fácil surgir alguém assim, e isso permite crescer gradualmente com a confiança de usuários e desenvolvedores
Como projetos grandes têm alta probabilidade de falhar, é preciso começar pequeno seguindo o Princípio da Precaução (Precautionary Principle)
Esse ciclo iterativo é a base de qualquer projeto
Começar pequeno e modularizar antes de escalar. O caso da megafábrica da Tesla foi marcante
Estudando a história da tecnologia, percebi que o setor de hardware aprende com sucessos e fracassos do passado, mas o setor de software não
A maioria dos desenvolvedores não aprende desmontando sistemas antigos, e cada geração acaba revivendo os mesmos problemas
Nas retrospectivas, a pergunta é sempre “o que os desenvolvedores deveriam fazer diferente da próxima vez?”, e os gestores nunca assumem responsabilidade
No fim, os mesmos problemas se repetem, e o peso recai sobre os desenvolvedores
As gerações passadas resolviam problemas na base da stack, mas hoje tenta-se resolver tudo apenas no topo
O resultado é uma torre de abstrações, com mais consumo de recursos e praticamente as mesmas funcionalidades
Agora estamos entrando na era de empilhar mais uma camada de software em cima de modelos de IA
Tanto experiência quanto personalidade importam, e é essencial ter ego baixo e mentalidade voltada para resolver problemas
A maioria subestima a complexidade do projeto
Na pós-graduação, passei uma semana lendo o código-fonte do TinyOS para entender sua estrutura, e essa experiência me ajudou muito
A capacidade de entender rapidamente um codebase desconhecido é extremamente valiosa
Se novas linguagens e frameworks aparecem periodicamente, as empresas conseguem continuar contratando juniores com salários baixos
Acho que essa é uma das razões pelas quais software não é tratado como outras áreas da engenharia
Fundamentalmente, isso não é um problema de programação, mas de incompetência gerencial
Na maioria dos projetos, os requisitos de negócio não são claramente definidos, e tudo avança na base do achismo
O fracasso de grandes projetos públicos de TI fica claro quando se olha para a estrutura contratual e os incentivos
O problema é a dependência de consultoria por hora faturada em vez de competência real
Em projetos bem-sucedidos, o essencial não é a tecnologia, mas o alinhamento entre organizações e a competência
Acho que o etarismo no Vale do Silício é um problema real
A experiência é ignorada, e as lições do passado não são incorporadas de forma alguma
O setor de hardware buscou inovar sem deixar de respeitar seu legado
Existe a visão de que quem aprendeu com fracassos do passado acaba incapaz de tentar coisas novas
Projetos de software acabam falhando por causa de falhas humanas
Mais importante do que processo ou ferramenta perfeita é ter pessoas motivadas e responsáveis
É preciso haver consequências legais para que as pessoas façam o trabalho direito
Como em obras físicas, cada etapa deveria ter verificação independente e responsabilização
Por isso, na prática, o mais realista é aceitar um certo nível de risco
Os projetos bem-sucedidos dependeram de algumas pessoas com inteligência emocional e liderança
No fim, engenharia de software é um problema humano
Mas a indústria continua presa à fuga de responsabilidade e à perseguição de modismos
Esse tipo de problema não é exclusivo de software
Grandes projetos de infraestrutura como Auburn Dam, Columbia River Crossing e Big Dig também são notórios por estouros de orçamento
Se o orçamento inicial era irrealista, isso pode ser apenas o custo real finalmente aparecendo
Por isso a abordagem de começar com projetos pequenos e expandir gradualmente é importante
Não sou desenvolvedor nem PM, mas fiquei curioso sobre casos de sucesso em grande escala
Como trabalho em hospital, seria ainda melhor se fossem casos de sucesso na área de saúde
Li The Phoenix Project e entendi um pouco da mentalidade de Agile e DevOps, mas ainda é difícil aplicar isso na prática
Quero plantar as sementes do sucesso em projetos pequenos
Eles nasceram como uma reação à complexidade do Multics, e o Unix começou quando Ken Thompson escreveu o sistema ele mesmo em três semanas
Veja este texto
Lei de Conway, risco de depender de pessoas-chave, propriedade clara e cultura de testes também são indispensáveis
Acima de tudo, é preciso ter coragem para dizer “não”
Há também casos como o healthcare.gov, que melhorou depois do fracasso inicial
Antes de culpar a comunidade de TI, é preciso olhar para a cultura empresarial focada em ganhos de curto prazo
Segurança e estabilidade são sempre os primeiros itens a sofrer corte de orçamento
Executivos fracassam e saem com paraquedas dourados, enquanto a responsabilidade fica com os desenvolvedores
O governo também não pune adequadamente os incidentes de segurança causados por negligência corporativa
No fim, se repete a realidade cínica de tentar resolver tudo com IA, consultores e terceirização
Jogar trilhões na IA não vai melhorar a situação; na verdade, vai piorá-la
As sociedades ocidentais já estão instáveis e inclinando-se à extrema direita
A próxima crise pode levar não só a um colapso financeiro, mas a um colapso social
A humanidade precisa avançar por meio da compreensão, não de crises
Com bons processos, ela aumenta os resultados; com processos ruins, acelera os problemas
No fim, a direção continua a mesma — só a velocidade muda
Se isso não foi corrigido por tanto tempo, talvez não seja um problema de tecnologia ou de princípios de desenvolvimento, mas sim da área de operações que precisa absorver isso...
O escândalo dos Correios do Reino Unido até virou drama de TV.
Até agora, as vítimas ainda não foram indenizadas, então o caso continua em andamento.
Um caso recente no país que me vem à mente é o fracasso na implementação do sistema de TI de próxima geração do Gyeonggi Credit Guarantee Foundation.
https://v.daum.net/v/20251111165048155
Será que em outros países também fazem projetos de SI gigantescos assim?