System/360操作系统：从500人日到5000人年
IBM在1960年代开发System/360操作系统时，最初估算需要500人日。这个估算基于核心功能的代码量预测，看起来很科学。但最终这个项目花了5000人年——是原计划的365倍。
布鲁克斯作为项目经理，亲历了这个估算是怎么失控的。最初的500人日只考虑了编写代码的工作量，完全没有考虑测试、文档、系统集成、版本管理这些工作。更致命的是，他们假设人月可以互换——如果一个人需要500天，那么500个人只需要1天。
当项目开始延期时，管理层的第一反应是加人。从50人加到200人，再加到500人。每次加人都伴随着"这次一定能追上进度"的乐观预期。但现实是，每增加一个人，现有团队成员都要花时间来培训新人，沟通成本呈几何级数增长。
调用场景： 当你的软件项目开始延期，管理层提出"加人"方案时，这个案例提醒你为什么这种直觉性反应通常会让情况更糟。
巴别塔项目：概念完整性的缺失
布鲁克斯用巴别塔的故事类比大型软件项目的失败。巴别塔项目不是因为技术能力不足而失败，而是因为缺乏统一的语言和概念框架。
在System/360项目中，不同的小组有不同的设计理念。存储管理组认为效率最重要，用户界面组认为易用性最重要，系统组认为稳定性最重要。每个理念都有道理，但拼在一起就是灾难。最终的系统功能强大但概念混乱，用户需要掌握三套不同的操作逻辑才能使用。
布鲁克斯总结说，宁要一个人设计的平凡系统，也不要委员会设计的华丽系统。概念完整性比功能丰富性更重要。这不是反对团队协作，而是强调需要有统一的架构愿景。
调用场景： 当你的产品功能越来越多，但用户抱怨"越来越难用"时，这个案例帮你理解为什么功能堆砌不等于产品价值。
外科手术队vs民兵组织
布鲁克斯对比了两种团队组织方式：外科手术队和民兵组织。民兵组织是大多数软件团队的默认模式——每个人都是战斗员，人人平等，任务平均分配。这看起来很公平，但效果很差。
外科手术队的模式是：一个首席程序员负责核心设计和关键代码，其他人提供支持——有人负责测试，有人负责文档，有人负责工具，有人负责代码审查。首席程序员像外科医生一样专注于最关键的工作，不被琐事干扰。
布鲁克斯在后期项目中试验了这种模式，发现效果显著。一个10人的外科手术队产出质量，往往超过50人的传统团队。关键不是技术能力的差异，而是组织结构的效率。
调用场景： 当你需要重新组织开发团队，或者评估是否要"扁平化管理"时，这个案例提供了具体的参考模式。
第二系统效应：OS/360的功能膨胀
System/360的设计师们都参与过之前的成功项目，满怀信心地要做一个"更好的系统"。他们把第一个系统中所有想做但没做的功能，统统塞进了新系统。
结果是一个功能极其丰富但复杂度失控的系统。布鲁克斯称之为"第二系统效应"——设计师在第二个系统中倾向于过度设计，加入太多花哨但非必要的功能。
这个案例的价值在于，它揭示了成功经验如何变成下一次失败的原因。第一次成功给团队带来自信，但也带来了对复杂性的低估。
调用场景： 当你的团队刚完成一个成功项目，开始规划下一个"更大更好"的系统时，这个案例提醒你谨防过度设计的陷阱。
这些案例的共同价值在于：它们不是理论推演，而是真实项目的血泪教训。每个场景都能帮你识别现实中的类似情况，避免重复同样的错误。