《人月神话》是我在入职培训时被被培训员屡次提及并且奉为神话的一本软件工程类书籍，当时的培训里有一个下午的课程专门来讲“银弹”这件事儿，当年初入此行，听个懵懵懂懂。最近被“34岁程序员”问题困扰的我在通勤路上重读此书，结合参与过的几个项目，还是颇有收获的。

《人月神话》是小弗雷德里克·布鲁克斯对其在IBM主持研发、管理的System/360计算机家族和OS/360软件支持包项目过程中的经验总结。虽然IBM的360项目最终还是没有摆脱焦油坑，但却为软件工程留下了一本软件工程的经典著作。

人月神话

要装修一间房子，需要3个工人干60天。但小明着急用这所房子结婚，于是和工长说，能不能加点人，缩短点工期。包工头在本子上写写画画，咬咬牙说，6个工人30天。小明很高兴，但是算了算时间，觉得还是不够，于是又向工长提出建议，问能不能12个工人15天结束。工长听后也不再写写画画了，揽着小明的肩膀和他说：“这样吧，我给你凑180个工人，咱们一鼓作气，1天搞定，让你第二天就能洞房。”

好吧，这个故事是我杜撰的，但是确实是现在很多产品经理在产品上线期限临近时常出的笑话。工作中，最常听见的话“再给你三个人，咱们本周五下班前上线。”这其中体现的矛盾就是《人月神话》这本书想要告诉我们的。软件工程不同于一般的流水线制造，不能靠简单的堆人来解决问题，再说就是简单的流水线制造也不可能满足这种总工作量除以时间的计划安排，毕竟还有工艺、调测、质检等流程卡着呢。

外科手术

单纯提出问题而不给出解决方案的人，应该下猪笼。《人月神话》给出了一种经过反复实践而得出的保证项目按照计划高效推进的方法。组建一个“外科手术”式的团队。
“外科手术”团队中包括两种类型的人员，技术类人员和行政类人员。其中技术类人员包括外科医生（首席程序员）、副手（外科医生的后备）、程序员、维护人员、测试人员以及语言专家；行政类人员包括管理员（老板）、编辑（资料生产&维护者）以及他们的秘书。

“外科医生”是对整个产品的架构、规格等负责，确定技术选型、产品呈现等，由他来进行技术决策，保证产品的核心竞争力；副手是能力次于“外科医生”的存在，可能深耕产品的某一领域，对此有着独到的见解，在技术方案讨论中起到至关重要的作用；程序员、维护人员、测试人员都是字面意义，完成产品的开发、运维以及相应的测试验收；最后的语言专家是本团队的“维基百科”，能够解答开发过程中的种种疑难杂症，一般由对本项目开发语言十分痴迷的同学担任，但我觉得这个角色有可能会和程序员重叠。

管理员顾名思义，就是产品的管理者，世俗观点技术人员可能在人际沟通、对外呈现等方面都体现出弱势，各种影视作品中最喜欢表现为不通人情世故的怪咖，如谢耳朵（我本人是不同意这种观点的，例子很多，我最喜欢拿来说嘴的就是比尔盖茨的汇编能力），所以需要一个保姆似的人帮助其管理技术领域以外的事情，如人力调配、薪酬发放、激励团队等。不由想起组内聚餐时，越大的领导越爱说“我就是为兄弟们服务的，你们负责干出好产品，我为大家扫清周围障碍”。这么看来管理员就是领导啊，好想当。但书中十分强调，由于人的趋利性，管理员必须从内心到物质上对“外科医生”表现出无条件的尊重，否则“外科医生”可能无法将正确的技术决策贯彻到产品中。写到这，不禁吐槽一句，好多团队都把前半段实施的很好，但是后面技术决策时呢？我看到的大部分“外科医生”都屈从了公司的大战略、大方向，也不知是对是错。编辑是产品的资料生产者，负责将开放过程中的设计文档、产品规格、使用说明等完全透明的呈现给开放团队以及后续的产品发布。

这样的团队在运作中有点像亮剑的李云龙和赵刚，一个管打仗，一个管政工，当“外科医生”和管理员能够同心同德时，这个产品应该不会差到哪里去。

巴比伦塔

小弗雷德里克很有意思，讲道理时引用了很多西方特色的典故，比如这个巴比伦塔的失败。在《创世纪》里，记载了巴比伦塔失败的过程，原文太长了，简单来说，就是地上的人们想要通过垒砖头的方式建个高塔来宣扬他们的实力并召集更多同伴，于是他们垒啊垒，还真搞了好高，上帝怕了，就搞了个小破坏，在他们语言中加入了混淆，让他们不能通过语言完全理解对方的意图，从而阻挠了工程的进度，最终使他们各自分离，自此巴比伦塔的建造也就失败了。

