文章指出，尽管全球IT支出在过去20年增长了三倍，但软件开发失败率并未显著改善。软件故障普遍存在于各国及各类型组织中，且随着软件普及，失败带来的商业和社会成本持续攀升。这反映出IT管理在吸取教训方面存在重复性错误。

软件失败与IT管理的重复错误

核心问题
过去二十年，全球IT支出从2005年的1.7万亿美元激增至2025年的5.6万亿美元，但软件项目的成功率并未显著提升。软件故障不分国界、规模或行业，其带来的商业和社会成本随着软件渗透到生活各个领域而持续增长。尽管AI工具和编程助手被寄予厚望，但在可预见的未来，AI难以解决大型IT项目中系统工程、财务管理与组织政治等复杂问题。

典型案例：加拿大Phoenix薪酬系统
2016年上线的Phoenix系统耗资3.1亿加元，旨在整合105项工会协议和80,000条薪酬规则，却因以下管理失误酿成灾难： - 过度乐观：团队试图以低于供应商预算60%的成本完成任务，削减了关键测试和人员配置。 - 持续影响：九年间，43万公务员中70%遭遇薪资错误，甚至导致一名员工因财务压力自杀。截至2025年3月，仍有34.9万笔错误未解决，政府承诺的整改期限一再推迟。

失败的根本原因
1. 重复错误：Phoenix是加拿大政府第二次薪酬系统改革，首次失败（1995年）的教训被忽视，管理者声称"项目特殊性"使其豁免于历史经验。 2. 风险低估：牛津大学研究表明，IT项目是成本风险最高的领域。美国企业每年花费5200亿美元维护遗留系统，80%的高管承认旧技术阻碍创新，但替换成本更高且风险巨大。 3. 方法论局限：尽管敏捷开发（Agile）和DevOps被广泛采用，但前者失败率据称达65%，后者90%未达预期。成功实施需要领导力、文化变革和持续投入——这些恰恰是组织长期缺乏的。

系统性顽疾
- 管理幻觉：IT管理者常以"项目独特性"为由拒绝借鉴经验，导致类似凤凰系统的"财务飓风"频发。 - 伦理缺失：算法自动化决策的失败案例（如美国密歇根州失业系统误判、澳大利亚Centrelink福利系统错误指控）暴露了对技术的盲目信任，后续补救中官僚体系推诿责任。 - 成本忽视：项目评估极少考虑用户因系统故障承受的财务与情感压力，加剧了社会代价。

解决路径
1. 管理变革：高层需正视软件开发的复杂性，提供充足资源并建立问责制。 2. 风险透明化：诚实地评估风险而非合理化，对供应商承诺保持警惕。 3. 伦理前置：在AI等新技术整合中，必须优先考虑对人类的影响，推行"以人为本的设计"。 4. 创新失败观：允许探索性失败，但杜绝因傲慢导致的重复错误——正如西塞罗所言："犯错是人之常情，执迷不悟才是愚蠢。"

结语
IT行业亟需从"软件危机"（1968年提出的概念）的循环中跳出。若不改变，随着AI与关键系统深度融合，失败代价将呈指数级增长。真正的进步不在于避免所有错误，而在于不再重蹈覆辙。

评论内容总结

1. 项目失败的原因分析

• 领导力与责任缺失：多位评论者认为项目失败主要源于领导层缺乏责任感和决策失误。

  • "Hot take: It's not technical problems causing these projects to fail. It's leadership and accountability (well, the lack of them)." (apercu)
  • "Software projects fail because humans fail." (0xbadcafebee)

• 架构与需求复杂性：部分评论指出过度定制和需求膨胀是根源。

  • "Phoenix project executives believed they could deliver... 80,000 pay rules spanning 105 collective agreements." (x0x0)
  • "Managing software requirements... is by far the hardest part." (nacozarina)

2. 行业共性问题

• 重复错误与经验忽视：软件行业缺乏对历史教训的总结，硬件领域则更注重传承。

  • "While hardware folks study past failures, software folks do not." (BirAdam)
  • "SV’s endemic ageism... shuns experience." (ChrisMarshallNY)

• 方法论争议：评论者对敏捷开发、工具和流程的有效性持不同看法。

  • "The lesson isn’t 'better methodologies'... it's 'don’t do big software projects'." (MattRogish)
  • "Universal style enforcement delivers results." (exabrial)

3. 技术与管理的矛盾

• 技术理想 vs. 现实约束：开发者追求完美，但业务需求导致妥协。

  • "Devs see code as artwork... hard to have critical conversations." (exabrial)
  • "Enterprise software sucks because it adapts to oddball requirements." (MattRogish)

• 资金与干预问题：高预算项目易受非技术因素干扰。

  • "Big money makes stakeholders feel entitled to get in the way." (John23832)

4. 未来与解决方案建议

• AI的潜在影响：部分评论担忧AI加剧问题，少数认为可优化管理。

  • "AI won’t make this better, but worse." (mdavid626)
  • "Use AI to replace managers, not developers." (amai)

• 监管与标准化：提议通过法律或规范约束项目质量。

  • "Create laws with consequences to ensure project success." (0xbadcafebee)
  • "Software lacks professional licensing like engineering." (oldandboring)

5. 少数乐观观点

• 软件质量进步：有评论认为当前软件整体可靠性显著提升。
  • "Software today is the highest quality ever... I trust my phone as my sole payment method." (827a)

关键分歧点

• 失败主因：技术复杂性 vs. 管理失效 vs. 人类固有缺陷。
• 解决方案：加强流程管控 vs. 限制项目规模 vs. 引入外部监管。
• AI角色：风险源头 vs. 管理优化工具。

（注：所有评论均无评分数据，故未纳入认可度分析。）