1482_人月神话阅读笔记_人月神话

全部学习汇总： GreyZhang/The_Mythical_Man_Month: My reading notes of The Mythical Man-Month. (github.com)

虽然《人月神话》这本书已经成为经典并且影响了很多人，但是我总觉得这个书的题目多少有点问题。我不知道其他人是否会这么思考，至少我自己看到这样的标题之后总会联想美国阿波罗登月之类的主题。甚至，我可能会联想到关于月亮的神话故事而不会考虑到什么软件相关的信息。

从这一章开始，接触人月神话。

这里有一个很有意思的说法，大概是劝人不要着急的，等待或许会有美好的事情发生。这样的解释是数到额过去的，有时候还是很合理的。但是，如果许诺了过多的快餐服务，那么这种回答很可能就是砸自己招牌的举动了。

失败的很多理由在我现在遇到的工作中真实存在。缺乏合理的安排是导致问题产生的主要原因，但是合理的安排背后的原因可能是很多的，这个值得我们去仔细总结。

首先，对于估算技术缺少有效的研究。一切都是假设在什么都没问题的前提之下，这过分增加了项目组的自信。但是，如果缺少的不仅是估算技术，还是对于技术的了解，这种情况可能更是灭顶之灾。

第二，这里其实是可以看出人月神话是什么意思了。人月其实是一个工作量的单位，而错误的认为人月可以互换，这个也的确是存在的。我遇到的比较夸张的调度会出现6个人干同样的事情而没有任何衔接的情况。

第三，工作的评估其实应该是每一个阶段都需要重新估计一下，动态实时调整。

第四，实施跟踪不健全。

第五，遇到问题的时候，下意识的做法是增加人手。这个，最为常见不过。

其实，不仅仅是上面的描述是真实的，或许有些时候更加严重。或许，很多人都缺乏自己自我剖析反省的勇气。

这里，算是对人月出了一个书中的官方解释。但是，更加看出来了这本书的标题的翻译的不是很恰当。或许，这里的表达不像是人月神话，而是人月谜题来的更恰当。

沟通负担的增加：培训以及相互的交流。这个，在我前面提到的典型的6人干一件事情的例子上就凸显的格外明显。

有时候项目经理的安排是好心帮倒忙，错误的安排增加人手可能会适得其反。其实，我前面从开发者的角度提到了一个聪明人和智者的概念，从项目经理的角度也应该有这样的思考。作为项目经理的我们，也应该在遇到不如意的时候坦然面对并接受，我们无法保证终生之事全都顺心如意，做到最好就行了。

系统测试最大的恶果莫过于bug的流出，让客户为此抓狂。

这里，作者给出了一个经验性的数据来说明各个工作在实际的项目中的占比。而后面的信息，也是我前面提到的恶果的具体表现了。

客户的紧急催促以及不合理的进度现在看起来会是大多数，如何面对并处理这样的问题会是一门很有意思的艺术性手段。因此，面对这样的问题一是要反复积累数据以及评估模型，另外就是需要项目经理腰杆硬一点。

在许多工作中，培训其实是一个避不开的时间消耗。回忆过去的经历的确如此，但是这个在过去的很多工作中被忽略掉了。

遇到类似的问题，可能说明我们项目中面临着不得不去承受的痛楚。而这是我们很好的经验教训，我们也应该从这个角度庆幸一下。

如果进行有效合理的工作评估以及推演安排，这个是一个项目经理在项目管理中最需要反复磨炼的技巧。