由于该书所描述的内容比较庞杂，本人预计将分为三篇文章对于相关内容和感想进行阐述。
作为开章第一篇，就先来说说为什么“人月”是“神话”。
小学的时候我们都做过这样的应用题：“工厂需要加工一批零件，安排5名工人的话需要10小时完成，那么安排25名工人加工，多少小时可以完成”之类的。对于这类题目，小学一二年级的学生都可以轻松得到答案。也正是如此，如今的工作中，仍有不少同仁秉持这样的小学生思维来衡量工作量，跟进工作进度。他们没有发现，如今的工作已经远非小学的应用题。那些稚子玩闹的应用题，在人生和工作的大部分场景中，实际上根本无法“应用”。
让我们回到《人月神话》这一本书，它的第一章叫做“焦油坑”。
当一滴焦油，掉在你身上的时候，你使用各类有机溶剂洗涤，只要有充足的耐心反复搓洗，总能够将之解决；那么两滴、三滴乃至更多的焦油滴到身上呢，这时你可能会觉得麻烦，就把那件弄脏的衣服丢弃了事；再发展一步，当你掉到了一个“焦油坑”中，你会如何？这个坑填埋不掉，脱身不出，净化不得，你和你的工作任务只能如同困兽一样不断挣扎，最终被它吞噬。可是不要忘记，这“焦油坑”可是从一滴一滴的“焦油”累积而来的，正如书中所言，“表面上看起来好像没有任何一个单独的问题会导致困难，每个都能被解决，但是当它们相互纠缠和累积在一起的时候，团队的行动就会变得越来越慢且很难看清问题的本质。”这不禁我想起了《倚天屠龙记》中张无忌在武当山顶剑斗方东白（阿大）的那一幕：“张无忌的一柄木剑在这团寒光中画着一个个圆圈，……木剑每发一招，便似放出一条细丝，要去缠在倚天宝剑之上，这些细丝越积越多，似是积成了一团团丝绵，将倚天剑裹了起来。两人拆到二百余招之后，方东白的剑招渐见涩滞，手中宝剑倒似不断的在增加重量，……偶尔一剑刺出，真力运得不足，便被木剑带着连转几个圈子。”即便是绝顶高手，也会陷于这一滴一滴小小的焦油形成的“深坑”。
这便是“人月神话”为什么会成为“神话”的原因，如原文所述，“因为一些意想不到的交互会产生许多不易察觉的bug，测试工作将会非常耗时，因此相同功能的编程系统构件的成本至少是独立程序的三倍。如果系统有大量的组成单元，成本还会更高。”，“人们发现调试和查错往往是线性收敛的，或者更糟糕的是，具有二次方的复杂度。结果，测试一拖再拖，寻找最后一个错误比第一个错误将花费更多的时间。”。当任务复杂度逐渐增加时，我们习惯于计算工作量的两个单位“人”和“月”就不再能够互相转化了，“人月”神话最终走向破灭。
目下所及，有不少的机构和管理者都会掉入“人月”神话的窠臼之中，本人才疏学浅，经验欠奉，并不敢在管理者面前班门弄斧，仅引用书中的观点略作分析：
- 我们对估算技术缺乏有效的研究。即有的时候，我们既无法准确估算某一个项目或者某一项工作需要多少工作量，也无法估算该项工作量需要多少人力才能够完成。更有甚者，对于估算技术缺乏有效的研究，是因为对于项目本身缺乏研究。不知道如果需要完成项目应当完成多少个“小目标”，更不知道这些“小目标”应该由谁依赖哪些工具来完成。所谓“将不识战”、“将不知兵”便是如此，工作总量尚且无法预估，何况分解乎？
- 我们采用的估算技术隐含地假设人和月可以互换，错误地将进度与工作量相互混淆。文初的那一个孕妇的搞笑例子已经足以说明这一想法在非线性、非无限可分解的多里程碑（节点）任务下，简单地进行人月互换有多么的荒谬。
- 由于对自己的估算缺乏信心，通常不会有耐心持续地进行估算这项工作。很多时候，估算只是为了估算，或者通过估算证明一些什么，而非解决一些什么，因此即使估算出现错误，明知道多估或者少估，也不能、不想或者不愿进行调整了。
- 对进度缺少跟踪和监督。实际工作中，不少人对于项目的跟踪和监督就是在开始下达任务和在最后等待结果汇报，这一做法是否正确，将会在后两篇中提及。
- 当意识到进度的偏移时，下意识的反应是增加人力或者催促加班。实际上，这两种方式都是饮鸩止渴——增加人力的话，并不意味着更多人加入解决原先的工作量，增加人力本身就会导致工作量的增加。具体来说，有三个方面：任务重新分配本身和所造成的工作中断；培训新人员以及额外的相互沟通。而催促加班的结果往往只能够得到一些低质乃至无效的回馈，返工和修订同样会造成劳动总量的上升。
那么或许就要有人问了，“人月”难道真的无法换算吗？添加人手对于项目的进展难道一点作用都没有吗？对此，书中也是予以了解答“人数和时间的互换仅仅适用于以下情况：某个任务可以分解给参与人员，并且他们之间不需要相互的交流。”上述的条件在编程领域几乎是不可能的，可以想见，在实际的工作中也极少存在有这些既可以分解，又不需要交流的工作。因此“人月”神话可以实现的场景其实非常有限。而当任务由于次序上的限制不能分解时，人手的添加对进度没有帮助。由于调试、测试的次序特性，许多软件都具有这种特征。坦率的讲，以上两种“人月”可以自由兑换或者完全不能兑换的情况，对于我们目前大部分的工作而言显得过于极端，实际工作中，我们遇到的大部分是第三种情况——可以分解，但子任务之间需要相互沟通和交流的任务。此类任务必须在计划工作中考虑沟通的工作量。因此，相同人月的前提下，采用增加人手来减少时间得到的最好情况，也比未调整前要差一些（简单的说，3个人10个月完成的量，如果换做10个人来做，需要的时间比3个月要长）。与此同时，团队内的沟通其实非常重要，如果任务的每个部分必须分别和其他部分单独协作，则沟通工作量按照n(n-1)/2递增。一对一交流的情况下，三个人的沟通工作量是两个人的三倍，四个人则是两个人的六倍。而对于需要在三四个人之间召开会议、进行协商、一同解决的问题，情况会更加恶劣。因此建立定期的，高效的沟通机制是决定人员增加任务分解后是否能够相较于原先的预估时间产生优化的重要因素，否则就会产生“三个和尚没水吃”的尴尬局面。
既然对于大部分的工作任务，通过增加人手来减少所需时间的最好状况，要略逊于为调整前，那么大家一拥而上，蚁多噬象式的团队构建方式，则明显不会是解决问题最有效的团队构建，那么怎样的团队才是能够在一定人月前提之下，解决问题的最有构建呢？书中同样给了我们一些建议，那就是——外科手术队伍（The Surgical Team）。
在一台手术中，如果主刀医生、护士、麻醉师等人一拥而上，对于病人来说绝对是无妄之灾。因此，在任何的软件编程项目，乃至于其他的项目中，必须有一个分工明确，主次分明的团队，每个人各司其职，这样的团队，显然不可能存在“人人平等”式的民主。简单地说，必然由一个人来进行问题的分解，其他人给予他所需要的支持，以提高效率和生产力。
以编程为例，团队的首席程序员亲自定义功能和性能技术说明书，设计程序，编制源代码，测试以及书写技术文档，以他的意志搭建整个程序的架构，而副手（负责建议、讨论和评估）、管理员（管理财务、人员和机器设备）、编辑（书写各类说明文档）、基层程序员、开发工具管理、测试人员、语言专家（技术顾问）等则如同外科手术中的各类支持人员一样，在首席程序员的所搭建的框架内各司其职。在这个框架内，首席程序员拥有绝对的权威，也承担绝对的责任，他的决策很大程度上决定了整个开发的进度和成效，他在担负起整个项目职责的同时还拥有对于项目组其他成员的评估权和任免权。如此思想统一的团队可能不近人情，但绝对是一个开拓利器。
这样的团队组成还有一个好处就是当团队需要扩建时，比如我需要一个200人的团队（一般的“外科手术队伍”的组成是20人左右）来编辑一个大型程序或者系统时，作为项目领导者不需要将200人全部召集进行概念统一和管理，只需要将10个团队的首席程序员召集起来统一思想和认识即可，这样可以大幅度降低沟通成本，提升沟通效率，以达到“如臂使指”的效果。如此的团队搭建，既避免了一拥而上，也避免了各自为政，是一个较为有效的团队搭建方式。