《人月神话》阅读心得

巴比伦塔的失败启示

——《人月神话》读后感

12330227 计应2班 吕顺

 

初读人月神话，我就深深地被其中所涉及到的软件开发中遇到的各种难题和解决对策所折服。坐着布鲁克斯用一种高瞻远瞩的视角详细地阐释了团队与管理，强调了沟通及人的重要性，技术方面虽未过多涉及，却从项目管理的角度高屋建瓴地描绘了软件开发的整个过程，在一些不涉及具体技术的方面，很有先见性和指导性，我想这也是这本书的普适性这么强的原因之一。

我认真地读完了《人月神话》32周年纪念版的全本，并且选择了自己认为十分重要，值得深入探讨的一个章节进行详细地对比，分析和思考，下面首先让我来总结一下这本书的主要内容。

 

一、内容概述

首先要明确的是“人月”是什么？软件开发项目常以人月来衡量工作量，这种度量暗示着人手和时间是可以互换的。这种“人多力量大”的想法是一种一厢情愿的虚妄神话，布鲁克斯法则：向滞后的软件项目追加人手会使得进度更迟缓（Adding manpower to a late software project makes it later）。

接下来我简要的总结一下这本书的主要内容

史前时代的焦油坑吞噬了成千上万个力大无穷的巨兽，今天的大型软件项目则令无数庞大的开发团队陷入无从逃脱的窘境。软件程序按其规模和目标的不同，对开放过程的要求也有极大的不同，这给软件开放这一职业带来无穷乐趣，同时也是这一行业苦恼的根源。

虽然优秀的程序员的工作效率往往数倍于平庸的程序员，但若是缺乏合理的配置，优秀的成员未必能构成优秀的团队。大型软件开发项目的团队需要和外科手术组一样妥善分工，各司其职协调配合。

人们在第一个系统成功完成后，往往会在开发后续的第二个系统时犯冒进的错误。第二个系统经常成为过度设计或画蛇添足的牺牲品。要避免这种错误，必须在第二个系统开发时审慎地考查技术环境的变化，广泛进行交流和沟通，聆听各方面的建议，确立严谨的估算和规划。

架构设计通常由核心设计小组完成，将设计概念传达到整个开发团队是贯彻概念完整性的必然要求。要贯彻概念完整性，需要在团队中保持良好顺畅的沟通和交流，采用形式化定义等技术来确保概念被精确地定义和传达。独立的测试小组是系统质量的良好保证。

如果缺乏良好有效的沟通和协作，成员间难以有效的配合，团队项目的目标就无法实现。清晰的工作文档，明确的组织结构，合理的职责分配，都是大型软件项目最终成功的保证。最大化资源利用率，减少不必要的资源占用，合理规划，使软件系统在资源有限的情况下依然保证了良好的性能，从而实现良好的可伸缩性和健壮性，这能体现软件开发人员精湛的设计技巧。巧妙的数据结构往往能大幅度地俭省资源耗费，提高系统运行的性能。

变化是永恒的，用户的需求和期望在变化，开发者对用户需求的理解在变化，适用的技术也在变化，故而最佳的解决策略也可随之变化。软件开发团队应灵活地配置人力和资源，适应开发过程中的种种问题。程序的复杂性、用户需求的不确定性、软硬件技术环境的发展等因素导致了软件维护工作并非总是能够百分之百地获得回报。

作者在最后《没有银弹》还提出，由于软件的复杂性，一致性，变化性和不可见性，解决软件危机的银弹并不存在。作者点评了二十世纪80年代前期为业界寄予厚望的一些新技术，讨论了它们在克服软件危机中所具备的优势和缺憾。作者预言在近十年内，没有任何单独的软件工程进展可以使软件生产率有数量级的提高。　　

 

二、关键词剖析

书中的真知灼见的确值得被后人字斟句酌地探讨，但是囿于篇幅所限，我选择了《为什么巴比伦塔会失败》这一个章节作为重点研读的对象，在这个章节中，作者首先阐释了巴比伦塔的搭建动机，搭建所需要的必要条件，以及搭建巴比伦塔所缺失的条件——“交流”，以及交流的结果，“组织”。他们无法相互交谈，从而无法合作。当合作无法进行时，工作陷入了停顿。通过史书的字里行间，我们推测交流的缺乏导致了争辩、沮丧和群体猜忌。很快，部落开始分裂——大家选择了孤立，而不是互相争吵。

然后用两个小节的内容阐释了大型项目中的交流问题应该怎么解决，大型项目中的编程架构，尤其是项目工作手册的内容，最后推荐了几种大型项目中的组织架构形式。下面我就结合软件行业当前的现状来阐述一下沟通交流的重要性以及如何更好地进行沟通。

 

