|
项目跟踪控制的目的是保证项目目标的达成。项目周期是重要的项目目标，因此进度控制是重要的监控内容，同时软件产品的质量，成本等也应该根据当初定义的目标进行监控。否则到了时间点，产品完成了但质量和成本都达不到要求，仍然是失败。
有监控但项目仍然延期，或者说仍然达不到当初定义的质量和成本要求，原因何在？只跟踪不控制，只发现问题不找寻根源和解决问题，只应急处理问题而不是提前观察各种征兆是监控中最常见的现象。
进度跟踪中发现进度偏差的根源分析
1.任务本身的估算问题
任务本身的工作量估算是否合理？进度出现偏差首先要考虑的工作量的估算是否合理，是否考虑了工作中存在的技术难点，是否考虑了项目成员自身的技能，是否考虑了其它应该考虑的风险。任务计划下达给项目成员时候应该获取承诺，但很多时候获取承诺是无用的，是否可以承诺或者是否能完成承诺跟项目成员的个人经验和技能有太大的关系。
当偏差出在估算上，而且后续项目都是采用的相同估算模式的情况，调整项目计划往往是必须的了。对于短期型的项目，如果这个时候才发现是项目成员技能问题，而想通过培训来提高技能以取得立竿见影的效果往往已经是不现实的。
如果项目任务中存在着技术攻关或技术难点需要解决，对于这种任务往往是很难估计工作量的，而且一旦在技术问题上被卡住往往对项目进度产生致命的影响。唯一的方式就是把无法预测和不透明的东西转换为透明，在项目开始之前就应该进行风险分析和应对，提前进行技术问题的预研，开发原型，积累相关的知识和经验。
估算问题的根源又出在历史项目或版本对项目历史数据的采集和分析不够，准确的估算依赖于专家的经验，但专家的经验同样是依赖于历史项目和历史数据。估算问题的根源还在于对项目成员技能和生产率水平没有较清楚的认识，一个软件类任务的完成往往存在着巨大的个人生产率差异和进度差异。
2.任务本身的粒度问题
对于一个软件项目，出现1-2天的偏差很容易得到纠正。而如果出现1-2周的偏差则很难再进行纠正。任务本身的粒度和工作量直接和偏差的大小相关。当任务本身的粒度太大的时候是不适宜进行跟踪的，任务本身是否会偏差不在取决于跟踪者，而是执行者对于大粒度的任务是否有很好的细分和自我控制能力。
任何一个任务，要么不出现偏差，要么出现成倍的偏差。一个任务的粒度如果是1个月，那这个任务很有可能要2个月才能完成，如果我们的进度偏差最多允许一周，则需要把任务粒度细化到周，按周进行跟踪。如果对于任务最多允许偏差1-2天，则需要把任务粒度细化到天，按天来进行跟踪。细粒度的跟踪目的就是要消除不确定性因素和风险，尽可能早的发现任务中的问题，这样才有可能有时间来解决问题和纠正偏差。
对于大粒度的项目任务，任务内部本身也存在跟踪但一般只能有项目成员自己进行。任务没有细分，成员反馈的任何任务完成40%,70%等完成百分比都是不可靠和主观的数据。项目成员的自我监控能力对进度是否偏差起到重要的影响，在这种情况下，任务是否能够按期完成对项目经理是不可控的，因此项目经理必须对成员有充分的了解和信任。
3.项目经理对业务和技术领域的不熟悉
对于IT领域项目经理，对业务和技术领域的熟悉是必须具备的能力。有了这些能力才可能和项目组一起得出比较好的WBS分解和任务工作量的估算，有了这些能力才可能实现细粒度任务的划分，并定义清晰的出入口准则。
在项目的跟踪过程中往往体现的较多的是项目管理能力，但在项目控制过程中体现更多的则是业务和技术能力。控制的目的是真正去发现问题的根源，去解决问题并纠正偏差。举个例子：项目经理给项目成员安排了一个任务，要求本周完成，到了周末项目成员反馈无法完成需要延期2天，项目经理就确认延期两天并调整后续任务。到了下周二，项目成员又反馈出现了新问题，有个细节没有考虑到还需要延期三天，项目经理不得已又进行任务调整。这就是我们常看到的场景，整个任务和项目计划都变得不可控制了，项目成员有责任，但项目经理同样有责任，项目经理在第一次出现偏差时候就应该介入任务或问题本身，帮忙一次诊断和分析问题，挖掘问题延期根源，或者调整任务粒度，改进监控方式，而这些都需要项目经理具备一定的业务和技术能力，具备相关的经验积累及时做出指导。
在第一次出现进度偏差的时候，你需要的就是及时介入问题，查找问题根源而不是简单的关注成员反馈的下一个可能完成的时间点。只有这样才可能进度小偏差就立即查找根源并控制，而不是进度大偏差的时候进行应急。
4.最后总结
项目总体进度允许偏差确定了项目任务粒度划分和任务跟踪频度。
很多进度问题是前期没有进行充足风险分析和提前应对。
估算很重要，一份不切实际的进度再怎么跟踪都只可能延期或低质量。
任务完成百分比不可靠，可靠方法是任务细分并定义严格的出入口准则。
第一次延期就应该介入问题，查找根源而不是乐观期待下一个可能完成点。 | 
收藏
分享
有用
无用