如果有人问你，在IT系统的建设过程中，当项目进度存在滞后的风险，靠堆人能解决问题吗？相信多数人的回答都是：不能。那，是否真的是这么绝对呢？

“当意识到进度的偏移时，下意识（以及传统）的反应是增加人力。这就像使用汽油灭火一样，只会使事情更糟。越来越大的火势需要更多的汽油，从而进入了一场注定会导致灾难的循环。”--《人月神话》
01
针对人月（工作量单位，指1个人在1个月内的产出），时间和人数是否存在真的换算关系？书中给出了4类关系，如下图所示：

不需要交流的事：比如厂线上的计件活动，他是可以通过堆人的方式，把所需时间降下来。各类标准化的活动，都可以按此曲线解释。
无法分解的事：增加人手也无法追赶进度的事，典型的十月怀胎，无论是多少人，都得是十个月。这类事通常是不以人的意志为转移的。
少量沟通的事：仅需要少量沟通，就能快速复制的事。这个场景与第一个场景的区别在于，这类事是非标准化的，还存在沟通，所以它的下限会比较高，也就是不能堆太多的人。人一多，沟通成本就上来了。
大量沟通的事：基本上IT的活动都是这类场景，需要大量的沟通对齐，所以会说IT的事堆人是没什么用的。

前面两种情况在IT活动中基本不存在，所以不讨论，本文主要讨论后两种情况在IT中的实践。

02
先聊聊第三种情况：少量沟通的事，在IT的场景中，什么情况下会出现呢？这时候适当堆人其实是能解决问题的。这种场景的适用前提是：非标准化的少量沟通。

背景：某团队在UAT环境中，遗留了近200个P2级别的BUG（一般问题及优化建议，不影响主流程使用。嗯，我们业务比较友好，所以不用计较为什么有这么多还能上线），业务希望在上线后的1周内修复完成。但现在研发团队只有8个人，还需要负责后续迭代的研发，按当下的资源肯定是无法按期交付的。

解决方案：经过团队内部评估，可以通过堆人来解决这个问题。原因是这些BUG都是比较简单就能修复好的，不会有太大的影响。所以就紧急抽调了同一个产品线上的其他其他人员来支援（注意这个前提，是同一产品线上的人，他们对系统同样熟悉，只是在做别的版本），共来了10个人，配合着每日严格的任务规划，还是把这200多个BUG完全修复并交付上线。

大力还是能出奇迹的，只要条件和方法合适。解决方案的选择，需要理解前提条件。

03
再聊聊第4种情况：大量沟通的事。这个是IT团队大量存在的问题。敏捷研发过程强调的就是沟通。那么，在这种情况下，如果项目滞后，存在延期风险，堆人显然不是合理的方式了。

“向进度落后的项目中盲目增加人手，只会使进度更落后”--《人月神话》

背景：在某个730版本的研发过程中，原计划需要2个迭代来完成，但是第一个迭代由于各种原因有延期，需要在第二个迭代中追赶回来，由于需求已经澄清，各开发也只有自己了解自己的Story内容，这个时候堆人是解决不了问题的。

解决方案： 没有什么好的解决方案，而且不能给团队传导更多的压力，让士气变得更低落。向全员透明情况，通过加班，把时间变多出来，集体攻坚，让进度赶上来。负责人需要提供好各类后勤保障。当然，这不是一个长期的解决方案。（如果你有更好的解决方案，可以沟通）

在这种场景下，管理者应该反思为什么没有及时发现风险。因为延期不是突然发生的，它一定是在某种外部变化下，人员去处理其他的其他的问题了，或者是某个前置依赖的Story延期了，导致后续一连串的延期，又或者只是某个人员的请假，风险没有被及时识别出来。

04
不论是哪种情况，都不能盲目乐观。不能期待一切都将运作良好，每一项任务仅花费它所“应该”花费的时间。就像第一个例子，虽然我们及时解决了问题，但中间还是花了1天的时间让团队做好交接。第二个例子，最终还是Delay了。做好前期规划，关注团队变化的细节，给排期预留一定的冗余时间。尊重团队实际产能。才能让延期的事少发生。

魔幻的延期，需要未雨绸缪。
共勉。