As causas estruturais do fracasso em projetos de TI: a ignorância gerencial recorrente e seu custo

baeba · 2025-11-26T09:56:15+09:00

Resumo geral: Tema central: O fracasso de projetos de TI não decorre de desafios técnicos, mas da 'ignorância deliberada' da alta gestão e da arrogância de se recusar a aprender com fracassos do passado. Principais números: Nos últimos 20 anos, os gastos globais com TI triplicaram (US$ 5,6 trilhões), mas a taxa de sucesso permaneceu estagnada, enquanto 75% do orçamento é consumido apenas pela manutenção de sistemas legados. Casos principais: A falha gerencial generalizada do sistema Phoenix, do Canadá, e o encobrimento antiético do caso Horizon, no Reino Unido, não são simples 'erros (Blunder)', mas sim 'maldade administrativa (Administrative Evil)'. 1. Introdução: a taxa de fracasso não melhora apesar do investimento massivo Estagnação da eficiência frente ao investimento: Desde 2005, os gastos mundiais com TI saltaram de US$ 1,7 trilhão para US$ 5,6 trilhões em 2025, mais que triplicando. No entanto, apesar do enorme volume de recursos investidos, a taxa de sucesso de projetos de software não mostrou melhora clara nos últimos 20 anos. Cautela com a ilusão em torno da IA: Muitos executivos esperam que ferramentas de IA ou assistentes de programação como Copilot tornem grandes projetos bem-sucedidos, mas o autor é cético quanto a isso. A IA não consegue resolver a complexidade da engenharia de sistemas, os trade-offs financeiros e, acima de tudo, a 'política organizacional (Organizational Politics)' dentro dos projetos. Fracasso como fenômeno universal: Falhas de software ocorrem indiscriminadamente, independentemente de país, porte da empresa ou natureza lucrativa/não lucrativa, e isso decorre não de simples erros técnicos, mas da 'falta de imaginação humana' e de 'metas irreais'. 2. Desenvolvimento: análise aprofundada dos tipos e causas do fracasso 2.1. A repetição dos 'erros (Blunder)' e a recusa em aprender Diferença entre fracasso e erro: O fracasso como 'destruição criativa (Creative Destruction)', ao desafiar limites técnicos, deve ser bem-vindo. Porém, a maioria dos fracassos em TI não passa de 'erros estúpidos (Blunder)', repetindo causas já documentadas há décadas, como ausência de gestão de risco e subestimação da complexidade. A arrogância da gestão: Gerentes de projeto tendem a afirmar que seu projeto é "especial e único", ignorando casos de fracasso anteriores e os dados existentes. Isso não é simples ignorância, mas 'ignorância deliberada (Willful Ignorance)', em que sinais de risco são conscientemente ignorados. A armadilha dos sistemas legados: Organizações nos EUA gastam mais de US$ 520 bilhões por ano apenas com a manutenção de sistemas legados, o equivalente a 70% a 75% de todo o orçamento de TI. Por medo de falhar na substituição, a modernização é adiada até que o sistema entre em colapso físico (como no mainframe do Departamento de Veículos da Louisiana) ou deixe completamente de fazer sentido do ponto de vista econômico. 2.2. Detalhes dos principais casos de fracasso e seus efeitos em cadeia Sistema de folha de pagamento Phoenix, do Canadá: Erro inicial de avaliação: Ao adotar uma solução pronta (PeopleSoft), tentou-se customizá-la para 80.000 regras salariais e 105 acordos coletivos de trabalho. O preço dos cortes no orçamento: Para executar o projeto com menos de 60% do orçamento proposto pelo fornecedor, foram forçadas a remoção de funções essenciais da folha, a redução de testes e a eliminação de um teste-piloto indispensável. Resultado: Entrou em colapso logo após entrar em operação em 2016. Causou sofrimento financeiro por pagamentos incorretos a funcionários (sendo apontado, em alguns casos, como fator em suicídios). Custo: O orçamento inicial era de 310 milhões de dólares canadenses, mas os custos de recuperação e correção hoje já ultrapassam 5,1 bilhões de dólares canadenses (cerca de US$ 3,6 bilhões). Escândalo Horizon, dos Correios do Reino Unido: Falha técnica: Um bug no middleware do sistema fornecido pela Fujitsu gerou erros de discrepância financeira. Encobrimento organizacional: Mesmo sabendo dos defeitos do software, a gestão os encobriu e, em vez disso, acusou 3.500 gerentes de agência postal de peculato e roubo. 900 foram condenados e presos. Custo social: As vítimas enfrentaram falência, divórcios, prisão e suicídio. O caso é registrado como o pior fracasso de TI e erro judiciário da história do Reino Unido. 2.3. Decisão automatizada e 'maldade administrativa' A violência dos algoritmos: Os sistemas MiDAS, do estado de Michigan (detecção de fraude em seguro-desemprego), e Robodebt, da Austrália (detecção de fraude em benefícios sociais), tomavam decisões baseadas apenas em algoritmos, sem supervisão humana. Dezenas de milhares de cidadãos inocentes foram tratados como criminosos, mas os burocratas recusaram compensação ou evitaram responsabilização mesmo após a comprovação de falhas no sistema. Os riscos da adoção de IA: Essa 'maldade administrativa (Administrative Evil)' tende a se agravar à medida que a IA se aprofunda na infraestrutura pública. A UE introduziu o 'direito de exigir explicação', mas globalmente continua urgente definir transparência e responsabilização sobre algoritmos. 3. Conclusão: soluções e os desafios para a comunidade de TI Metodologias (Agile/DevOps) não são uma chave mestra: Há relatos de que a taxa de fracasso de projetos Agile pode chegar a 65%, mostrando que a metodologia em si não garante sucesso. Sem liderança consistente e disciplina organizacional, qualquer nova metodologia fracassa. Avaliação honesta de riscos e responsabilidade ética: Antes de iniciar um projeto, deve haver uma análise honesta de lacunas (Gap Analysis) sobre "o que se sabe e o que não se sabe". O conceito de 'IA centrada no ser humano (Human-centered AI)' deve ser expandido para todos os projetos de TI, incorporando à análise de custo-benefício os danos emocionais e financeiros que falhas do sistema podem causar aos usuários finais. Apelo por mudança de postura da alta gestão: Software é, por natureza, frágil (Fragile) e complexo. A alta gestão deve respeitar e apoiar o desenvolvimento de software não apenas como detentora do poder orçamentário, mas como responsável pelas consequências do fracasso. Interromper a repetição dos mesmos erros é o único caminho para que a indústria de TI saia de sua 'crise (Crisis)'.

