人月神话读后感2

“人月”难道真的无法换算吗？添加人手对于项目的进展难道一点作用都没有吗？对此，书中也是予以了解答“人数和时间的互换仅仅适用于以下情况：某个任务可以分解给参与人员，并且他们之间不需要相互的交流。”上述的条件在编程领域几乎是不可能的，可以想见，在实际的工作中也极少存在有这些既可以分解，又不需要交流的工作。因此“人月”神话可以实现的场景其实非常有限。而当任务由于次序上的限制不能分解时，人手的添加对进度没有帮助。由于调试、测试的次序特性，许多软件都具有这种特征。坦率的讲，以上两种“人月”可以自由兑换或者完全不能兑换的情况，对于我们目前大部分的工作而言显得过于极端，实际工作中，我们遇到的大部分是第三种情况——可以分解，但子任务之间需要相互沟通和交流的任务。此类任务必须在计划工作中考虑沟通的工作量。因此，相同人月的前提下，采用增加人手来减少时间得到的最好情况，也比未调整前要差一些（简单的说，3个人10个月完成的量，如果换做10个人来做，需要的时间比3个月要长）。与此同时，团队内的沟通其实非常重要，如果任务的每个部分必须分别和其他部分单独协作，则沟通工作量按照n(n-1)/2递增。一对一交流的情况下，三个人的沟通工作量是两个人的三倍，四个人则是两个人的六倍。而对于需要在三四个人之间召开会议、进行协商、一同解决的问题，情况会更加恶劣。因此建立定期的，高效的沟通机制是决定人员增加任务分解后是否能够相较于原先的预估时间产生优化的重要因素，否则就会产生“三个和尚没水吃”的尴尬局面。

既然对于大部分的工作任务，通过增加人手来减少所需时间的最好状况，要略逊于为调整前，那么大家一拥而上，蚁多噬象式的团队构建方式，则明显不会是解决问题最有效的团队构建，那么怎样的团队才是能够在一定人月前提之下，解决问题的最有构建呢？书中同样给了我们一些建议，那就是——外科手术队伍。

在一台手术中，如果主刀医生、护士、麻醉师等人一拥而上，对于病人来说绝对是无妄之灾。因此，在任何的软件编程项目，乃至于其他的项目中，必须有一个分工明确，主次分明的团队，每个人各司其职，这样的团队，显然不可能存在“人人平等”式的民主。简单地说，必然由一个人来进行问题的分解，其他人给予他所需要的支持，以提高效率和生产力。

以编程为例，团队的首席程序员亲自定义功能和性能技术说明书，设计程序，编制源代码，测试以及书写技术文档，以他的意志搭建整个程序的架构，而副手（负责建议、讨论和评估）、管理员（管理财务、人员和机器设备）、编辑（书写各类说明文档）、基层程序员、开发工具管理、测试人员、语言专家（技术顾问）等则如同外科手术中的各类支持人员一样，在首席程序员的所搭建的框架内各司其职。在这个框架内，首席程序员拥有绝对的权威，也承担绝对的责任，他的决策很大程度上决定了整个开发的进度和成效，他在担负起整个项目职责的同时还拥有对于项目组其他成员的评估权和任免权。如此思想统一的团队可能不近人情，但绝对是一个开拓利器。

这样的团队组成还有一个好处就是当团队需要扩建时，比如我需要一个200人的团队（一般的“外科手术队伍”的组成是20人左右）来编辑一个大型程序或者系统时，作为项目领导者不需要将200人全部召集进行概念统一和管理，只需要将10个团队的首席程序员召集起来统一思想和认识即可，这样可以大幅度降低沟通成本，提升沟通效率，以达到“如臂使指”的效果。如此的团队搭建，既避免了一拥而上，也避免了各自为政，是一个较为有效的团队搭建方式。