Licoes de Engenharia de Software dos Maiores

Eu tenho um fascínio meio mórbido por projetos de software que deram espetacularmente errado. Não é schadenfreude — é que os fracassos ensinam muito mais do que os sucessos. Quando um projeto dá certo, tem 50 fatores envolvidos e é difícil isolar o que fez a diferença. Quando um projeto fracassa, geralmente dá pra apontar exatamente onde deu errado.

O que mais me impressiona analisando esses casos é que nenhum deles fracassou por causa de tecnologia. Não foi o framework errado, a linguagem errada ou o banco errado. Todos fracassaram por decisões humanas: gestão ruim, pressão de prazo irreal, falta de testes, cultura que punia quem dizia 'não está pronto'. A tecnologia era a parte mais fácil. As pessoas eram o problema.

Healthcare.gov: 1.7 bilhão de dólares e 6 usuários

Outubro de 2013. O governo Obama lança o Healthcare.gov, o marketplace online do Affordable Care Act onde milhões de americanos sem plano de saúde iam finalmente poder contratar um. O site era a peça central da maior reforma de saúde dos EUA em décadas. Tinha que funcionar.

No dia do lançamento, 250 mil pessoas tentaram acessar simultaneamente. O site travou. Quem conseguiu acessar encontrava erros em cada página. Formulários que não salvavam. Sessões que expiravam no meio do cadastro. Integração com seguradoras que falhava silenciosamente — você achava que tinha contratado um plano mas a seguradora nunca recebia seus dados.

No final do primeiro dia, exatamente 6 pessoas tinham completado o cadastro com sucesso. Seis. Num site de 1.7 bilhão de dólares. Num país de 320 milhões de habitantes.

O que deu errado

Tudo. Mas se eu tiver que escolher os três maiores problemas: governança fragmentada, zero load testing e requisitos instáveis.

55 contratantes trabalhavam no projeto sem um integrador responsável pelo sistema completo. Cada contratante construía sua parte e torcia pra funcionar junto. A agência do governo responsável (CMS) não tinha expertise técnica pra gerenciar um projeto dessa complexidade. Decisões técnicas eram tomadas por burocratas sem contexto de engenharia.

Ninguém fez load testing com o volume esperado de usuários. O governo estimava 50 mil a 60 mil usuários simultâneos no pico. O site aguentava menos de mil. E ninguém testou porque ninguém era responsável pelo teste de integração do sistema inteiro. Cada contratante testava sua parte isoladamente.

Os requisitos mudavam até semanas antes do lançamento. Decisões políticas alteravam funcionalidades em cima da hora. O plano era lançar tudo de uma vez, sem rollout gradual, sem feature flags, sem plano B. Tudo ou nada.

Cyberpunk 2077: crunch, scope creep e promessas impossíveis

A CD Projekt Red era a queridinha da indústria de games depois de The Witcher 3. Quando anunciaram Cyberpunk 2077, as expectativas foram pra estratosfera. E a CD Projekt alimentou essas expectativas com trailers espetaculares e promessas ambiciosas sobre IA de NPCs, mundo aberto vivo, personalização profunda e interações complexas.

O jogo foi lançado em dezembro de 2020 após ser adiado três vezes. Na versão de PC, era jogável com bugs. Nas versões de PS4 e Xbox One, era praticamente injogável — performance horrível, crashes constantes, NPCs desaparecendo, carros caindo do céu, missões quebrando. A Sony chegou a tirar o jogo da PlayStation Store e oferecer reembolso total. Uma humilhação sem precedentes.

O inferno do crunch

Meses antes do lançamento, a CD Projekt Red impôs crunch obrigatório de 6 dias por semana. Relatos de devs falavam em semanas de 100 horas. A empresa tinha prometido publicamente que não faria crunch — e depois fez. Devs exaustos produzindo código com mais bugs, tomando atalhos, sem tempo pra testes adequados.

O resultado foi previsível pra qualquer pessoa que já trabalhou com software: código escrito sob pressão extrema é código ruim. Não importa quão talentosa é a equipe. Quando você trabalha 14 horas por dia, 6 dias por semana, por meses, a qualidade despenca. O número de bugs por linha de código sobe. A capacidade de pensar em edge cases desaparece. A vontade de escrever testes some.

Boeing 737 MAX: custo acima de segurança

Já cobri o 737 MAX no artigo sobre os 10 bugs que mudaram a tecnologia, mas aqui o foco é diferente. O bug do MCAS é a consequência. A causa real é a cultura organizacional da Boeing.

A Boeing estava numa corrida contra a Airbus pelo mercado de narrow-body (aviões de corredor único). O A320neo da Airbus estava vendendo muito. A Boeing precisava de uma resposta rápida. Em vez de projetar um avião novo — o que levaria 7-10 anos e custaria bilhões — decidiu modificar o 737, um design dos anos 60. Turbinas maiores, software compensatório, certificação acelerada.

