如果有人问你，在 IT 系统的建设过程中，当项目进度存在滞后的风险，靠堆人能解决问题吗？相信多数人的回答都是：不能。
那，是否真的是这么绝对呢？
“当意识到进度的偏移时，下意识（以及传统）的反应是增加人力。这就像使用汽油灭火一样，只会使事情更糟。越来越大的火势需要更多的汽油，从而进入了一场注定会导致灾难的循环。” --《人月神话》
针对人月（工作量单位，指 1 个人在 1 个月内的产出），时间和人数是否存在真的换算关系？书中给出了 4 类关系，如下图所示：
不需要交流的事：比如厂线上的计件活动，他是可以通过堆人的方式，把所需时间降下来。各类标准化的活动，都可以按此曲线解释。
无法分解的事：增加人手也无法追赶进度的事，典型的十月怀胎，无论是多少人，都得是十个月。这类事通常是不以人的意志为转移的。
少量沟通的事：仅需要少量沟通，就能快速复制的事。这个场景与第一个场景的区别在于，这类事是非标准化的，还存在沟通，所以它的下限会比较高，也就是不能堆太多的人。人一多，沟通成本就上来了。
大量沟通的事：基本上 IT 的活动都是这类场景，需要大量的沟通对齐，所以会说 IT 的事堆人是没什么用的。
前面两种情况在 IT 活动中基本不存在，所以不讨论，本文主要讨论后两种情况在 IT 中的实践。
先聊聊第三种情况：少量沟通的事，在 IT 的场景中，什么情况下会出现呢？这时候适当堆人其实是能解决问题的。这种场景的适用前提是：非标准化的少量沟通。
背景：某团队在 UAT 环境中，遗留了近 200 个 P2 级别的 BUG（一般问题及优化建议，不影响主流程使用。嗯，我们业务比较友好，所以不用计较为什么有这么多还能上线），业务希望在上线后的 1 周内修复完成。但现在研发团队只有 8 个人，还需要负责后续迭代的研发，按当下的资源肯定是无法按期交付的。
解决方案：经过团队内部评估，可以通过堆人来解决这个问题。原因是这些 BUG 都是比较简单就能修复好的，不会有太大的影响。所以就紧急抽调了同一个产品线上的其他其他人员来支援（注意这个前提，是同一产品线上的人，他们对系统同样熟悉，只是在做别的版本），共来了 10 个人，配合着每日严格的任务规划，还是把这 200 多个 BUG 完全修复并交付上线。
大力还是能出奇迹的，只要条件和方法合适。解决方案的选择，需要理解前提条件。
再聊聊第 4 种情况：大量沟通的事。这个是 IT 团队大量存在的问题。敏捷研发过程强调的就是沟通。那么，在这种情况下，如果项目滞后，存在延期风险，堆人显然不是合理的方式了。
“向进度落后的项目中盲目增加人手，只会使进度更落后” --《人月神话》
背景：在某个 730 版本的研发过程中，原计划需要 2 个迭代来完成，但是第一个迭代由于各种原因有延期，需要在第二个迭代中追赶回来，由于需求已经澄清，各开发也只有自己了解自己的 Story 内容，这个时候堆人是解决不了问题的。
解决方案： 没有什么好的解决方案，而且不能给团队传导更多的压力，让士气变得更低落。向全员透明情况，通过加班，把时间变多来，集体攻坚，让进度赶上来。负责人需要提供好各类后勤保障。当然，这不是一个长期的解决方案。（如果你有更好的解决方案，可以沟通）
在这种场景下，管理应该反思为什么没有及时发现风险。因为延期不是突然发生的，它一定是在某种外部变化下，人员去处理其他的其他的问题了，或者是某个前置依赖的 Story 延期了，导致后续一连串的延期，又或者只是某个人员的请假，风险没有被及时识别出来。
不论是哪种情况，都不能盲目乐观。不能期待一切都将运作良好，每一项任务仅花费它所 “应该” 花费的时间。
就像第一个例子，虽然我们及时解决了问题，但中间还是花了 1 天的时间让团队做好交接。第二个例子，最终还是 Delay 了。
做好前期规划，关注团队变化的细节，给排期预留一定的冗余时间。尊重团队实际产能。才能让延期的事少发生。
魔幻的延期，需要未雨绸缪。
共勉。
