前几天一朋友跟我吐槽，他那个项目已经delay了，领导的第一反应永远是加人。我挺想跟他说一句：管理学里最反直觉的一条，可能就是"晚了别加人"。
新人进来不是马上能顶上，得有人带。能带人的通常是最值钱的那几个老手，等于为了救火，先把最能灭火的人抽去当培训师。人再多一点，沟通链路是按平方往上涨的，三五个人还能喊一嗓子，十几个人光对齐目标就得耗掉半天。原本就紧的排期，被这些看不见的成本一口口啃掉。
更吊诡的是…，加人常常被用来盖住真正的问题。项目慢，是目标没对齐，还是流程在某个节点卡死了，还是分工本来就是一笔糊涂账？这些不理顺，多塞几个人进去，混乱只会更显眼。人越多，扯皮的界面就越多。
所以下次再听见"再加两个人赶一赶"，先别急着点头。有时候瘦瘦身，反而跑得快。
补充个出处，这条最早是 Fred Brooks 在 1975 年《人月神话》(The Mythical Man-Month) 里系统讲过的，他那句常被引用的话是：给一个已经延误的软件项目加人，只会让它更延误。书里最狠的比方是，让九个女人一个月生出个孩子，有些工作的时长就是不可压缩的。
不过帖子里"沟通链路按平方往上涨"那个判断，得加个前提才站得住。Brooks 算的是两两之间的沟通渠道数，n 个人对应 n(n-1)/2 条，确实随人数平方增长。但这成立的条件是任务高度耦合、彼此依赖。活儿要能拆成互相独立的块，搬砖、流水线那种，加人基本是线性的，人多了就真快了。
所以"晚了别加人"更准确的范围应该是：在任务不可随意切分、新人得靠老手带着上手的工作里，加人才会越加越慢。你朋友那个项目，先判断它属于哪一类比较要紧。
这条在《人月神话》里叫布鲁克斯定律，你那朋友领导八成没翻过这本书。
补一个细节：沟通成本你说的"按平方涨"其实更准的算法是 n(n-1)/2，也就是每个人要跟其他人对齐的接口数。十个人就是四十五个潜在接口，比多数人直觉里想的还吓人。
我前阵子围观过一个项目，慢不是因为人不够，是同时铺了七八个方向，人人都在等别人的半成品。那种局加人纯粹火上浇油，后来把并行的活砍掉一半，两周就收了尾。
你朋友那领导怕是把人当复制粘贴，以为多来几个能提速。说真的…，老手被抽去带人，等于把最能灭火的先调走，添乱嘛。
读到"瘦瘦身反而跑得快"那句，心里微微一动。人堆得多了，连一声叹息都要绕好几道弯，才传到该听见的人耳朵里。我偏爱那种小小的一伙人，三两人，不说话也不尴尬，比十几张嘴的对齐会要踏实些。
前几年待过一个小团队，五个人时干活比后来扩到十五个还利索。活儿一多就先堆人，结果最能干的那几个全去带新人了，正经活反倒没人碰。说到底，人不是越多越顶用，沟通那点损耗看不见但真吃进度。
你朋友这领导的反应太典型了。我以前待过一个小团队，本来五六个人跑得挺顺，上面一看进度紧就往里塞人，结果带新人的带新人、对齐目标的对齐目标，最能干活的那几个老手整周都在开会。后来把活儿边界重新砍了砍，反而轻快了。是呢，有时候不是人不够，是框没画清，外面看着是慢，根子上还是分工那笔账没理顺。
楼主说的这条，说白了就是 Brooks’s Law —— Fred Brooks 在 1975 年那本 The Mythical Man-Month 里写下的结论。不过有一处值得补一刀：Brooks 自己留了前提，这条定律之所以成立，是因为软件开发里大量任务"不可完美切分"(non-partitionable)。
要是活儿本身能切得干净，比如一大批互相独立的数据录入、或者纯体力的搬砖，加人就是近乎线性地提速，根本不存在"越加越慢"。所以"晚了别加人"更像一条经验法则，不是铁律，得先看瓶颈卡在协调成本还是单纯人手不够。
再说"沟通链路按平方涨"，数学上没错，n(n-1)/2 确实是 O(n²)，但 Brooks 原著里真正拖垮项目的其实是新人那段 ramp
那个"沟通链路按平方涨"说得太准了，我前阵子看一个组从6个人扩到快20，光是对齐进度每周就能吞掉两天，真不如先把卡住的节点揪出来。
以前带过十几个人的小团队，后来砍到五个，反而每周都能准点交活。
我年轻的时候也以为人不够就加人，后来见得多了才明白没那么简单。前几年赶一个项目，一吃紧上头就往里塞新人，最能顶事的那几个人反倒被拽去当师傅，活儿没人干，新人也带得半生不熟。
那会儿
慢在哪得先看清，是目标没对齐还是流程卡死，这个不理顺，人越多越像赶集。这事吧你那朋友那领导，怕是宁肯往里塞人，也不愿蹲下来看看病根在哪儿。
我朋友前段时间也遭了这罪，他们组从五个人扩到十二个，进度反而往后缩 后来他算了笔账，光是把"这活归谁"对齐，每周就能吃掉两天。
你提到"加人常常是为了盖住真问题"那点，我见过的次数数不清。以前待过一个小团队，项目卡死，老板二话不说塞进来三个人，结果新人每天最大的KPI就是证明"卡住的不是我"。问题该卡哪还卡哪，只是多了一层"我们在努力"的戏。人越多，扯皮的舞台越大，跑起来反而更喘。
帖子里说"最能灭火的人被抽去当培训师"，这个画面挺准的。不过我观察到的另一面是，有些组加人没崩，是因为平时就把知识摊开了，内部wiki、onboarding清单、代码评审都在跑。新人翻文档就能上手大半，不用独占老手时间。
反倒是那种leader脑子是唯一知识库的组，一加人立刻塌。所以"加人变慢"到底是加人的锅，还是平时没做知识沉淀、在救火时一次性爆债？我更倾向后者。见过两个规模相近的组，一个文档齐全一个全靠口口相传，加同样两个人，产能差距能拉开两周以上。
之前待过的组就这样，一delay就加人，老手全抽去带新人，活反倒更没人干了。