O MCAS foi projetado pra ser 'invisível' para os pilotos e reguladores. Se fosse declarado como um sistema crítico de controle de voo, exigiria retreinamento de pilotos (caro) e certificação mais rigorosa (demorado). A Boeing minimizou a importância do MCAS nos documentos entregues à FAA. Pilotos não sabiam que o sistema existia.

Internamente, engenheiros levantaram preocupações. E-mails revelados depois mostraram que funcionários da Boeing chamavam o MCAS de 'desenhado por palhaços supervisionados por macacos'. Outro escreveu que não deixaria a família voar num MAX. Essas vozes foram ignoradas pela gestão.

Hertz + Accenture: 32 milhões jogados no lixo

Em 2016, a Hertz contratou a Accenture pra redesenhar seu site e sistema de reservas online. O projeto era de 32 milhões de dólares. Dois anos depois, a Hertz processou a Accenture alegando que o projeto nunca foi entregue de forma funcional.

Segundo o processo judicial, a Accenture entregou código com milhares de bugs. O site não funcionava em browsers mobile. O sistema de reservas perdia dados. A interface era inconsistente entre páginas. Funcionalidades que estavam no escopo simplesmente não existiam.

A Hertz alegou que a Accenture não tinha pessoal qualificado no projeto e que desenvolvedores juniores estavam tomando decisões de arquitetura. A Accenture contra-argumentou que a Hertz mudava os requisitos constantemente e que a governança do projeto era caótica dos dois lados.

Os dois provavelmente estavam certos. É o cenário clássico de projetos enterprise: consultoria grande vende projeto ambicioso, staffa com juniores, cliente muda escopo toda semana, ninguém tem ownership real do resultado, e no final ninguém fica feliz. 32 milhões de dólares pelo ralo.

O padrão que conecta todos os fracassos

Depois de estudar dezenas de projetos fracassados — esses quatro e muitos outros — eu consigo ver um padrão tão claro que chega a ser frustrante. Frustrante porque ele se repete, projeto após projeto, década após década.

Lidando com pressão de prazos: o que fazer na prática

Eu sei que é fácil falar 'não ceda à pressão de prazo' quando você não é o dev que vai ser demitido se não entregar. A questão é mais nuançada. Prazo existe. Negócio precisa shipar. A pergunta certa não é 'como eliminar pressão' — é 'como comunicar risco de forma que a gestão consiga tomar decisões informadas'.

Na minha experiência, gestores que pressionam prazo geralmente não entendem o trade-off que estão fazendo. Eles acham que estão escolhendo entre 'entregar em março' e 'entregar em junho'. Na cabeça deles é só velocidade. O que você precisa mostrar é que a escolha real é entre 'entregar em março com 40% de chance de cair em produção no primeiro dia' e 'entregar em abril com 5% de chance'.

Cultura de engenharia que previne fracassos

Se eu pudesse mudar uma coisa na indústria de software seria a cultura em torno de dizer 'não'. Nos projetos que fracassaram, sempre tinha alguém que sabia que ia dar errado. Na Boeing, engenheiros escreveram e-mails explícitos sobre o MCAS. No Healthcare.gov, técnicos alertaram sobre a falta de testes. No Cyberpunk, devs sabiam que o jogo não estava pronto.

Em todos os casos, essas vozes foram ignoradas ou abafadas. A cultura organizacional não dava espaço pra bad news. E quando a cultura pune quem traz más notícias, você para de receber más notícias — não porque os problemas desapareceram, mas porque as pessoas pararam de reportar.

Aplicando no seu projeto

Você provavelmente não está construindo o próximo Healthcare.gov. Mas o seu side project, a startup onde você trabalha ou o sistema interno da empresa onde você é dev — todos estão sujeitos aos mesmos padrões de fracasso em escala menor.

Scope creep acontece no seu projeto quando o PM adiciona 'só mais uma featurezinha' toda sprint. Crunch acontece quando 'precisamos shipar isso até sexta' vira rotina. Deploy sem teste acontece quando 'é só uma mudança no CSS, não precisa testar'. São os mesmos padrões. Escala diferente, consequência diferente, mas dinâmica idêntica.

Minha recomendação concreta: leia esses casos de fracasso com seu time. Discuta em retrospectiva. Pergunte 'estamos fazendo alguma dessas coisas?'. Na minha experiência, quando o time reconhece o padrão, fica muito mais fácil resistir à pressão de repeti-lo.

Se quiser explorar o lado técnico dos bugs que esses fracassos produziram, os 10 bugs que mudaram a história da tecnologia mostram o resultado final quando a cultura falha. E pra ver o outro lado — como organizações que levam software a sério realmente testam — tem o artigo sobre como sistemas críticos são testados na aviação, medicina e finanças.