三、软件团队现状

其实要说起团队开发让人最头疼的不是什么技术问题，而是队员之间的合作问题。尤其是遇到矛盾重重的团队，那项目的进度一拖再拖将是家常便饭。团队开发绝不是拉几个有水平的程序员就可以开始的事情！需要注意很多方面才有可能出色的合作完成一项工程。

一个软件开发团队即使没有高深的技术背景，没有突出的项目管理能力，只要其内部交流通畅并以务实态度解决问题，一样可以开发出优秀的产品。软件开发团队的内部交流是很重要的，是建设一个有战斗力的团队所应充分重视的。团队内部交流包括两方面：技术交流和思想交流。

一般来说，如果你的所作所为曾经让他人感到意外，这就是一个交流不善的标志。（唯一的例外是项目经理本身也感到了意外）项目经理同样应该注意同小组成员之间的交流。如果你发现小组成员不清楚项目的工期，或是他们在做一些并不需要去做的工作，那么就该考虑一下自己同他们之间的交流是否存在着问题了。

很多项目都存在着问题。交流不善是导致很多问题产生并且激化其他问题的原因。从另一方面来说，前摄性的交流可以帮助解决很多问题。不要觉得交流是一种负担，通过它可以使项目平稳的进行——大家就会少一些失望，少一些不确定，也不会再感到意外。

其实我们目前流行的团队成员的技术交流，不但可以增进团队成员之间的友谊，更能拓宽成员的技术视野，迅速提高成员的技术水平，对一些基础、模糊问题的探讨，可以使其清晰，问题明确，并达成一致意见。团队成员的思想交流有助于团队成员形成战友、挚友的关系，共同营造一个和谐、团结、友爱的工作环境。因此，高效的软件开发团队必须具有融洽的交流环境。

   

四、对比变化和差异

在近二三十年来，随着软件团队专业化程度越来越高，团队之间的配合越来越默契，在团队沟通方面，技术沟通的成本降低，但是思想交流的比重大大上升，而且这不仅出现在开发小组内部，更出现在PM和开发者之间。

有一些项目经理没有很好的同小组成员进行交流，让他们了解大家对自己工作的期望值。有的时候，项目经理不知道什么时候该给小组成员布置工作任务，有的时候，项目经理明明知道自己对小组成员的期望值，但却没有及时告诉他们，直到发现他们的工作出现了问题。有的时候，由于项目经理没有说明工作要求，小组成员花费时间做了很多不必要的工作。无论是对于项目经理来说还是对于小组成员来说，这种交流不善的情况都让他们做了很多额外的工作，也难免让他们的心情感到沮丧。

项目沟通计划是项目整体计划中的一部分，它的作用非常重要，也常常容易被忽视。很多项目中没有完整的沟通计划，导致沟通非常混乱。有的项目沟通也还有效，但完全依靠客户关系或以前的项目经验，或者说完全靠项目经理个人能力的高低。然而，严格说来，一种高效的体系不应该只在大脑中存在，也不应该仅仅依靠口头传授，落实到规范的计划编制中很有必要。因而，在项目初始阶段也应该包含沟通计划。

应遵循尽早沟通、主动沟通两个原则。尽早沟通要求项目经理要有前瞻性，定期和项目成员建立沟通，不仅容易发现当前存在的问题，很多潜在问题也能暴露出来。在项目中出现问题并不可怕，可怕的是问题没被发现。沟通得越晚，暴露得越迟，带来的损失越大。

 

五、自我管理的反思

虽然我们现在的课程项目一般成员都比较少，但是在开发过程中也遇到了类似的问题。反思前几天的会议，我就发现出现了这样的情况：

我们小组想要完成的是一款桌面弹幕软件，在讨论技术可行性的时候，各位小组成员并不是在我的带领下各抒己见，而是自我组织地异想天开。在探讨软件的使用功能时我们发现，成员们一度用自己的想法代替用户的想法。这样造成的后果就是在讨论过程中争端不断，并且进度缓慢，难以形成统一一致的想法。于是在书籍思想的指导下，我发现做出一款Demo，让自己成为技术主管，再加之以团队产品负责人的身份，话语权威性更大，并且更能被大家接受，理解和认同。

 

六、如何改进才能做得更好

1.主动沟通代替被动交流

