灾祸来自白蚁的肆虐，而不是龙卷风的侵袭。同样，项目进度经常以一种难以察觉，但是残酷无情的方式慢慢落后。重大灾害是比较容易处理的，它往往和重大的压力、新技术的出现有关，整个项目组通常可以应付自如。但是一天一天的进度落后是难以识别、不容易防范和难以弥补的。如果每件事都只会将某项活动延迟半天或者一天，最终会拖累整体进度的落后，尽管每次只有一点点。
如何制定一个严格进度表来控制项目？
第一个步骤是制订进度表，对进度表上的每一件事，被称为"里程碑"（项目管理中里程碑概念指以阶段性明确的可交付物来衡量项目进度），它们都有一个日期。选择日期是一个评估技术上的问题，它在很大程度上依赖以往的经验。
里程碑的选择只有一个原则，即必须是具体的、特定的、可度量的事件，能够进行清晰定义。下面是个反例，如开发进度，在代码开发时间达到一半的时候就已经"90％完成"了。
然而，具体的里程碑是百分之百的事件。"架构师和开发人员签字认可的规格说明"，"100%代码开发完成，纸带打孔完成并输入到磁盘库"，"测试通过了所有的测试用例"。这些切实的里程碑澄清了那些划分得比较模糊的阶段--计划、编码、调试。
里程碑有明显边界和无歧义性，比它容易被老板核实更为重要。如果里程碑定义得非常明确，以至于无法自欺欺人时，很少有人会就里程碑的进度弄虚作假。但是如果里程碑很模糊，老板就常常会得到一份与实际情况不符的项目进度报告。毕竟，没有人愿意承受坏消息。
对于大型开发项目中的评估行为，政府的承包商做了两项有趣的研究。研究结果显示：
1. 如果在项目开始之前就着手评估，并且每两周进行一次仔细的修订。随着开始时间的临近，无论最后情况会变得如何的糟糕，它都不会有太大的变化。
2. 项目期间，对时间长短的过高估计，会随着项目的进行持续下降。
3. 过低评估在项目中不会有太大的变化，但直到计划的结束日期之前大约三周左右可能就会有问题出现。
好的里程碑对团队来说实际上是一项服务，可以用来向项目经理提出一些合理要求，而不确切的里程碑是难以处理的负担。当里程碑没有正确反映损失的时间，并对人们形成误导，以致事态无法挽回的时候，它会彻底碾碎项目组的士气。
"其他的部分反正会落后"
进度落后了一天，那又怎么样呢？谁会关心一天的滞后？我们最终可以跟上进度。何况，和我们项目关联的其他小组已经落后了。
并不是每一天的滞后都等于灾难。尽管会如上文所述，事先评估会给工作进度的超前带来影响，但对活动的一些计算和考虑还是必要的。那么，如何判断哪些偏离是关键的呢？只有采用PERT或者关键路径技术才能判断。它显示谁需要什么样的东西，谁位于关键路径上，他的工作滞后会影响最终的完成日期。另外，它还指出一个任务在成为关键路径时，可以落后的时间。
严格地说，PERT技术是关键路径计划的细化，如果使用PERT图，它需要对每个事件估计三次，每次对应于满足估计日期的不同可能性。
PERT的准备工作是PERT图使用中最有价值的部分。它包括整个网状结构的展开、任务之间依赖关系的识别、各个任务链的估计。这些都要求在项目早期进行非常专业的计划。
随着项目的推进，PERT图为前面那个泄气的借口，"其他的部分反正会落后"，提供了答案。它展示某人为了使自己的工作远离关键路径，需要超前多少，也建议了补偿其他部分失去的时间的方法。
地毯的下面
当一线经理发现自己的队伍出现了计划偏离时，他肯定不会马上赶到老板那里去汇报这个令人沮丧的消息。团队可以弥补进度偏差，他可以想出应对方法以解决问题，为什么要去麻烦老板呢？从这个角度来看，好像还不错。解决这类问题的确是一线经理的职责。老板已经有很多需要处理的真正的烦心事了，他不想被更多的问题打搅。因此，所有的污垢都被隐藏在地毯之下。
但是每个老板都需要两种信息：需要采取行动的计划方面的问题，用来进行分析的状态数据。出于这个目的，他需要了解所有开发队伍的情况，但得到状态的真相是很困难的。
一线经理的利益和老板的利益是内在冲突的。一线经理担心如果汇报了问题，老板会采取行动,这些行动会取代经理的作用，降低自己的威信，搞乱了其他计划。所以，只要项目经理认为自己可以独立解决问题，他就不会告诉老板。
有两种掀开毯子把污垢展现在老板面前的方法，它们必须都被采用。一种是减少角色冲突和鼓励状态共享，另一种是猛地拉开地毯。
减少角色的冲突。首先老板必须区别行动信息和状态信息。他必须要求自己，不对项目经理可以解决的问题做出反应，并且决不在检查状态报告的时候做安排。
如果老板把会见、评审、会议明显标记为状态检查（status-meeting）和问题－行动（problem-action）会议，并且约束自己的行为，这对整个过程会很有帮助。当然，事态发展到无法控制时，状态检查会议会演变成问题－行动会议。不过，至少每个人知道"当时游戏的分数是多少"，老板在接过"皮球"之前也会三思。
猛地拉开地毯。不论协作与否，拥有能了解状态真相的评审机制是必要的。PERT图以及频繁的里程碑是这种评审的基础。大型项目中，可能需要每周对某些部分进行评审，大约一个月左右进行整体评审（7080年代项目开发模式通常是瀑布开发模式，项目周期较长）。
里程碑报告中很容易记录"计划"和"估计"的日期。计划日期是项目经理的工作产物，代表了经协调后的项目整体工作计划，它是合理计划之前的判断。估计日期是最基层经理的工作产物，基层经理对所讨论的工作有着深刻的了解，估计日期代表了在现有资源和已得到了作为先决条件的必要输入的情况下，基层经理对实际实现日期的最佳判断。项目经理必须停止对这些日期的怀疑，而将重点放在使其更加精确上、以便得到没有偏见的估计，而不是那些合乎心意的乐观估计或者自我保护的保守估计。一旦它们在每个人的脑海中形成了清晰的印象，项目经理就可以预见到将来哪些地方如果他不采取任何措施，就会出现问题。
PERT图的准备工作是老板和要向他进行汇报的经理们的职责。需要一个小组来关注它的更新、修订和报告，这个小组可以看作是老板的延伸。对大型项目，这种计划和控制小组的价值是非常可贵的。小组的职权仅限于向产品线经理询问他们什么时候设定或更改里程碑，以及里程碑是否被达到。计划和控制小组处理所有的文字工作，因此产品线经理的负担将会减到最少——仅仅需要作出决策。
对计划和控制职能进行适度的技术人力投资是非常值得赞赏的。它对项目的贡献方式和直接开发软件产品有很大的不同。计划和控制小组作为监督人员，明白地指出了不易察觉的延迟，并强调关键的因素。他们是早期预警系统，防止项目以一次一天的方式落后一年。
- END -
关注 软件质量保障，与质量君一起学习成长、共同进步，做一个职场最贵Tester！
往期推荐