为何增加人手并不能使项目进度提高到想象的程度

为什么增加人手并不能使项目进度提高到想象的程度？

　　假定一个项目估算出来，一个人做需要12个月（客户哪能等那么久，黄花菜都凉了）；那么增加到4个人来做，是不是就可以3个月来完成呢，因为总共12个人月嘛。答案是否定的。

　　因为，如果项目真是一个人来做，不存在沟通的问题，不会存在接口的问题，不会有这样的场景出现：

　　项目经理：我们每周开个例会，讨论一下目前的进度；

　　技术经理：来，讨论一下设计方案；

　　程序员甲：这个需求好像不太明确，你自己弄清楚了再来找我；

　　设计人员：方案有变，得重新讨论一下新方案；

　　程序员乙：我写的程序没问题，你调用的数据有问题；

　　......

　　其实，很多人一起做一个项目，有点类似于现在多核时代的并行处理系统，有个阿姆达尔定律对并行系统的处理能力给出了定量的计算公式：

　　项目由单个人完成，其实就是一种串行计算模式，一环套一环，一件事情接着一件事情完成；而增加到多个人来完成，就变成了并行计算，需要对工作任务进行并行化设计和分解，某些工作肯定是很难进行并行化的，而且工作任务需要同步，彼此协作才能完成这个项目。（有时候，系统的一些设计方式，就是为了方便多人协作，但往往会增加开销）

　　假定我们需要串行工作的部分是20%，那么上面一个人12个月完成的事情，在增加到4个人时，会提速多少呢？我们用阿姆达尔定律公式计算如下：

　　S = 1 / (0.2 + (1-0.2) / 4) = 1 / (0.2 + 0.2) = 1 / 0.4 = 2.5 倍速

　　意思是说，进度是原来的 2.5 倍，那么原来需要 12个月的，现在 需要

　　T = 12 / 2.5 = 4.8 月

　　比原来设想的3个月搞定的计划要落后差不多两个月时间。

　　那，有人说，那我继续来增加人手，增加到 8个人来干，总能更快些了吧？我们重新来计算：

　　S = 1 / (0.2 + (1-0.2) / 8) = 1 / (0.2 + 0.1) = 1 / 0.3 = 3.33 倍速

　　时间

　　T = 12 / 3.3 = 3.6 月

　　也就是说，新增加的那4个人带来的效率，就是可能使项目再提前1个月完成。果真如此吗？

　　我们前面假定a的值是20%，对于只是计算机执行的任务来说也许可以这样来假定，但对于由人组成的“并行”系统呢？计算机的并行系统，比如使用多核处理器，每核的处理能力相同；但每个人的能力都是由差别的，对于项目人员配置，总是技术好的带几个技术一般的（甚至是学徒工），因此每个人对提速的贡献是不同的。而且随着人员的增加，沟通的成本会急剧上升，由于模块之间接口增加，相应的缺陷也会急剧增加，因此 a 的值也会随着人员的增加而变大。我们假定在 8 个人参与项目的时候，a 的值估计为 30%，我们重新来计算：

　　S = 1 / (0.3 + (1-0.3) / 8) = 2.58 倍速

　　发现这个结果与４个人参与项目时差不多，也就是说新增加的这４个人，除了增加了人员成本之外，并没有带来项目效率上的提升。（也可以预计到，再增加人手，项目将会更慢更慢些）

　　这一点，毋庸置疑，增加人手并不能使项目进度加快到想象的速度，甚至相反，Brooks 在《人月神话》中早就提及（有人也把此称之为布鲁克斯定律）：

　　网上也有人写了文章来讨论“布鲁克斯定律”，比如：

　　柳记　浅谈软件开发定律系列之布鲁克斯定律　http://eilfei2000.blog.51cto.com/2956473/738324

　　下面的文章也很不错：做一个艺术品，只有一个人才可以做好。规模庞大的工程，需要多个人来完成。

　　云风的Blog 软件项目需要很多人一起完成可能是一个骗局　http://blog.codingnow.com/2011/05/solo.html

　　关于分工合作　http://blog.codingnow.com/2012/01/_oeouoeie.html

　　ＰＳ：为什么会写这么一篇文章呢？因为今天刚好看到最新的《程序员》杂志上的《1024核CPU上的并行编程》一文，突然想到在项目中好像也存在这种并行计算的影子。该文说道“同步所带来的串行化开销是并行程序最大的性能杀手”，同样也可以说“沟通 所带来的时间成本开销是项目的最大进度杀手，但沟通是不可以省略的”。（当然，本文并不是否定团队协作完成项目，因为大多数项目都不可能一个人搞定：一是时间不允许，二是精力不允许，三是能力不允许，四是客户不允许，五是......，最大的原因是没有必要也没有能力一个人扛，钱是公司赚滴，身体是自己的哦）