迷人的书名讲着现实主义的残酷故事 ——读《人月神话》有感

序言

刚开始看到这本书的时候是被书名所吸引的，《人月神话》让人不由得想起“明月几时有，把酒问青天”的人月交心，又想起“旷野天低树，清江月近人”的人月共情。殊不知被冠以如此迷人书名的书本中所讲述的却是极具现实主义的残酷故事——在真实的软件项目管理过程中，用“人月”作为计量单位衡量工作的规模是一个危险和极具欺骗性的神话。回头去看这本书的英文名“the mythical man-month”，突然感受到英汉翻译中歧义现象的独特魅力，但又为读了四年软件工程却不知道“人月”这个单位的自己感到一丝丝惭愧。于是畅快淋漓地通读了全书，终于明白这本书流传三十余年仍旧为软件从业者津津乐道的原因，绝不是仅仅因为书中众多深入浅出的案例和形象的比喻，更是书中作者所凝练的软件管理和开发的思想——这是众多从业者潜意识认可的思想，因而在阅读到的刹那总会发出“确实如此”、“形容得太准确了”的惊叹。或许这就是一本好书的魅力吧。在阅读的过程中，我对一些特定的章节产生了一些新的思考，在下面分点进行展开。

人月神话与祸起萧墙

这两章所讲述的都是与时间相关的理论，前者强调缺乏合理的时间进度是造成项目滞后的最主要原因，且这一因素所产生的影响要比其他所有因素影响只和更大；后者则侧重于日积月累的进度落后是极具灾难性的。
在“人月神话”章节，作者提出了一个令人深思的结论，即在软件项目过程中，人员数量和工作时间是不能互相替换的。这使我想到今年年初新冠疫情在武汉大爆发的时候，政府招募了大量的工人用了短短8天的工期从无至有建成了火神山医院，这是一项令人震惊的工程。在类似的建筑项目中，工作人数和工作需要完成的时间之间的关系是类似双曲线的，即“众人拾柴火焰高”，招募的工作人员越多，项目完成的工期越短。然而，在软件开发中，人与月的关系并非如此。人手的增加不仅不会直接缩短工作的周期，反而可能使得工期延长。这是由于软件开发工作的进展需要成员之间密切的沟通协作，当新加入的人员增加的时候，势必导致相关的沟通网络的负载急剧增加；此外，新人不仅仅需要熟悉技术、项目方案、工作计划等，还需要适应其他成员的编程风格，这个过程会耗费团队的很多精力。当新成员所消耗的时间成本大于短期内能够提供的劳动力的时候，完成工期所需的时间会随着人数的增长而增加。因此，作者总结出，保持短小精干是软件开发的最佳方案。
然而，随着软件行业的不断发展，一个开发团队的规模势必越来越大。以我曾经实习过的滴滴出行为例，一个小项目组包括了几十名成员，多个小项目组又集结成为大项目组。如何在扩大团队规模（生产力）的同时与所需的工期成反比，作者在“外科手术队伍”这一章中形象地指出了一种管理模式——在一个软件的开发过程中保持概念完整性，即有且只有一个“大脑”来负责软件设计工作，其他人则负责实现工作。这样的工作模式在现今的众多互联网公司中依旧有着广泛的应用。反观本科期间组队完成的课程项目，我们通常都是在小组讨论后，由一位同学最终完成项目的架构和接口等高层的设计，其余人负责实现功能。这也符合“外科手术队伍”的软件开发模式。
在“祸起萧墙”章节，作者指出每日的进度落后更难以识别，更不容易防范和更加难以弥补。因此，软件项目的里程碑必须是具体的、特定的、可度量的事件，能进行清晰能定义。这使我想到了当代青年的通病——拖延症。拖延症不仅能够让一个程序员在任务deadline时忙得焦头烂额，更会降低他在工作整体进程中的效率。丹·所罗门曾经说过：“有的时候宁愿付钱让你周一在床上待着，也不想让你用这周剩下的时间去调试你在周一所写的代码”，说的就是工作效率对于项目进展的重要性。

巴比伦塔的失败

在该章节，作者通过《圣经》中人们由于语言不互通导致巴比伦塔建造失败的例子形象地说明了团队应该以尽可能多的方式进行相互之间的交流，包括但不限于非正式、常规项目会议，会上进行简要的技术陈述、共享的正式项目工作手册等等。这同样让我反思自己之前的实习经历：在项目组中，每天早晨都会例行举行站会，虽然并不会占用许多的时间，但是通过每人轮流简述自己昨天的工作完成情况以及当天的工作目标，小组内成员能够更好地了解与自己对接的同伴的日常工作进展，这对于项目沟通是十分必要的。此外，当某个项目成员想要提交新编写的代码并上线新功能的时候，他提交的代码必须通过至少两位组内成员的审核并进行修改后才能生效，这不仅有效地增强了成员对于对方代码及实现的了解，更加能够帮助统一组内的代码风格，这种风格的统一对于大型项目的开展以及后续的功能增加、代码重构等工作而言是至关重要的。
此外，项目文档的写作也是一项沟通技巧。我记得我的mentor曾经告诉我当遇到项目难点、bug反馈等情况时，均可以有条理地记录在成员共享的文档中，这样既可以方便别人在遇到同样问题的时候不再踩雷，也能够帮助自己高效地处理和整理问题。这种工作方法使我受益匪浅。

没有银弹

在该章节中，作者预言未来十年，不可能试图通过寻找一种有效地银弹将软件开发效率提高一个甚至几个数量级。现如今，距离作者的预言已经过去有三十多年，纵观现在的软件开发领域，虽然新技术层出不穷，仍旧没有出现一种能够让软件开发产生一次革命的银弹。参考如今的软件的发展，作者在三十多年前的观点极具前瞻性和预见性，令人不由得敬佩。然而，这种悲观的想法看似在诸多乐观派的软件开发群体中间显得很突兀，但是通过作者总结的软件开发中存在着4个天生的根本困难，即复杂度、一致性、可变性和不可见性，我们可以略微瞥见一点“没有银弹”的原因，也为软件开发浪潮中的后来人提供了“警醒”与“目标”。

总结

通过阅读《人月神话》一书，我对软件开发和软件管理都有了一些新的认知。本科四年以及实习期间我所扮演的角色均是一个普通的开发人员，接触软件管理的知识仅限于课堂和观察管理者的工作，因此我常常思考的是诸如某个模块选择更优的算法、探究某个函数的具体用法的问题。虽然不能说这些工作就是不重要的，但是通过阅读这本书，我意识到了自己所缺乏的“大局观”的软件开发思想。拘泥于某个模块的具体实现并不能创造太多的价值，反之，如何实现高效沟通、如何组建优质团队、如何思考软件行业的去向是我需要思考的。在当今中国互联网高速发展的浪潮中，许多软件从业者面临着30+即失业的风险，我想这或许是因为他们只能依靠编写代码来实现自我价值，而不能站在更高的角度进行思考，我想这也是我所缺失的。因而，在未来的学习中我将更加着重思考这方面的内容，也时常翻看这本能带给我诸多启发的神书。