(spectrum.ieee.org)

3 pontos por baeba 2025-11-26 | 1 comentários | Compartilhar no WhatsApp

Resumo geral:
- Tema central: O fracasso de projetos de TI não decorre de desafios técnicos, mas da 'ignorância deliberada' da alta gestão e da arrogância de se recusar a aprender com fracassos do passado.
- Principais números: Nos últimos 20 anos, os gastos globais com TI triplicaram (US$ 5,6 trilhões), mas a taxa de sucesso permaneceu estagnada, enquanto 75% do orçamento é consumido apenas pela manutenção de sistemas legados.
- Casos principais: A falha gerencial generalizada do sistema Phoenix, do Canadá, e o encobrimento antiético do caso Horizon, no Reino Unido, não são simples 'erros (Blunder)', mas sim 'maldade administrativa (Administrative Evil)'.

1. Introdução: a taxa de fracasso não melhora apesar do investimento massivo

Estagnação da eficiência frente ao investimento:
- Desde 2005, os gastos mundiais com TI saltaram de US$ 1,7 trilhão para US$ 5,6 trilhões em 2025, mais que triplicando.
- No entanto, apesar do enorme volume de recursos investidos, a taxa de sucesso de projetos de software não mostrou melhora clara nos últimos 20 anos.
Cautela com a ilusão em torno da IA:
- Muitos executivos esperam que ferramentas de IA ou assistentes de programação como Copilot tornem grandes projetos bem-sucedidos, mas o autor é cético quanto a isso.
- A IA não consegue resolver a complexidade da engenharia de sistemas, os trade-offs financeiros e, acima de tudo, a 'política organizacional (Organizational Politics)' dentro dos projetos.
Fracasso como fenômeno universal:
- Falhas de software ocorrem indiscriminadamente, independentemente de país, porte da empresa ou natureza lucrativa/não lucrativa, e isso decorre não de simples erros técnicos, mas da 'falta de imaginação humana' e de 'metas irreais'.

