Project中的前锋线（进度线）使用基础图文教程

我想每个人都有体会，做一个计划不难，难的是把计划执行下去。所以，项目管理的前辈们费了很多心思去想办法测量和衡量进度的绩效，从而对当前进度绩效做出判断，以便决定下一步行动。于是，基准、挣值分析、前锋线等相关的方法不断地创造出来，这其中，我个人认为，基准的概念是最重要的，很多工具都是基于基准才能计算和应用。

这些方法在微软的Project软件中都有体现，今天我们就来讲一下Project里面的前锋线，在Project中它叫做“进度线”，英文版Project软件中叫做“Progress Lines"。在甘特图区域鼠标右键点击【进度线】，如图1所示。

?

图1

然后会弹出进度线的窗口，如图2所示，在【日期与间隔】选项下勾选【显示】，默认会按照【在项目状态日期】来显示进度线。在图1中，甘特图区域的红色折线就是进度线。

?

图2

Project软件中的进度线，有两个衡量和比较的维度，一个是根据当前计划（就是图2右下角的两个选项，其中“实际计划”应该是当前计划，我认为软件界面是有问题的），一个是根据基准计划。有的同学说，不知道什么是当前计划和基准计划，关于这个问题，大家可以看一下我的课程或者书，本文就不赘述了。这是衡量绩效的维度，或者参照物。那么数据比较的时间点呢，又分为状态日期和当前日期，就是说以哪天的数据来进行计算或比较。在下文中，我们将以状态日期来进行讲解。

那么进度线是怎么衡量进度的呢？就是用状态日期这一天（或当前日期），任务的“实际进度”与当前计划或基准计划“应该完成的百分比”去比较。现在我们分别解释一下什么是“实际进度”和“应该完成的百分比”。

实际进度，在Project中用【完成百分比】来表示，这个很好理解。

什么是按照当前计划或基准计划“应该完成的百分比”呢？这里面有个假设，它假设任务的工作量在工期这个时间段内是均匀分布的，也就是说每天的工作量是相等的。

比如任务工期是10天，从3月1日到3月10日（采用全年无休日历），那么每天“应该”完成10%，就是这么一个简单的逻辑。如果现在状态日期是在第2天（3月2日），那它“应该”完成20%。注意，我们首先按照当前计划的衡量维度来解释，因为它比较好理解，然后再按照基准计划的衡量维度来解释。

假如输入的【完成百分比】是19%，就理解为实际进度小于“应该完成的百分比”，这时候进度线会向左凸起。如图3中的任务A。

假如输入的【完成百分比】是20%，就理解为实际进度满足“应该完成的百分比”，这时候进度线显示为垂直的竖线，不向左凸起。如图3中的任务B。

假如输入的【完成百分比】是21%，就理解为实际进度满足“应该完成的百分比”，这时候进度线也显示为垂直的竖线，既不向左凸起，也不向右凸起。如图3中的任务C。

图3

我想这样给大家解释，应该比较好懂。在图3中没有摘要任务，是三个并行的任务，假如我们创建一个摘要任务，它下面包含任务A、B、C，那进度线又会如何显示呢？

图4

如图4所示，摘要任务的完成百分比是20%，工期是10天，状态日期是第2天，好像它满足了“应该完成的百分比”。实际上，摘要任务的进度线会根据子任务的状态而计算和显示，如果某一个子任务是落后的（输入的完成百分比小于“应该完成的百分比”），那么摘要任务的进度线就会向左凸起，代表落后，如图4中的“摘要任务”。假如子任务都没有落后，那么摘要任务理论上会显示为一条竖线，既不向左凸起，也不向右凸起。

比如，在图4的基础上，我们将任务A的完成百分比改成25%，那么任务A的实际进度（25%）也满足“应该完成的百分比”（20），所以，任务A的进度线显示为一条竖线，如图5所示。

同时，我们看，此时，任务A、B、C都没有落后，所以摘要任务的进度线显示为一条竖线，既不向左凸起，也不向右凸起。

图5

上面举的例子是比较简单的，只是为了给大家解释清楚进度线应该如何计算。但是，我们发现实际上Project软件中的进度线计算是有缺陷的，下面我仍然用实例给大家说明。

我们现在把上面的例子进行改编，现在采用“标准”日历，任务A、B、C的工期仍然都分别是10个工作日，这样这些任务都是从2019年3月1日开始，2019年3月14日结束。假定状态日期是3月2日，任务A、B、C的完成百分比都是10%，如图6所示。

图6

我们看到，由于状态日期是3月2日是一个星期六，不是工作时间，所以在图6中，进度点显示在3月4日开始的时刻（星期一早上8:00），看起来进度线好像是向右凸起的（注意，进度线向左凸起还是向右凸起，是看进度点）。这看起来就不合逻辑，因为任务A、B、C目前的进度明显是落后的，从进度点上应该是向左凸起才对，而在图6中却显示为向右凸起。这是一个问题。

现在假如我们在图6的基础上再进行改编，把任务C的完成百分比改成50%，如图7所示。

图7

图7相较于图6来讲，进度线没有变化。实际上只有任务C的进度是提前的，但是由于状态日期是在一个非工作日，导致任务A和B的进度线还是向右凸起。