没有反馈的沟通IT部门一潭死水，各做各的事，但是，有谁知道IT部门到底应该做什么呢？这是我到这里的第一印象：没有人知道！这同原来的IT部门定位有关，本来就是一个维护几台服务器、系统的部门，有了一个应用需求，就按照需求来做，IT部门没有职责，也没有权利去干涉需求，所以，技术方案也是以第三方为准，如此情况下，就导致出现这样一种情况：要么，将现有的系统或设备运行维护好；要么，就按照第三方的方案来实施；没有总体上的规划，没有系统的思考，所以一个个独立的系统、网络、存储等都相互无关，不仅仅是资源的浪费，更是管理上的繁琐，很简单的维护工作，就显得非常的繁忙，而且新人无从帮手，因为，根本就没有维护方面的指引。要改变这种现状，那么就应该沟通，让大家了解我们的现状，了解我们该做什么。

2.减少无效沟通

在项目开展过程中，几乎所有的项目都会存在这样的情况：客户在检查项目阶段成果时，指出曾经要求的某个产品特性没有包含在其中，并且抱怨说早就以口头的方式反映给了项目组的成员，糟糕的是作为项目经理的你却一无所知，而那位成员解释说把这点忘记了；或者，你手下的程序员在设计评审时描述了他所负责的模块架构，然而软件开发出来后，你发现这和你所理解的结构大相径庭。

所以在项目中，沟通更是不可忽视。项目经理最重要的工作之一就是沟通，通常花在这方面的时间应该占到全部工作的70%-90%。良好的交流才能获取足够的信息、发现潜在的问题、控制好项目的各个方面。     

如果结合项目，那么项目经理在沟通管理计划中应该根据项目的实际明确双方认可的沟通渠道，比如与用户之间通过正式的报告沟通，与项目成员之间通过电子邮件沟通；建立沟通反馈机制，任何沟通都要保证到位，没有偏差，并且定期检查项目沟通情况，不断加以调整。这样顺畅、有效的沟通就不再是一个难题。

3.尊重，对等交流

思路有了，发给大家，可是，没有任何反馈，该如何？其一，当然是正式职位上的问题，没有这样的位置，如何有人理会？其二，就是，职责的划分，这是管理问题，其他人需要思考吗？其三，已经有的惯性思维，与我无关！更不想改变。其四，增加了我的工作职责，或者，你改变了我的工作范围，我以后能干什么？我的饭碗问题！第二步：开讨论会异常的激烈，但是，争论不在内容本身，而是其他，为什么呢？其一，竟然没有看我发出的文件！其二，讨论的是，你应该去分工，而不是讨论该做什么的问题？这不是一个团队吗？

有些项目经理在刚开始的时候并不是良好的交流者。如果自己属于这一类的话，就应该通过培训或是他人的指导来更好的学习和掌握交流技巧。但是，在大多数情况下，交流出现问题并不是因为缺乏交流技巧，而是因为没有对交流给予足够的重视。很多项目经理把前摄性的交流看作最不重要的一件事。当他们与他人进行交流时，通常既简单又仓促，给人一种他们不愿意花费时间与经历与别人进行交流的感觉。

无论什么时候都不要正面否定组员的意见，就算你是项目组长（或者项目经理）也不行！在项目设计阶段，当组员为系统提出其他的见解的时候，如果你觉得合理那自不必说表示赞同即可。如果觉得不合理，你要做的仅仅是把你的观点摆出来和他的观点对比，让团队所有人进行讨论、选择，到底哪个更有利于软件的实现。

4.有效的人员分配与责任划分

最后的结果没有什么赞同或反对，那么，我该如何做了？那就制订工作计划，列出来，并且辅以工作负责人，让上一级领导来督办好了！一旦涉及到“责任人”，问题就来了，分派工作可以，这个责任，好像不是我的吧！所以又是一番争执！不过，总算有了一份工作计划清单，每一阶段工作是什么：这是责任人自己提出的，那么应该可以执行吧！四、下一步沟通的设想看来这个团队存在问题，尤其是原有的定位原因，不能怪谁！先看看计划执行情况，了解每一个的工作方式、特长到底是什么！要沟通，先“相互”了解，而不是“争执”的误解！   

 

七、总结

诚然，这本经久不衰的畅销书籍的确可以被作为软件开发的指南手册，但软件工程的焦油坑在将来很长一段时间内会继续地使人们举步维艰，无法自拔。软件系统可能是人类创造中最错综复杂的事物，只能期待人们在力所能及的或者刚刚超越力所能及的范围内进行探索和尝试。关注点在事情上面，多阐述自己对事情的看法，而不是对人的看法；我们会讨论什么是好什么是坏，而不是讨论谁好谁坏；

最后用全书的结语为我的报告做结：当代的软件行业需要的是——进行持续的发展；学习使用更大的要素来开发；新工具的最佳使用；经论证的管理方法的最佳应用；良好判断的自由发挥；以及能够使我们认识到自己不足和容易犯错的——上帝所赐予的谦卑。