那么，这个神话告诉我们什么呢？上帝好坏！再有就是为我们解释了项目失败的一个重要原因——沟通不当。一个项目从立项到实施，再到最终的产品发布，往往经历5-10个人的手，甚至更多。大家来自不同的专业、地域，在对同一件事务的讨论上就会出现偏差，一个个误差累积最终会导致产品与最初的计划相去甚远，面目全非或者失败。

那么为了保证沟通的正确性以及有效性，在项目演进过程中该如何做呢？面对面的沟通+完备的文档制度。面对面沟通的好处在很多沟通类书籍中已经反复论述了，反正就是效率高，信息量大。如果团队是多地团队的话，视频会议、语音电话则是沟通的不二选择。其次，为了保证沟通的内容能够得到落地、或者便于后续查阅，我们要养成文档输出以及纪要整理等动作习惯，用我们的黑话就是“纪要发出来，签字画押”。此外，沟通的困难程度也会随着团队规模的扩大而成几何级数上升，这也是为什么软件项目不是人越多干得越好的原因。

没有银弹

在未来的十年内，无论是在技术还是在管理方法上，都看不出任何突破性的进步，能够保证在十年内大幅度的提高软件的生产率、可靠性和简洁性。

上面是书中原文，最后两章也是在反复的论证软件开发的复杂性和创造性。读完确实有点气馁，但反过来说，对于我这个充满“34岁焦虑”的程序员来说也看到了一点希望。

没有银弹就意味着程序员的不可替代性，只要能够持续学习、跟上技术潮流，起码还是能够有一碗饭吃的。与君共勉。

好读书、读好书、读书好。遇见更好的自己。

人月神话——我从绝望中读到了希望相关推荐

杀不死的人狼——我读《人月神话》（一）
＝＝＝＝＝前言＝＝＝＝＝在这与这段文字之前,我已经阅读过种种关于<人月神话>的文字.评论者既有刘天北这样的美食家,试图在书页中夹点胡椒面以慢慢品味,为了表现食客特有的风格,他的书页都 ...
杀不死的人狼——我读《人月神话》（三）
<<==上一节＝＝＝＝＝三.<人月神话>是预言了未来还是控制了未来? ＝＝＝＝＝事实是:我们现在的很多工程知识,--无论是从书上看到的,还是从实践中体验到的--大多未曾 ...
也读《人月神话》：没有银弹的软件工程
一.关于人月神话这本书记得在上大学的时候,就经常听学长和老师讲起<人月神话>,但是却一直没有阅读.记得当时一听到这个书名,还以为是个神马科幻类别的书,结果是个软件工程方面的书籍.这本书是 ...
读《人月神话》有感2
人月神话的核心法则:概念完整性和架构师.Books认为,一个整洁.优雅的变成产品必须向它的每位用户提供一个条理分明的概念模型,这个模型描述了应用,实现应用的方法以及用来指明操作和各种参数的用户界面使用 ...
人月神话（七）没有银弹－软件工程中的根本和次要问题、20 年后的人月神话
第16章没有银弹-软件工程中的根本和次要问题没有任何技术或管理上的进展,能够独立地许诺十年内使生产率.可靠性或简洁性获得数量级上的进步. Part 1 摘要所有软件活动包括根本任务-打造由抽象软 ...
杀不死的人狼——我读《人月神话》（二）
<<== 上一节＝＝＝＝＝二.哪些是现象,哪些是答案,而哪些才是本质? ＝＝＝＝＝ Brooks 在 1961 年至 1964 年间,主持与领导了被称为人类从原子能时代进入信息时代标 ...
杀不死的人狼——我读《人月神话》（五）
<<==上一节＝＝＝＝＝五.从广义工程到狭义工程＝＝＝＝＝现在我们回到一个实际的问题上:工程的本质需求是什么?如果我问一千个人工程的本质,可能会得到一千种答案.因为大家离本质的东西 ...
上百本中文书籍中对《人月神话》的引用（4）
<人月神话>于1975年出版,1995年出二十周年版.自出版以来,该书被大量的书籍和文章引用,直到现在热潮不退. 特整理中文书籍引用--其实绝大多数还是老外写的.特别说明的是:本文只是陈述 ...
人月神话中的神话（一）
人月神话中的神话(一) 序提起<人月神话>这本大名鼎鼎的书,相信大家都不会陌生.在很多卖书的网站,不少网友都各抒己见, 纷纷发表评论和意见:国内也发行了一本32周年纪念本,随书附送的小册 ...

人月神话——我从绝望中读到了希望

人月神话

外科手术

巴比伦塔

没有银弹

人月神话——我从绝望中读到了希望相关推荐

最新文章

热门文章