现在再次对这个小案例进行改变，将状态日期从3月2日（星期六）改成3月4日（星期一），如图8所示。

图8

此时状态日期是在一个工作日上，我们看任务A、B都是落后的，因为状态日期来到了第二个工作日，这两个任务至少要完成20%才能满足要求，现在完成百分比都是10%，所以都是落后的，因此进度线也显示为向左凸起。而任务C的完成百分比是50%，进度满足要求，进度线就显示为一条竖线，既不向左凸起，也不向右凸起。由于子任务中有落后的任务，所以摘要任务的进度线也向左凸起，显示为落后。现在显示好像是正常的。

再次对案例进行改编，我们将任务A的完成百分比改成20%，如图9所示。由于状态日期来到了第二个工作日，工期是10个工作日，它应该完成20%，目前进度满足要求，所以任务A的进度线显示为一条竖线，既不向左凸起，也不向右凸起。任务C也是如此。任务B仍然是落后的，进度线向左凸起，摘要任务由于子任务中有落后的任务，此时进度线也向左凸起，显示为落后。此时进度线显示也是正常的。

图9

好了，从上面的一步一步演示和解释中，我们能看出来，当状态日期在一个非工作日上的时候，进度线的显示是比较紊乱的，容易对计划阅读者造成困扰。这是软件需要改进的地方。

我们再次对案例进行小小的改编，假如我们任务A、B、C的完成百分比都改成0，状态日期仍然是3月4日，很明显子任务都是落后的，任务A、B、C的进度线都向左凸起，如图10所示。但是摘要任务的进度线却显示在完成时间上，进度线向右凸起，这也不合理。

图10

所以，当计划做完了，所有子任务都还没有更新完成百分比的情况下，摘要任务的进度线显示也是有问题的。我认为软件这是软件需要改进的地方。

本文开始的时候讲了，进度线有两个比较维度，一个是当前计划，一个是基准计划。上面把第一种情况（就是跟当前计划对比）讲过了，现在我们再解释一下按照基准计划去对比。

我们在图10的基础上对案例进行改编，假如还是采用全年无休日历，任务A、B、C的工期都是10个工作日，从3月1日到3月10日。然后我们保存一下基准，并切换到跟踪甘特图视图，如图11所示。

图11

注意在图10中，任务A、B、C的完成百分比都是0，状态日期是3月4日。

在甘特图区域鼠标右键点击【进度线】，在弹出的进度线窗口中，如图12所示，在【日期与间隔】窗口中勾选【显示】，默认会勾选【在项目状态日期】，本文都是以状态日期来解释，如果用当前日期，原理相同。然后在进度线窗口右下角点击勾选【基准计划】，点击确定按钮。

?

图12

在图13中我们看到，状态日期已经来到了3月4日，按照基准计划计划的话，应该完成40%，而任务A、B、C的完成百分比都是0，明显是落后的，所以进度线都是向左凸起的。摘要任务的进度线也是向做凸起的（对比图10，按照基准计划显示进度线时，任务还未更新完成百分比时，至少摘要任务的进度线显示还是正常的）。

图13

现在我们分别输入任务A、B、C的完成百分比是20%、41%、39%，如图14所示。按照基准计划的话，在状态日期这一天（第4天），任务A、B、C应该完成40%，所以此时只有任务B满足了要求，所以任务B的进度线显示为一条竖线，而任务A和C的进度线显示为向左凸起，同样，由于子任务中有落后的，摘要任务的进度线此时也显示为向左凸起。此时进度线显示是正常的。

图14

假如任务C的实际状态不是这样的，它实际上是在3月2日才开始的，我们输入实际开始时间为3月2日，但是在状态日期时我们重新估算了它的工期，认为只需要8天就可以完成，我们将其工期改为8。当前的完成百分比我们假如输入50%。如图15所示。

图15

我们看，此时任务C按基准计划的话，在3月4日这一天只需要完成40%就可以了，而实际上任务此时已经完成了50%，所以理论上讲，任务C是提前的，但是进度线却显示为向左凸起，好像是落后的。这是不合理的地方，所以按照基准计划显示进度线一定要慎用，可以说软件的设计还不严谨。

实际上，还有很多情况，按照基准计划显示进度线时，显示结果都是混乱和没有逻辑的。比如图16中，任务A的预估工期相比原来的基线工期缩短了，当前完成的百分比也达到了40%，但是进度线却向左凸起，任务B也向左凸起，看起来都是落后的，而摘要任务的进度线却想右凸起，完全不符合逻辑。

图16

所以，Project软件里面的进度线，在按照基准计划显示时，我认为是有比较严重的缺陷的，建议大家还是不要用了。即使是按照当前计划显示进度线，如上文中所讲的，也有一些问题。这就是我在课程以及书中都不愿意讲解进度线的原因，因为它的设计不成熟，不能起到正确的指导作用，那为什么还要使用这个功能呢？或者说，至少在现有版本一直到Project 2016，还是暂时别用这个功能了。也许软件在今后的迭代版本中会对进度线进行优化。

我相信很多人在自己的Project计划中显示了进度线，但是却没有认真思考过这个进度线是否能够真正指导我们的工作，抑或仅仅是为了让计划看起来牛逼闪闪？