更多的人力投入真的意味着更快的工作吗？
更多的人力投入真的意味着更快的工作吗？
——《人月神话》读后感
如果三个工人需要用十个小时的时间去挖一个坑，那么对于一个相同大小的坑，如果现在有六个工人，我们需要多长时间呢？没错，这个问题实在是简单的不能再简单了——五小时。但事实上，如此简单的工作，我们当然可以把它分开来，按照如此的算法进行理想的计算，但如果我们把视角放在复杂度无比巨大的软件工程中呢，一切将变得不再一样。特别是对于工程量巨大的任务来说。
在1975年，布鲁克斯（以下称为Brooks)发布了一本注定被载入史册的书籍——《人月神话》。Brooks曾在IBM担任360系统（人类的第一代操作系统，正式代表人类步入了信息时代）的项目经理，而当年他只有29岁，正是在这个系统的帮助下，美国航天局建立了数据库，完成了美国的登月计划。凭借在此项目中的出色表现，他获得了1985年的美国国家技术奖，又在1999年获得了计算机领域的最高奖项图灵奖。现在我想我们也不必怀疑为什么《人月神话》会成为一本20年来经久不衰的书籍了。
在介绍完作者后，我还想在进入书籍内容前再唠两句，其实Brooks并不是直接发布了这样一本《人月神话》，事实上，这本书只是他许多文章的汇总，书中的许多名篇都被奉为经典，例如“没有银弹”、“外科手术团队”等，至今还有着指导意义。
一.焦油坑
正如在课上时，李教授所说的，大型软件开发是如此的复杂，就像是自然界中的焦油坑一般，一旦不慎掉入，浑身都将沾满黏糊糊的焦油，苦苦挣扎，最后精疲力竭而亡。在旁观者看来，掉进焦油坑的人大多数都是在极度恐惧的情况下做着无意义的挣扎，不但无法拯救自己，反而加快了自己送命的速度。Brooks用这种生动中有些残酷的比喻描述了自己所从事的大型软件开发这一行业，一个单独的问题出现在团队的面前，大家很轻松就可以去解决，但当许多的问题同时出现在团队的面前时，大家突然发现问题的解决时间被无限拉长了，再也不是开头那样简单的除法计算，可能需要投入比解决之前的一个问题还要多几倍的时间来解决如今的一个问题。
有人可能会问——那为何还有如此多的人想要从事软件开发呢？这不是给自己找罪受吗？Brooks当然不是傻子，他能从事这项工作，一定有他的理由，而这个理由在本书的第一章就已经给出，即——创造全新的事物。并且该事物一定要对他人是有用的，在创造如此事物的过程中你需要不断地进行学习，因掌握一门新的技术而获得快乐与成就感，满足自己内心的渴望，让人们与你产生共鸣。
互联网大佬们，几乎都有着这样的心态，MacOs的拯救者——乔布斯，在他的人生轨迹中，始终有两个理念围绕着他，第一个便是资本，第二个便是给人们带来改变。值得庆幸的是，这两样东西并不冲突，革新性的技术反而更能挣钱，带来资本最想要的东西，Ipod便是如此。再比如Linux内核的最早作者、Linux内核的首席架构师Linus,以及GNU项目的创始人Richard Stallman，他们都是极度的技术爱好者。
话题好像有点跑偏了，但当我读到Brooks写下的那些话时，我下意识想到的就是这些人们，事物都有着自己的两面性，当我们最终完成任务，享受到内啡肽带来的快乐时，不可避免地在过程中我们一定感受过痛苦，我们所就读的软件工程专业不可避免地会经历这些，我想教授让我们读这本书的一个理由，就是让我们真正的明白我们所将要从事的将是一项什么样的工作，我们到底会面临什么吧。
二.人月神话
作者在第二章便写到了与书名相同的“人月神话”，不难想象，此章的含金量肯定不低，而事实也确实如此。
首先让我们从本书的书名来入手，人月并没有被写作为Human-Moon，而是以Man-Month呈现给读者，从字面意思就很好看出，人月是一个形容工作量的词汇，即一个人在一个月内的工作量，这是一个混淆了工作量和进度这两个概念，因为这样的两个因素并不能简单相乘。正如开头时的例子一样，作者在书中也生动地讲述了一个大同小异的故事——一个孕妇生下一个孩子要十个月，但有人想要她一个月就生下来，但就算找来了是个孕妇，哪里能够一个月就把孩子生下来呢？回到大型软件开发这个环境中来，许多的项目管理者总是希望通过增加更多的软件开发人员来加快软件开发的进度，但却事与愿违。有人可能会说，你生孩子的例子好像在偷换概念，现在放到这个环境下来，一个项目需要一个人十个月的时间，那现在有了十个人，一个月不就可以完成了吗？如果从理想的角度来说，确实如此，但可惜现实世界远比我们书本题目中的世界复杂的多。软件工程的各项工作之间，往往存在着前后的联系，要完成之前的一项，才可以继续进行下一项，中途加入的人手，并不能马上就开始工作。所以想要通过增加人手来加快大型软件开发的进度，是不可取的，这正是一个神话——人月神话。
作者在这章中所想表达的，正是软件开发在项目管理中遇到的一系列难题。所有的程序员都有着乐观主义，总是觉得自己的代码可以运行，乐观的项目管理者错误的估计了项目的所需时间，错误地认为无脑堆叠人数就可以加快工作的进度，错误地计算，忽略了小细节对整个大局的影响，最终导致项目的延期。
在生活和工作中，我想大家都或多或少体验过这样的感觉——工作路径中的一些问题，是无法被拆解的，只能由一个人来完成。或者说这个问题可以被拆解，但一个人做事和一群人做事，方式总归是不一样的，一个人单打独斗，不需要与他人过多的交流，一群人在一起工作，要互相了解对方的工作模式，工作习惯等等一系列事情，花很长的时间去开会交流，再加上为新员工进行业务的培训，技能的训练等，无意中就增加了大量的工作周期。
我选择在这里回答教授所向我们布置的此次作业中要求我们回答的“该书最中心主题是什么”这一问题，我认为是Brooks法则：
“向进度落后的项目中增加人手，只会是进度更加落后。”
”Adding manpower to a late software project makes it later."
Brooks试图用他的法则来告诉人们，用人月这一单位去衡量一个项目的进度是不可靠的，时间上的不足并不能够通过增加大量的人力来解决，有时候盲目的增加人手只会让项目变得更加缓慢，已经在工作的员工不得不抽出时间为加入的新鲜血液进行培训，大大拖延了项目的进度。巴比伦塔的失败归因于交流与组织的缺失，而世界上还有大大小小数不清的项目，其实也是一个个小小的巴比伦塔。回到软件行业来，这是一个知识密集性的行业，团队中的成员数量会很多，角色也会很多，比如产品经理、交互设计师、前后端开发、架构师、测试人员等一系列角色，“每个人都是独立的个体”，不同角色的思考方式是截然不同的，流畅的沟通才能让他们团结起来，经历一定的磨合期，成为一个强大的团队。
读完上述的内容，我不禁有些困惑与恐惧，难道组织管理就是一条比登天还难的道路吗？Brooks在这时给了我们答案。他通过自己多年在不同项目团队中的工作经验，总结出了属于自己的经验法则，并在书中分享了出来。
1/3 计划
1/6编码
1/4构件测试和早期系统测试
1/4系统测试，所有构件已完成
大部分人都会以为编码占据了软件开发过程中绝大多数的时间，但事实上看来，编码仅仅只占到了六分之一的时间，而这也正是为什么大多数管理者让项目落后的原因了。
三.外科手术团队
在本章节中，Brooks讲述了自己对于如何解决项目管理问题的看法，也正就是本章的名字——外科手术团队。
Brooks建议人们采用小团队的方式来开展工作，如何更加有效的组织团队成员工作，是管理者需要重点考虑的事情，其中一种卓有成效的建议便是，通过类似外科手术团队的组织结构来进行管理。
从团队对每个成员的工作效率影响来说：
在一个团队中，最好成员和最差成员之间的工作效率差异为10:1。
正如乔布斯所言，一个优秀的人顶的上50个平庸的人，同时也是我在班级自我介绍的环节中提到过的，谷歌公司为什么愿意多花十几倍的价钱去雇佣一个博士生当电话接线员，而不是雇佣另外一个普通大学生，正是因为博士生的工作效率可能是普通大学生的几十倍，正如那句足球界的名句所言：
最贵的就是最好的。
但事实上，并非人人都是优秀的，总会在对比中产生优秀与平庸，所以Brooks提出了他的理念，反对团队采用一拥而上的方式，而是让优秀的人成为整个团队的核心，围绕他来开展工作，其他人作为辅助，各司其职，最终完成整体工程。不难理解，其实就是以主刀医生为核心，麻醉师、护士、负责助理医师等成员在旁边进行辅助性的工作，例如递纱布、递止血钳、擦汗等一系列任务，最终共同完成一台手术。回到软件工程管理中来，相同的，让首席程序员或是架构师，团队管理者充当副手，其他成员便负责单元代码的编写功能、单元测试、文档管理、工具开发、技术专家支持等，这样下来，无论团队的成员多么复杂，只要根据工作边界合理化指定任务，分配到一个个小团队中去，效率就可以得到一定的提升。
其次还要有着合理有效的沟通，记录电话会议内容，定期召开统筹项目进度的例会，对数据结果进行监督和反馈、防微杜渐等。在这其中，Brooks重点将两点拎了出来，其一为使用产品文档，另一个为手把手带的工作方式。在这里不详细解释产品文档的概念，可简单理解为包含着产品开发的目标与人员安排等内容的文档，例如思维导图，在线合作编辑器等。不难理解，如果管理者能够得心应手的运用产品文档，那么团队的效率肯定会上一个档次，有着更好的团队合作的姿态。
一位在学习营销话术期间成绩优异的年轻的实习收银机推销员开始了他的第一天工作，兴高采烈地拉满了整整一车收银机，一天过去了，他还是一台都没有卖出去，前后的巨大差异使他开始怀疑自己，这时他的经理站了出来，手把手的带他推销收银机，教他如何正确摆放收银机的位置，以便让客户购买自己的产品，最后他才终于明白。而这就是第二点——手把手带的工作模式，不可否认的是，纵使如今的产品文档多么发达，一些工作还是需要前辈手把手带后辈才行。
在作者看来，软件工程是一个复杂度极高的项目，这种复杂度对效率的影响是几十倍的，有人认为特斯拉汽车是几十节电池的组装，毫无技术含量，确实，在今天来看，一节5号电池早已不是什么高精尖技术，但当你尝试把几十节电池组装在一起去进行一项工作时，工作的难度并不是线性叠加的，他远比你想象的更加困难。换成小小的失败来看，突然发生的小失败或许根本不值一提，担当小失败不断叠加，最后所酿成大祸时早已无法挽回。
四.没有银弹
何为银弹，为何没有银弹？让我们来一步步解释这一经典章节的问题。
首先，如果了解西方神话的人应该知道，人类为了杀死狼人，会采用白银做的子弹当武器，因为这样才能真正杀死他们，就好像人们会用大蒜对付吸血鬼一样，在这里我们可以把银弹当作是一种能够彻底解决问题的方法。但很不幸，标题依然告诉我们——没有银弹。通俗点来说，就是在软件开发的过程中，总会遇到无法解决的问题与困难，任何时候都不可能从头到尾一帆风顺。Brooks为什么敢如此绝对的说呢，他给出了两点原因。
其一，计算机行业的发展速度实在太快了，从世界上第一台现代电子计算机诞生起，那时ENIAC还足足有一间房子那么大，而如今的树莓派已经可以做到和U盘一样小，甚至内存更大，算力更强。无论是硬件还是软件，二者都在飞速地发展着，也就导致了工作人员需要不断地学习新的技术来保证自己不被淘汰，随着年龄的不断增加，每次的新技术对于他们都是一种挑战。
其二，软件研发本身的内在特性制约了开发的进展，作者用“复杂性”“一致性”“可变性”“不可见性”四个词汇来概括了这一点。
- 复杂性——表现在用户需求、技术研发和团队管理中，软件开发的需求本身就带有复杂性（你永远不明白甲方对你含糊不清的要求，无法明确的实现，只能自己一点点尝试一点点修改），想要真正明白用户需要什么，并将其转化成语言告诉架构师和软件研发团队进行设计和实现，最后还要把各岗位的人员调度到一起，共同构建起一个系统，并不是一件多么轻松的事情。计算机本身同样也存在复杂性，各种编译器，操作系统，设备驱动，计算机网络，数据库等……
- 可变性——在工作不断推动的过程中，产品在时时刻刻发生着变化，程序员抱怨产品经理不断地改需求，产品经理又要应对运营层出不穷的要求，而运营又要面对用户的抱怨与建议。环境在变，用户群体在变，用户需求在变，竞争对手也再变，改变是唯一的不变，你还能不变吗？
- 一致性——软件工程师会面临截然不同的各个产品需求，想要一招鲜吃遍天是完全不可能的，没有一个一致性的规则让你去套用。
- 不可见性——软件是一种思维产物，看不见摸不到，双方仅能通过语言来交流，难免会产生一定的困难，Brooks认为这是根本困难，无法解决，但同样的，他还是给出了一定的建议。
其一便是采用新的技术，例如使用高级语言（Python等），在C语言中需要数行才能实现的代码，在Python中可能只需要一行就可以实现，节省了许多时间，十分有效。再比如UE4与UE5的差别，UE5中的“Nanite”与“Lumen”都大大解放了美术师的工作负担，同样是节省了大把大把的时间。还有人工智能与专家系统，专家系统便是在系统中指定一系列的规则，根据领域内一些专家的知识与经验来制定，以此来对问题进行判断，模拟人类专家。人工智能可以看作是专家系统的升级版，在计算机发展的这么长时间来，人类已经积累的数不清的数据可供计算机学习，例如计算机视觉网络中的深度学习，令人工智能扫描世界上不同人种的图片，就算是外星人也可以识别出人体，学习的能力十分恐怖。或许在以后可以让人工智能去学习人工智能的开发，让人工智能去做人工智能，循环往复……这便是数据积累对新技术开发的助力
另一点便是使用增量开发，所谓增量开发便是团队迅速实现主要的功能，做出一个雏形，快速的推给用户进行使用，在用户使用过程中不断完善附加功能，不断推送新版本，进行增量开发。如今的移动端应用大多都采用如此的形式进行开发。
最后一条就是人才，Brooks认为好的设计型人才对于互联网企业来说实在是太重要了，软件行业是一个开发型行业，因人成事，人力成本往往占互联网公司投入的大部分。
五.写在最后
Brooks这本20年前的书中有很多的预言，如今我们站在20年后去看这些话，就像是惊讶于儒勒凡尔纳的猜想如此精准一般，在那个年代，Pc并不是多么普及的东西，大部分Pc都是公司以集体名义购买，让各个员工使用。Brooks语言之后计算机将有数百万的规模，他说的确实没错，甚至还说少了。同样的，他所看好的那颗铜弹——面向对象（大家可以自行了解面向对象与面向过程的差别，在此不多赘述），强制的模块化和清晰的接口可以极大增加效率。如今来看，面向对象好似已经统治了软件开发行业。
读完此书后对于软件工程行业的未来，我想我们并不能靠自己去改变整个行业的状态，不可能靠一己之力把焦油坑变成一个舒适的温泉，造出能够解决一切问题的银弹，正如Brooks所言，软件工程或许是人类创造的最复杂的事物，甚至他还在不断地发展，越来越复杂。我们唯一能做的，应是拥抱改变。
六.摘抄
没有任何技术或管理上的进展，能够独立地许诺十年内使生产率、可靠性或简洁性获得数量级上的进步。
There is no single development, in either technology or management technique, which by itself promises even one order-of-magnitude improvement within a decade in productivity, in reliability, in simplicity.
项目是怎样延迟了整整一年的时间？…一次一天。
但是一天一天的进度落后是难以识别、不容易防范和难以弥补的。昨天，某个关键人员生病了，无法召开某个会议。今天，由于雷击打坏了公司的供电变压器，所有机器无法启动。明天，因为工厂磁盘供货延迟了一周，磁盘例程的测试无法进行。下雪、应急任务、私人问题、同顾客的紧急会议、管理人员检查——这个列表可以不断地延长。每件事都只会将某项活动延迟半天或者一天，但是整个进度开始落后了，尽管每次只有一点点。
系统软件开发是减少混乱度（减少熵）的过程，所以它本身是处于亚稳态的。软件维护是提高混乱度（增加熵）的过程，即使是最熟练的软件维护工作，也只是放缓了系统退化到非稳态的进程。
对规模平均为3200指令的程序...大约单个的程序员所需要的编码和调试时间为178个小时，由此可以外推得到每年35800语句的生产率。而规模只有一半的程序花费时间大约仅为前者的四分之一，相应推断出的生产率几乎是每年80,000代码行1。计划、编制文档、测试、系统集成和培训的时间必须被考虑在内。因此，上述小型项目数据的外推是没有意义的。就好像把100码短跑记录外推，得出人类可以在3分钟之内跑完1英里的结论一样。
工作量 ＝ （常数）×（指令的数量）^1.5(Linux与Windows这种级别的操作系统为何无人能敌，工作量是很大的原因。)
七.参考
《人月神话》FREDERICK P. BROOKS, JR.
《人月神话》读书笔记 作者:陈浩要安静 https://www.jianshu.com/p/da8a68354caa
《人月神话》读后感 作者：夫礼者 https://www.jianshu.com/p/cf5a4c50a0a6
《人月神话》图灵奖得主、“IBM 360系统之父”作者Brooks颠覆了项目管理领域，长久不衰传奇经典！
