人月神话
人月神话 这一章节重点讲述了人、时间、项目进度之间三者之间复杂的关系。有的时候，项目进度滞后，PM盲目的增添人手，可能会使项目滞后更加严重，为什么会这么说呢？
下面有一个很恰当的比喻。
美食的烹调需要时间；片刻等待，更多美味，更多享受。——新奥尔良市安托万餐厅的菜单
这句话很形象的描述了软件开发和美食制作的相似之处，那就是都需要合理的时间安排。我想这一章就是Brooks想要表达的精华所在，《人月神话》的核心为 人月，那么在了解人月之前，我们先来聊一聊程序员的·优点·——积极乐观的心态。
1、程序员大部分都是乐观的
计算机还很年轻，程序员更加年轻（场外话：很多35岁的都被市场优化掉了，公司美其言为老白兔——公司价值观好，但是绩效产出差，没有功劳有苦劳），而年轻人满怀激情，总是乐观主义者，“我刚刚找到bug的原因，这次一定行”、“一切都会正常，良好的运行”。技术人员或多或少有属于自己独有的自信及荣誉感，对这种弥漫在编程人员中的乐观主义，越是要慎重的分析。
博主曾就职于一家saas运营相关电商公司（杭州的一家公司：wr），其中一个项目是营销相关的。2021年，电商行业大面积裁员，我们公司当然首当其中，成为了裁员大军的一个，大批量裁员，很多核心业务的人都选择主动被裁，拿到赔偿离开公司，虽然自己眼馋了一下，不过自己最终还是选择留下来（不要以为我是对公司有多忠诚，纯粹是因为面试还没有准备好，没有勇气离职）。因为公司大面积裁员，最后留下来的人接手的项目多了起来，刚好营销相关的项目就被分到了我的手里，哎~说白了就是没人愿意维护的小的业务。
而当时自己就因为绝对的自信，想着营销相关的业务，自己自从进入公司就一直在做相关项目，那我就来吧。很不凑巧，刚接手没多久，运营同学就反馈有一个功能有问题，当时的功能是 幸运大转盘 ，这个功能其实就是根据会员等级以及签到天数，在不同时间周期可以重复 抽取奖品，商家最终发奖品，很普遍的一个功能，当时反馈的问题就是：时间周期判断有问题，自己很快就定位到了问题，进行发版修复，但就是因为过于自信，提交代码的时候，居然手误写错了单位，原本单位分 日、周、月，原本代码只是天数都差了一个1，比如配置了7天，实际生效是6天，如果是周的话，转换为天数再换算，月与周同理，所以就导致最后天数都有差距，至于为什么这么设计，因为人员离职，已经无法追踪原因了，原本的产品没了，原本的测试没了，原本的开发没了。
而运营反馈这个问题，是希望天数归整为自然周自然月，说商家希望改成这样的实现方式，甲方爸爸提的需求，而且还和TL反馈过，那就改呗。自己非常自信，三下五除二就修改完毕，由于过于自信，只测试了自然日，其他周和月甚至自测都没有，直接就提测了，然后打脸的就来了。自己过于自信，都改成了自然日的代码，其他的代码，忘记修改单位为周、月，大家想必一定经历过CV大法带来的便捷吧，但一定要记得cv后修改到符合自己业务的逻辑哈，别像博主那么自信乐观，幸亏只是提测，不是自测保证上线，这要是…
原本只是修复一个bug却引入了另外一个新bug；原本只是一个简单的数学运算错误，一个上午或一个下午，更甚至一整天就被debug消耗掉了这些类似的场景发生，背后有一个错误的假设。
“ 一切都将运作良好，每一项任务仅花费它所 应该 花费的时间 ”，一旦任意一个任务出了意外，就会很自然导致后面的任务被延期。
这就引入了另外的一个概念—— 人月，也是最为重要的一个部分。
二、 人月
人月也就是人员和时间之间的关系。理想的情况，任务无交集，无互相依赖，无需交流沟通，可拆分为独立的小任务，那么
1人3天和3人1天是可以实现互换的。但现实情况呢，很多项目，尤其是大型项目中，任务是互相依赖纠缠在一起的，那么1人3天可以完成的工作量，不代表3人1天就可以完成，可能3人2天，如果项目复杂，可能3人3天+都会发生，因为这里面涉及到了后面作者说的产品概念的完成性。每个开发人员的理解不同，后加入的人员还需要培训，追赶项目进度，原本在项目中的人就必然需要额外分配出来一部分时间为新加入的同学答疑解惑，那么为了能够达成一致的产品概念，就无疑增加了解决误会的成本，也就是沟通成本随着人数的增加也随之提高。
所以有的时候，项目延期，盲目的增添人手，不一定是个明智的决定。软件开发本质上是一项系统工作——错综复杂的关系下的一种实践，沟通、交流的工作量非常大，它很快就会消耗掉任务分解所节省下来的个人时间。有的时候，添加人手，实际上延长了而不是缩短了时间进度。
1、沟通的成本如何解？
- 业务、技术培训；
- 相互交流；
无论哪一种都势必会带来时间的延长问题，而且随着人力的增加，还可能会产生重复的进度灾难，也就是难免会有些方法被或相同或类似的重复实现。
2、如何衡量应该投入多少人力进来呢？
去除人月神话的的神话色彩，只考虑人月问题，这里需要关注两点：
- 项目的时间 依赖于顺序上的限制；
- 人员的最大数量 依赖于独立子任务数量；
3、如何衡量应该投入多少人力进来呢？
应避免以下几点：
- 对估算技术缺乏有效地研究；
- 进度与工作量相互混淆；
- 对自己估算缺乏信心；
- 对进度缺少跟踪和监督；