2. Desenvolvimento: análise aprofundada dos tipos e causas do fracasso

2.1. A repetição dos 'erros (Blunder)' e a recusa em aprender

Diferença entre fracasso e erro:
- O fracasso como 'destruição criativa (Creative Destruction)', ao desafiar limites técnicos, deve ser bem-vindo.
- Porém, a maioria dos fracassos em TI não passa de 'erros estúpidos (Blunder)', repetindo causas já documentadas há décadas, como ausência de gestão de risco e subestimação da complexidade.
A arrogância da gestão:
- Gerentes de projeto tendem a afirmar que seu projeto é "especial e único", ignorando casos de fracasso anteriores e os dados existentes.
- Isso não é simples ignorância, mas 'ignorância deliberada (Willful Ignorance)', em que sinais de risco são conscientemente ignorados.
A armadilha dos sistemas legados:
- Organizações nos EUA gastam mais de US$ 520 bilhões por ano apenas com a manutenção de sistemas legados, o equivalente a 70% a 75% de todo o orçamento de TI.
- Por medo de falhar na substituição, a modernização é adiada até que o sistema entre em colapso físico (como no mainframe do Departamento de Veículos da Louisiana) ou deixe completamente de fazer sentido do ponto de vista econômico.

2.2. Detalhes dos principais casos de fracasso e seus efeitos em cadeia

Sistema de folha de pagamento Phoenix, do Canadá:
- Erro inicial de avaliação: Ao adotar uma solução pronta (PeopleSoft), tentou-se customizá-la para 80.000 regras salariais e 105 acordos coletivos de trabalho.
- O preço dos cortes no orçamento: Para executar o projeto com menos de 60% do orçamento proposto pelo fornecedor, foram forçadas a remoção de funções essenciais da folha, a redução de testes e a eliminação de um teste-piloto indispensável.
- Resultado: Entrou em colapso logo após entrar em operação em 2016. Causou sofrimento financeiro por pagamentos incorretos a funcionários (sendo apontado, em alguns casos, como fator em suicídios).
- Custo: O orçamento inicial era de 310 milhões de dólares canadenses, mas os custos de recuperação e correção hoje já ultrapassam 5,1 bilhões de dólares canadenses (cerca de US$ 3,6 bilhões).
Escândalo Horizon, dos Correios do Reino Unido:
- Falha técnica: Um bug no middleware do sistema fornecido pela Fujitsu gerou erros de discrepância financeira.
- Encobrimento organizacional: Mesmo sabendo dos defeitos do software, a gestão os encobriu e, em vez disso, acusou 3.500 gerentes de agência postal de peculato e roubo. 900 foram condenados e presos.
- Custo social: As vítimas enfrentaram falência, divórcios, prisão e suicídio. O caso é registrado como o pior fracasso de TI e erro judiciário da história do Reino Unido.

2.3. Decisão automatizada e 'maldade administrativa'

A violência dos algoritmos:
- Os sistemas MiDAS, do estado de Michigan (detecção de fraude em seguro-desemprego), e Robodebt, da Austrália (detecção de fraude em benefícios sociais), tomavam decisões baseadas apenas em algoritmos, sem supervisão humana.
- Dezenas de milhares de cidadãos inocentes foram tratados como criminosos, mas os burocratas recusaram compensação ou evitaram responsabilização mesmo após a comprovação de falhas no sistema.
Os riscos da adoção de IA:
- Essa 'maldade administrativa (Administrative Evil)' tende a se agravar à medida que a IA se aprofunda na infraestrutura pública.
- A UE introduziu o 'direito de exigir explicação', mas globalmente continua urgente definir transparência e responsabilização sobre algoritmos.

3. Conclusão: soluções e os desafios para a comunidade de TI

