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

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

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

人月神话

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

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

外科手术

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

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

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

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

巴比伦塔

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

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

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

没有银弹

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

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

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

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