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計劃中顯示了進度線，但是卻沒有認真思考過這個進度線是否能夠真正指導我們的工作，抑或僅僅是為了讓計劃看起來牛逼閃閃？