Metodologias (Agile/DevOps) não são uma chave mestra:
- Há relatos de que a taxa de fracasso de projetos Agile pode chegar a 65%, mostrando que a metodologia em si não garante sucesso. Sem liderança consistente e disciplina organizacional, qualquer nova metodologia fracassa.
Avaliação honesta de riscos e responsabilidade ética:
- Antes de iniciar um projeto, deve haver uma análise honesta de lacunas (Gap Analysis) sobre "o que se sabe e o que não se sabe".
- O conceito de 'IA centrada no ser humano (Human-centered AI)' deve ser expandido para todos os projetos de TI, incorporando à análise de custo-benefício os danos emocionais e financeiros que falhas do sistema podem causar aos usuários finais.
Apelo por mudança de postura da alta gestão:
- Software é, por natureza, frágil (Fragile) e complexo. A alta gestão deve respeitar e apoiar o desenvolvimento de software não apenas como detentora do poder orçamentário, mas como responsável pelas consequências do fracasso.
- Interromper a repetição dos mesmos erros é o único caminho para que a indústria de TI saia de sua 'crise (Crisis)'.

1 comentários

baeba 2025-11-26

Resumo das reações nos comentários do Hacker News

1. Ausência de implantação gradual e de estratégia de escala (Start Small)

Fracasso inevitável do modelo “big bang”: implantar um projeto em escala nacional de uma só vez é um ato suicida. É essencial expandir com validação sequencial em unidades menores (vilarejo → cidade → país).
Diferença entre produto e sistema: ao contrário de um produto único como o WhatsApp, sistemas corporativos complexos precisam suportar grande escala desde o início, então a abordagem deve ser diferente.
Solução central: o princípio de “construir pequeno e adicionar funcionalidades após validar” está sendo ignorado.

2. Incompetência da gestão e fuga de responsabilidade (Management Issues)

Estrutura de poder sem responsabilização: quando o projeto falha, os desenvolvedores tentam remediar com horas extras, enquanto a gestão, que tomou as decisões, não assume responsabilidade ou até recebe bônus — uma estrutura contraditória muito criticada.
Falta de entendimento técnico: impor prazos irreais ignorando a dificuldade técnica e uma cultura hierárquica que se recusa a ouvir “más notícias” impedem a resolução dos problemas.
Decisões políticas: há uma tendência de escolher soluções com base em política interna ou na relação com fornecedores externos (como rebates), e não na adequação técnica.

3. Requisitos incontroláveis e complexidade (Complexity & Scope Creep)

Ausência de simplificação prévia dos processos: como no caso do Phoenix Project, tentar informatizar diretamente 80 mil regras de folha de pagamento sem antes organizá-las é uma causa raiz. Um processo offline bagunçado só produz um sistema digital bagunçado.
Mudanças frequentes de requisitos: a expansão do escopo (scope creep) causada por mudanças de ideia da gestão ou do cliente durante o projeto afunda a iniciativa em um pântano.

4. Cultura dos desenvolvedores e incentivos errados (Developer Culture)

Desenvolvimento guiado pelo currículo (RDD): adotar à força tecnologias da moda (frameworks) que favorecem futuras trocas de emprego, em vez do sucesso do projeto, aumenta a dívida técnica.
Ruptura no aprendizado: a cultura de mudanças frequentes de emprego (job hopping) em ciclos de 2 a 3 anos impede que desenvolvedores vejam o fracasso de longo prazo do próprio código e tirem lições disso.
Obsessão por reinventar: uma prática ineficiente de reescrever tudo do zero para satisfação pessoal, em vez de aproveitar soluções existentes já validadas.

5. A natureza particular da engenharia de software (Engineering Nature)

Ausência de restrições físicas: diferentemente de construção civil ou hardware, o software não tem restrições físicas e acaba permitindo complexidade infinita, o que leva à perda de controle.
Falta de aprendizado com o passado: outras áreas da engenharia analisam falhas (por exemplo, o colapso de pontes) de forma rigorosa e registram lições, mas a indústria de software repete erros passados com a mentalidade “desta vez é diferente”, em um estilo de desenvolvimento tipo YOLO.