document.writeln(""); document.writeln(" "); document.writeln("

<\/td>"); document.writeln(" <\/tr>"); document.writeln(" <\/table>"); document.writeln(" "); document.writeln(" "); document.writeln("

<\/td>"); document.writeln(" <\/tr>"); document.writeln(" <\/table>"); document.writeln(""); document.writeln(" "); document.writeln(" "); document.writeln("

该文章免费阅读，以下是该文章的全部内容：<\/span><\/td>"); document.writeln(" <\/tr>"); document.writeln("

<\/td>"); document.writeln(" <\/tr>"); document.writeln(" <\/table>"); document.writeln(""); document.writeln(" "); document.writeln("

<\/td>"); document.writeln(" <\/tr>"); document.writeln(" <\/table>"); document.writeln(""); document.writeln(" "); document.writeln(" "); document.writeln("

<\/td>"); document.writeln(" <\/tr>"); document.writeln("

    刚听说这本书的中文书名的时候，还以为是一本玄幻小说。看到英文名才恍然，《The Mythical Man-Month》，妥妥的一本管理类的图书。《人月神话》可以说是经典中的经典，问世多年以来，经久不衰，常被提起并热议。抛开译著都有的通病，语言比较晦涩之外，无论是实操还是成书逻辑，都十分经得起检验，毕竟从1975年开始到今天，已经接近40多年了。期间出了不少版本，每个版本都会有一些紧跟时代的小更新。说句题外话，如果英文足够好，还是建议去读英文原版。

    理解本书，可以把“人月神话”这个词可以拆分成两个名词来看，即“人月+神话”，“人月”指的是每人每月的工作时间，软件工程规划时使用 “人月”这个单位来评估计划是否可以如期完成。而“神话”这个词则直接表达了作者的观点，即认为这种规划方式像“神话”一样是不可能，这也是本书最基础的论点，规划的方式错误必将导致整个项目工程失败。

    这里面最明显的问题有三个：

    第一，一个人一个月的产能，不可能100%发挥。工作中会有许多杂七杂八的事情影响，或者单纯是开发者个人的状态、心情，还有各种Bug错误拖延等等，让工时成果直接低于原本预估的一个月的工作量。

    第二，工时无法叠加，两个人的一月，并不等同一个人的两个月，软件开发工作是有连续性的，做完 A 才能做 B，同一个月加入另一个人并不会加快工作进程，反而可能延缓。

    第三，就算工作可以分割并行，整个工程项目中仍然有许多的迭代，在任何时间点，加入新的人手，进行培训、了解情况都需要消耗大量的时间和精力，在一个进度已经落后的软件工程中增加人手，只会更加落后。

    其它行业的项目管理同样存在这些问题。项目经理都知道项目管理的的三大要素：时间、质量、成本。其内在的管理逻辑和人月神话的观点是相通的，这里面最活跃的因子其实是人。人与人之间的协作需要畅通的信息流，信息流的统一是需要时间，也是需要成本的，信息流的质量决定了项目的质量。《人月神话》用了接近二十章的内容，用了不同的角度和大量的实例，来论证人、时间和信息传递对最终项目成败的影响。

    第一，人对项目成败的影响。

    首先是团队的配置和分工，在“外科的手术队伍”这一章，对人员的配置方式，分享了一些不错的观点。同样有两年经验，并且还是在受到相同培训的情况下，优秀程序员的效能是较差程序员的十倍。如果团队只有两个人，那么其中一个设置为项目经理，常常是最佳的人员配置方案。如果是一个大型项目，从编程的经验可以看到，一拥而上的工作方法成本高、速度慢、不充分，开发出的产品几乎无法进行实质的集成。而设置一位首席程序员，建立类似于外科手术队伍的团队配置方法，可以很好的克服以上弊端，既能获得由少数大脑产生的产品完整性，又能得到多名协作人员的整体生产效率，并且大幅度地减少了沟通的工作量。

    其次是概念完整性的实现，需要一个人或者具有共识的小型团队来完成。“贵族专制、民主政治和系统设计”一章中讲明，概念完整性是系统设计中最重要的考虑因素。对于非常大型的项目，将设计方法、体系结构方面的工作与具体实现相分离是获得概念完整性的比较强而有力的方法。简单来说就是动脑的人和动手的人严格进行分工明确纪律、建立规则对行业是有益的。外部的体系结构规定实际上是在增强，而不是限制实现小组的创造性效能。

    然后是执行问题。“贯彻执行”一章说得很明确。大意是即使是大型的项目团队，设计结果也必须是由一个，最多两个人来完成，这样才能确保所有决定的一致性。必须明确体系结构中与先前不一致的地方，重新定义的细致程度必须与原本的说明一致。体系建构师，或者项目模块的负责人必须对具体执行人员的询问做出及时的回应解释，同时必须做好日志记录，并整理发布。

    “巴比伦塔的失败”这一章，就是一个反面的例子，在这里不做赘述。

    第二，时间对项目成败的影响

    时间无疑是项目进度的关键因素，其检验节点就是一个个里程碑，要根据一个严格的时间进度表来控制项目的进展，里程碑必须是具体的、特定的、可度量的事件，且够能进行清晰能定义。对于项目进度安排，作者的经验是三分之一时间用来计划、六分之一的时间用来编程、四分之一的时间进行构件测试，四分之一的时间进行系统测试。这里有两个重点：撰写程式的时间其实只有六分之一，而构件和系统测试的时间总和却高达一半，在功能合并收尾时，必须为排除错漏留下所需的时间，必须为后面发生问题的可能性，预留下来更多的时间。在“祸起萧墙”一章还说到，一天又一天的进度落后，和重大的灾难性的事件相比，识别的难度更大，更难防范且极难弥补。

    最后，便是信息传递对项目成改的影响。

   这一点，在“提纲挈领”这一章写的很清楚，就软件项目而言，以下几样要求必须明确：目标、用户手册、内部文档、进度、预算、组织机构图和工作空间分配。书中说，即便是小型项目，项目经理也应该在项目的早期，尽最大的可能，规范化上述的这一系列文档。这些文档起到的就是信息传递的作用。这一章强调文档重要性，并且给了项目经理实实在在的操作步骤。

   以上便是读完《人月神话》得到的启发，虽然这本书主要研究的是软件工程管理方面问题，但如果只当做软件行业才能读的著作，那实在是有些浪费。这本书对其它行业的项目管理工作，其借鉴意义也非常深远，从这个意义上来讲，这部书的价值被严重低估了。这本书只读一遍不足够，每次翻开，都有不同的收获。论项目管理成败，书中的方法便是很好的指导和检验。<\/td>"); document.writeln(" <\/tr>"); document.writeln(" <\/table>");