空泛的估算

编程人员有时和厨师一样，某项任务的计划进度，受限制与客户要求的紧迫程度，然而紧迫程度并不能控制实际完成的情况。

例如，约定两分钟内煎完一个鸡蛋，看上去简单，但实际上它无法在两分钟内完成，顾客只能选择等待或者吃生鸡蛋。厨师的另一个选择是把火开大，不过结果常常是得到一个更糟糕的煎蛋。

为了满足顾客期望而造成的不合理进度安排，在软件领域中非常普遍。不科学的估算方法，少的可怜的数据支持，完全凭借产品经理直觉的判断，这样的方式很难得出有力、可靠、低风险的评估。

显然，我们有两种解决方案：

1. 采用科学的方法，例如生产率图表、缺陷率图表、估算规则等
2. 项目经理挺直腰杆，坚持他们的估计，确信自己的经验比客户期望进度要强得多

可是，我们对自己的估计不确定，因此在管理和客户的压力下，我们常常缺乏坚持的勇气。

重复产生的进度灾难

当一个周期 4 个月的项目，在第 2 个月的节点上进度没有达到要求，此时项目经理可以做些什么呢：

• 假设任务必须按时完成，整体进度估算合理，那么就指派更多的人手
• 假设任务必须按时完成，整理进度估算偏少，那么指派更多更多的人手
• 不削减任务，确保工作能彻底完成，重新安排进度
• 削减任务，仔细认真的调整项目，重新安排进度

前两种情况是灾难性的，因为增加人手从三方面增加了项目必要的总体工作量：

• 任务重新分配本身和所造成的工作中断
• 培训新人员
• 额外的相互沟通

而且毫无疑问的是，增加人手所开发出的产品，比没有增加人手而是重新安排进度所生产出的产品更差。向进度落后的项目中增加人手，只会使得项目更加落后。

以上就是《人月神话》第二章 —— 人月神话，后两节所讲述的内容

作者反复论证了软件项目延期最主要的原因 —— 缺乏合理的进度安排。有个问题是 “没有按时完成任务是因为时间太短” 这难道不是诡辩吗？

其实，作者想要提醒的是那些制定项目进度的人。进度估算作为软件工程中十分重要的一环，常常得不到应有的重视，不全面的、不科学的、不负责任的进度安排时常发生。项目经理总会有意无意的犯下各种错误，例如忽略测试阶段、盲目自信、缺少方法、缺乏勇气等等。这么说来，软件项目延期的主要责任人也就是制定项目进度的人。

放到现实中来说，作者的观点其实是有前提假设的，那就是所有的程序员都拒绝加班，所有项目都会指派一名项目经理，所有客户都知道自己要什么。说不定国外的环境确实是这样的，但是这三点假设在我们身边都是不成立的。

首先，程序员无条件的加班让项目经理更加盲目自信，为了能够接收到项目，不断地妥协于进度紧张的客户。其次，人员安排的混乱和欠缺，大多数项目是不存在项目经理的，甚至是由商务人员直接规划进度。最后，也是最可怕的事情，客户不清楚自己需要的是什么。

总之，《人月神话》第二章作者通过严谨详实的论证，认为缺乏合理的进度安排是项目延期的主要原因。多少有点偏袒开发人员的意思，造成项目延期的原因肯定不止是估计错误那么简单。

转自 fourn - learnku.com