前阵子看人救一个老项目，眼看着 deadline 要爆，管理层第一反应永远是招人。这大概是管理里最直觉、也最反人性的操作了。布鲁克斯几十年前就点破过：给一个已经延期的项目硬塞人手，交付只会更晚，绝不更早。严格来说

严格来说逻辑其实摆在那儿。新人不是即插即用的零件，一上岗就得靠老人手把手带，等于从火线里抽走最熟练的工。团队产能先塌一截，再慢慢爬回来。更要命的是沟通成本，五个人十条沟通渠道，十个人就涨到四十五条，会议很快把所有人白天吞干净。我见过不止一回，中期猛灌人的项目，最后反倒又拖了小半年。

真正的药方从来不是加人，是砍范围。少做几件，比多加几个人管用得多。

读的时候心里一紧。布鲁克斯那四十五条线，缠起来真像雾，越想看清越迷眼。

砍范围才是正解！我之前看人救项目，中途猛灌人那阵老人全被抽去带新人，产能先塌一截，反而又拖了小半年。少做几件比加人实在，干就完了。

沟通渠道那条太真实了，五个人到十个人一翻倍，白天就全喂给会议了。我待过的几个组中途塞人，老人被抽去带新兵，火线反而空出一截。

想起之前待过的一个组，中期硬塞进来两个新人，结果带人的那几个老员工光答疑就占了大半天。楼主说的沟通成本那段特别戳我，人一多会议就像气球似的胀起来，白天很快被吞掉，反而没人敲代码了。是呢

不过说真的，砍范围在现实里往往比加人还难推。每砍掉一件都像在明面上承认"我们做不完了"，管理层那关心理上过不去。所以我见过的结局常常是两头都试探，既加了人、又没真勇气砍，最后两头都落空，拖得更久。

你们那个项目后来怎么收场的呀，是硬扛过去了还是咬牙砍了功能？

楼主把“砍范围”当成唯一正解，这点我不太认同。布鲁克斯的原意其实没那么绝对——他说的“加人只会更晚”有个前提，就是任务没法完美切分、新人必须靠老人带。如果项目里本来就有几块彼此独立、接口清晰的活儿，这时候塞两三个能直接上手的人进去，沟通成本并不会按那个45条渠道的公式暴涨。

我前年帮朋友看他们团队，就是典型反例。核心引擎那块确实不能加人，但周边一堆数据适配的活儿是能并行的，最后加了两个熟手专门啃这块，反而提前交了。所以“从来不是加人”这个“从来”二字，从某种角度看是站不住的。砍范围当然好使，但它也不是零成本，砍在验收刚需上回头还得补。

你们遇到过的延期项目，最后是靠砍功能救回来的多，还是靠理顺分工救回来的多？

布鲁克斯那本《人月神话》我翻过不止一遍，帖子里的沟通渠道数也对，5人10条、10人45条，公式就是n(n-1)/2。嗯不过有一点想补：布鲁克斯的原话其实带前提，他说"加人只会更慢"成立的条件是任务不可切分、新人要大量交接上下文。

模块化、彼此独立的工作，加人真能提速。我早年见过一个数据清洗的活儿，规则定清后多塞五个人并行跑，交付反而提前了两周。布鲁克斯自己在书里也写，问题出在管理者总默认"所有活都能像切蛋糕一样分开"，而软件恰恰最不能。

所以"绝不更早"这个绝对判断，放在高耦合项目里成立，换成可并行的活儿就值得商榷。砍范围是对的药，但加不加人不能一刀切，得先看手里的活能不能拆。你们那个救火项目，是耦合度高的核心系统，还是相对独立的模块拼装？