项目已经延期，再加两名工程师只会更晚

这本书被引用最多的是一句话：向已经延期的软件项目增加人手，只会让它更晚。Fred Brooks 的这条经验，来自他在 IBM 管理 System/360 和 OS/360 的经历。

五十年过去，这句话在 FDE 常待的地方依然成立：客户的会议室里，截止日期已经错过，有人提议“再派两个人过去”。

做前线部署工程师（FDE），迟早会坐进这样的会议室。部署已经晚了三周，客户不耐烦，客户团队想加人来表示诚意。《人月神话》解释了这种本能为什么常常适得其反，也给了反驳所需的数字。

推荐读二十周年纪念版（Anniversary Edition，Addison-Wesley，1995）。据 Pearson 介绍，这一版原样保留了 1975 年初版的文章，新增了重新审视软件项目管理的文章，并收录了《没有银弹》（“No Silver Bullet”，1986）。

布鲁克斯定律：成本有两项，不是一项

Brooks 指出了两个原因。第一个容易看到：新人需要时间上手，而这段时间里，他们占用的恰恰是最了解项目的人的工时。第二个不容易看到：每多一个人，就多出几条沟通线路。

书中给出了计算团队沟通渠道数的公式 n(n − 1)/2。拿一个中等规模的项目试试：四名工程师有 4 × 3 / 2 = 6 条渠道。再加两人变成六人，就是 6 × 5 / 2 = 15 条。人数增加 50%，渠道增加到 2.5 倍。50 名程序员时，这个数字是 1,225。

再把这笔账放进一个假设场景。你在给客户部署数据管道，项目已经晚了三周，公司又派来两名新工程师。

第一周，你坐在那里讲解客户的 schema、申请权限的流程，以及为什么另一张表绝对不能碰。第二周，他们开始写代码，但每个决定现在都要经过 15 条渠道，而不是 6 条。

到第三周，项目仍然一天都没有追回来。

所以在客户那里，第一件事是带着这笔账回到会议上，提出另一个方案：砍掉下一个里程碑用不到的内容，让现有团队保持专注。

外科手术团队：围绕最强的人集中力量

第二个值得记住的观点是“外科手术团队”。由一名技术精湛的首席程序员亲自编写关键部分，其他人都担任辅助角色。Brooks 把这一模式和一个直白的观察放在一起：“优秀”程序员的生产率是平庸程序员的五到十倍。

很多 FDE 项目其实已经这样运作，只是没人给它起名字：一个人掌握客户背景和集成架构的全貌。Brooks 给出的启示是：保护好这个人。

五到十倍是对程序员之间差距的总体观察，并非对某个人的测量；但如果首席工程师半天时间都在给新人重复讲解，浪费的恰恰是整个项目所依赖的那个人。

第二系统效应：第二版最危险

第三个观点适用于上线之后。Brooks 警告说，架构师设计的第二个系统，往往会塞满第一个系统推迟下来的功能。他称之为设计者一生中最危险的系统。

对 FDE 来说，这个陷阱通常在第一次部署成功后立刻出现。客户满意，你也有了信心，“下一版”清单突然就成了下一版的范围。重读这份清单，逐项问一句：它解决的是客户的问题，还是只是上次留下的情绪债？

砍范围也可能出错

理解了布鲁克斯定律，很多人在下一步栽跟头。最常见的错误，是在团队内部砍掉范围，却没有和客户商定新的里程碑。团队以为自己做对了，客户仍然期待原定日期交付全部功能，到交付那天，信任已经没了。

第二个错误，是拿这条定律当借口拒绝一切帮助。Brooks 说的是需要上手的新人和新增的沟通渠道，所以该问的是：派来的人会不会增加这两者中的任何一项。

稳妥的做法是写下来：哪些内容砍掉，新的里程碑日期是哪天，让客户确认之后，团队再调整计划。

适合谁读，按什么顺序读？

这本书适合有两年以上经验的工程师，尤其是开始负责项目、或者需要和客户讨论进度的人。InformIT 评价说，在软件项目管理领域，很少有书像它这样影响深远、经久不衰。即便如此，也不要把它当教科书读，书中很多例子来自大型机时代。

推荐顺序：先读讲定律和沟通公式的那篇，再读外科手术团队，然后是第二系统效应。《没有银弹》和 1995 年新增的内容留到最后，看 Brooks 如何重新评价自己的工作。

准备 FDE 面试时，不要只是引用布鲁克斯定律。讲一个你拒绝加人、转而砍范围的经历：项目晚了多久，你砍掉了什么，赶上了哪个里程碑。把这三点都写进简历，延期周数和达成的里程碑用具体数字写明。

一个 1975 年的公式不会让客户的项目跑得更快。但它给了你足够的理由，不让项目变得更慢。