读《人月神话》：为什么加人反而更慢

《人月神话》出版于 1975 年，讲的是 IBM 开发 OS/360 的教训。半个世纪过去，书里那些结论依然扎人。

核心那句话

人月（man-month）是一种危险的度量单位，人和月并不能简单互换。

直觉是这样的：一个任务需要 10 个人月，那就是 10 个人做 1 个月，或者 1 个人做 10 个月。Brooks 说这中间的关系是非线性的，而且方向往往是反的。

原因是三件事叠在一起：

• 沟通成本随人数平方增长 —— n 个人之间的沟通路径是 n(n-1)/2，人一多，开会、对齐、同步消息就会吃掉大量时间
• 任务本身不可无限拆分 —— 有些工作只能串行做，加人也没用
• 新人需要学习成本 —— 把新人培养到能独立产出，这段时间原本干活的人还得停下来带他

所以项目延期时加人，短期一定是更慢的。

概念的完整性

书里我最喜欢的一句是关于设计权的：

概念的完整性要求设计必须由一个人、或者非常少数相互协调的人完成。

这解释了为什么很多「委员会设计」的东西用起来别扭 —— 每个功能单独看都有理由，合起来却没有统一的视角。

对今天的启示大概就是：架构决策要收敛到少数人手里，其余人负责实现和反馈。民主适合做取舍的讨论，不适合做设计的决定。

关于「第二系统效应」

第二条系统是一个团队做第二个版本时的东西，它往往会变成灾难。因为做第一版时受限于时间、预算、对领域的不了解，大家都有一堆「当时想做但没做」的清单。到了第二版，所有想加的东西一次性全塞进去。

第二系统效应：第二个系统是设计师们所设计的最危险的系统。

这条在软件以外也成立。第一次做某事时懂得少，反而克制；第二次自以为懂了，就开始无止境地加功能。

值得一读吗

值得，尤其是如果你在带项目或做架构决策。书的篇幅不长，是讲稿整理出来的，读起来像在听一个很会讲故事的老人复盘。

不过也要注意它的语境：1975 年的大型机项目，协作方式和今天差别很大。Brooks 在 1995 年的二十周年版里自己也承认，有些建议（比如「外科手术式团队」）在实践中很难推行。读它的判断框架，而不是直接抄结论。