合理的进度安排--人月

1、首先，没有一个很有效的估算方法。

2、我们采用的估算技术隐含的假设人和月都可以互换，错误的将进度与工作量相互混淆。

3、由于对自己的估算缺乏信心，软件经理通常不会有耐心持续的估算这项工作。

4、对进度缺少跟踪和监督。

5、当意识到进度的偏移时，下意识的反应是增加人力。

在众多的项目软件中，缺乏合理的进度安排是造成项目滞后的最主要原因，它比其他所有因素加起来的影响还要大。

1、首先，没有一个很有效的估算方法。

在项目安排的初期，项目管理人员大多数都会秉持一种乐观的态度：一切都将运作良好，每一项任务仅花费它所“应该”花费的时间。但在很多时候这只是一个错误的假设，毕竟项目初期的安排是在信息比较缺乏的时候做出的，带有严重的主观主义色彩。导致项目计划变更的因素有很多。在单个的任务中，“一切都将运转正常”的假设具有可实现性，因为所遇到的延迟是一个概率分布曲线，“不会延迟”具有限定的概率，所以现实情况可能会像计划安排的那样顺利。然而大型的编程工作，或多或少包含了很多任务，某些任务间还有前后的次序，从而一切正常的概率变得非常小，甚至接近于零。

2、我们采用的估算技术隐含的假设人和月都可以互换，错误的将进度与工作量相互混淆。

第二种谬误的思考方式是：用人月作为衡量一项工作的规模是一个危险和带有欺骗性的神话。它暗示着人员数量很时间是可以互相替换的。人员和时间的互换仅仅适用于以下情况：某个任务可以分解给参与人员，并且他们之间不需要相互的交流。比如CRUD等一些简单重复的工作。

绝大部分情况下，任务之间是需要协作的，所以我们需要考虑沟通成本。沟通所增加的负担有两部分组成：培训和相互的交流。如果使用成熟的微服务技术，那么业务培训相对于技术培训会花费较多的时间，而从需求梳理到概念设计，再到系统设计，再到编码，再到测试，这整个流程在沟通上花费的时间更多，并很快会消耗任务分解所节省下来的个人时间。这时项目管理人员会考虑添加更多的人手，但实际上有可能会延长了而不是缩短了时间进度。

对于测试人员而言，由于系统的复杂程度不断增加，以及我们的乐观主义，每迭代一个大的版本（小版本更容易控制，所以提倡敏捷开发），通常实际出现的缺陷数量比预料的要多得多，因此，测试进度的安排常常是编程中最不合理的部分。

3、由于对自己的估算缺乏信心，软件经理通常不会有耐心持续的估算这项工作。

受限于客户的需求紧迫程度，会不断的调整任务的优先级（尤其是纯外包类的项目，公司内部平台类型项目相对变化较小），导致项目计划不断变更。

这时有两种解决方案。

（1）开发并推行生产率图表、缺陷率图表、估算规则等，而整个组织最终会从这些数据的共享上获益。

（2）或者，在基于可靠的基础的估算出现之前，项目经理需要挺直腰杆，坚持他们的估计，确信自己的经验和直觉总比从期望派生出的结果要强的多。

但是无论怎样项目经理都会疲于应对，需要极强的耐心和勇气。

4、对进度缺少跟踪和监督。

5、当意识到进度的偏移时，下意识的反应是增加人力。

项目进度严重落后的情况下，增加人手需要慎重。很多时候向进度落后的项目中增加人手，只会使进度更加落后。首先应该考虑的解决方法是

（1）重新安排进度。在新的进度中分配充分的时间（通常加班是一个选项）以确保工作能仔细、彻底完成，从而无需重新确定时间进度表，这要求项目经理有非常丰富经验的项目管理经验。

(2）消减任务。根据优先级或者重要程度调整项目计划，是一个简单且可操作性非常强的选项。

最后，如果项目进度严重落后是因为需求增加，任务模块变多，那么就非常需要添加响应的人手。