“人月”谎言

人月神话

人多没好事er

老话说：“三个臭皮匠顶得上一个诸葛亮。”
老话还说：“一个和尚抬水吃，两个和尚挑水吃，三个和尚没水吃。”
同样是三个，和尚比臭皮匠差在哪儿？
三个和尚，互相推诿，都不愿意干活，所以没水吃；皮匠虽然臭，可是三个笨人一起动脑，也比得上一个聪明人。
于是我们得出结论：只要乐于合作，人多总比人少好。
可是，有一本书却言之凿凿的说：即使全力合作，人多也不是好事，人越多，效率越低。这本书叫做《人月神话》。

“人月”谎言

《人月神话》是软件行业的一本“圣书”，别被书名骗了，这本书写的不是“神话”，和“登月”也没半点关系，书名的真正含义是：“人月”只是一个“神话”，换句话说，“人月”只是一个谎言。

什么是“人月”？
“人月”就是：人×月，是工作量的计量单位。在软件业，“人×月”大概是衡量工作量的唯一指标。

为什么说“人月”只是一个谎言呢？
书中是这么说的：

我认为，用人月来衡量一项工作的规模是一个危险和骗人的神话。它暗示着人员数量和工作时间是可以相互替换的。

作者的隐含意思是，人员数量和工作时间是不能互相替换的。理由如下。
作者把工作分为三类。
第一类是可以完全分解的工作，即成员各自完成任务且彼此不需要任何交流，人月之间的关系是双曲线形的：

理想的人月关系

第二类是可以分解、但成员之间需要少量的沟通的工作，人月之间的关系是L形的：

人月关系-少量沟通的工作

第三类是可以分解、但成员之间需要频繁复杂的沟通的工作，人月之间的关系是U形的：

人月关系-复杂沟通的工作

软件开发属于第三类工作，所以增加人手不但不会缩短任务周期，甚至会使情况更糟。为什么呢？
原因有两个。一是培训成本高，新人加入项目组，要熟悉技术、项目方案、工作计划以及团队其他成员的风格，这个过程会耗费团队的很多精力，这减少了他们用于软件开发的精力；二是沟通的工作量急剧增加，在软件项目中，成员之间要时常沟通，这构成了一个沟通网络，由沟通带来的工作量至少是N²级的(N是人数)，每增加一个成员，沟通的工作量会增加好几倍，甚至会超过这个新成员带来的贡献。因此，保持短小精干是软件开发的最佳方案。
为此书中举了一个例子：

如果在一个200人的项目中，有25个最能干和最有开发经验的项目经理，那么，开除其他175名程序员，让项目经理来编程开发。

这个案例有些夸张，但并非毫无根据，测试结果表明，好程序员和差程序员的生产率比值平均为10:1，175个庸才带来的附加成本可能会抵消甚至超过他们的贡献。所以说，精干的小团队总是更好的选择。

但是，大型软件项目不可能依靠小团队完成，比如，微软公司的Windows操作系统是由近万人的开发团队完成的。如果不得不管理一只庞大的软件开发团队，我们该怎么办？书中给出的答案是——像外科手术团队一样管理！

外科手术管理模式

软件项目讲究一个原则——概念完整性，即软件的设计思想要体现在软件的每一个部分。这就需要有且只有一个“大脑”来负责软件设计工作，其他人负责实现，这与外科手术如出一辙。

外科手术团队有一位主刀医生、一位副手，其他人员都是辅助岗位，比如麻醉师和护士。主刀医生是手术的唯一负责人；副手是和主刀医生的备选，其他人员按照分工完成各自的任务。

借鉴外科手术团队的管理模式，一个小型的软件项目可以划分为首席程序员、副手以及管理员、程序职员等辅助岗位。首席程序员是团队唯一的“大脑”，负责团队管理、软件设计甚至核心代码的实现；副手是首席程序员的后备，承担首席程序员的部分工作；其他人各司其职即可。
书中的结论是：按照这种结构组成的小型软件团队效率最高。

开发大型软件需要大型团队，这时可以把上述模式嵌套使用，即一个一级首席程序员管理若干个二级首席程序员，二级首席程序员管理自己的团队。不管项目人员有多少，原则永远不变——一个团队只有一个大脑。

归根结底，《人月神话》给团队管理者两个建议：
1.需要复杂沟通的工作，人越少效率越高；
2.一个团队永远只能有一个大脑。