制定項目里程碑 - 我們一起學項目管理 （十一）

4 人贊了文章

上回說到項目經理授權後的第一步動作，將需求轉化為了具體的任務。但是光有任務還遠遠不夠。對於任務還需要有一個大致的估算，這是在具體活動出現前的估算。明確任務層級的關鍵路徑。通過任務估算和關鍵路徑，可以獲得項目里程碑。

所以第二步動作是在任務的基礎上制定粗略的計劃。當前我們手頭上有以下信息：

1. 項目章程

2. 大而粗的項目時間節點

3. 干係人列表

4. 工作分解結構 （WBS）

5. 工作分解結構詞典

6. 項目範圍說明書

7. 需求管理計劃

8. 需求跟蹤矩陣

而做完第二步還將得到基於WBS的工時估算，項目的關鍵路徑以及項目里程碑。大致的流程如下：

《一》工時估算

這步的輸入是工作分解結構，而輸出是基於工作分解結構的工時估算。

對於一個項目來說，工時估算一般會有三次，

第一次發生在投標之前，需要估算項目成本。

第二次發生在項目啟動會議之前，主要用於制定項目里程碑。

第三次會在啟動會議之後，用於制定項目計劃。

區別在於詳細程度逐次遞增。第一次是非常粗略的估算，可能是基於歷史數據，也有可能是拍腦門得出的結果。第二次是在任務明確的基礎上的估算，精度會上升很多。第三次是基於活動的估算，此時的估算是項目計劃的基礎，需要非常精確，一般推薦三點估算方式進行。如果今後遇到項目需求變更，也需要使用三點估算進行估算。

現在回到基於工作分解結構的估算上來，對於此時的估算，多數使用的是基於歷史經驗，歷史數據的類比。如果做房屋裝修，對於項目經理來說，基本明白粉刷牆壁，鋪設地板，排布電線水管等等工作大致需要的時間。這些都是從歷史經驗上類比而來。

也許你會說那不是很不精確嗎？的確，在這個階段的估算並非十分精確，也沒有必要。原因在於：

1. 此時的項目需求也是比較粗略的，具體需求細節並未確定。

2. 項目資源並沒有明確，也就是說，在什麼階段需要什麼樣的資源，資源的個數都么有最終確定。

項目管理三角形中兩項要素都存在變數。自然此時的估算帶有大的誤差是可以理解的。

那麼這樣一個不精確的估算的意義是什麼呢？

在於被否定，被更新，逼近真實的情況。

這就好比定位一樣，當要找一個人的時候，起先定位到他在中國，那就不會去美國找。而隨著時間的推移，發現他在中國上海，那就不會去南京找。最後發現他在中國上海的外灘，那就不會去外灘找。

估算也一樣，隨著需求的明確和深入，對於估算的也隨之越來越準確。即使之後的估算推翻了之前的，這種情況經常會有，但是至少因為之前的估算，任務得以繼續，不會舉步不前。

於是在完成估算之後，對於每一個任務都有一個完成工時的估算。

《二》明確關鍵路徑

同樣的，工作分解結構中把任務進行了系統的羅列，基於他，可以產生項目關鍵路徑。

對於任務，可以分為兩種，一種和其他任務沒有關聯，相對獨立。另一種需要以完成其他任務為條件。對於第一種任務，只需要安排人做完成即可。而對於第二種任務，就需要根據其前置條件，制定任務拓撲圖。

在這個階段，需要將工作分解結構中所有任務，都放置到拓撲圖上去。如果兩個任務有關聯，需要標明之間關係。比方說粉刷牆壁的任務需要在水泥干後才能開始，那麼在這兩個任務上就需要有帶方向的箭頭標明先後關係。

下圖為關鍵路徑拓撲圖的一個例子：

方塊內為任務，以及需要的工時，連線標明任務的關係。

當把所有任務都羅列到拓撲圖中去之後，需要計算每條線路的時間，而時間最長的那條代表項目完成的最短時間，即項目的關鍵路徑。

值得注意的是，隨著項目的變化，需求的變化，資源的變化，關鍵路徑是會發生變化的。這需要項目經理時刻對於項目有個整體的把握，尤其在關鍵路徑上。

關鍵路徑的變化代表著工期的變化。並不是所有任務的延期都會造成項目交付的延期。但是關鍵路徑上任務的延期，必然造成交付的延期。

《三》確定項目里程碑

當經過工時估算和關鍵路徑確認之後，我們得到了每個任務的工時以及任務和任務之間的關係。同時在工作分解結構中，對於任務有了階段層級的歸類。這在賬戶編碼中可以體現見下圖：

在1.x這個層級1.1.1與1.1.2必然都屬於需求評估階段，而 1.1.1和1.2.1，必然不屬於同一階段，因為評估和開發不會混在一起。

所以根據不同的賬戶編碼，可以將任務歸類，而歸類的粒度可以根據賬戶編碼得以控制。

於是在關鍵路徑拓撲圖中，可以加上賬戶編碼。從中根據需要的粒度，提煉出各個階段所需要的時間。

拿軟體開發舉個例子，對於一個完整的項目，會有如下的工作分解結構：

這裡不妨做一個資源的假設，即我有一個BA做需求文檔，有一個資源做頁面設計，一個資源做資料庫設計以及一個資源做服務層設計，相應的，設計人員兼顧開發。有一個測試，以及一個資源專門負責部署。

對應的關鍵路徑拓撲圖：（下圖的關鍵路徑看出來了嗎？是 1.1.1 -> 1.4.1->1.4.2->1.4.3->1.5.2 哦）

於是得到了以下結論：

需求分析： 5天

設計： 2 天

開發： 2天

測試： 15天

部署：1天

結合最開始的大而粗的項目時間節點，獲取客戶要求的交付日期，倒推各階段的開始結束時間。如客戶要求11月30日交付。那麼可以得到如下結論：

部署： 開始時間 11月30號，結束時間 11月30號

測試時間：開始時間 11月9號，結束時間 11月29號

開發時間：開始時間 11月13號，結束時間 11月15號

設計時間：開始時間11月9號，結束時間 11月10號

需求分析時間：開始時間11月2號，結束時間11月8號

從而得到了各個裡程碑時間。

最後，還需要和當前客觀情況進行對比。問問自己，可行嗎？顯然如果今天是11月13日，這個計劃是不可行的。按照當前資源來說，需要在 11月2號開始需求分析。實際上是13號。於是在不更改交付日期的前提下，需要增加資源。

大致方案如下，增加為2個BA，縮短需求分析的時間為3天。開發人員不變，測試人員增加為2人。於是對應的拓撲圖發生了變化，關鍵路徑也發生了變化（1.1.1->1.2.1->1.3.1->1.4.2->1.4.3->1.5.2)

於是再次根據交付時間倒退里程碑得到如下：

部署： 開始時間 11月30號，結束時間 11月30號

測試時間：開始時間 11月20號，結束時間 11月29號

開發時間：開始時間 11月21號，結束時間 11月22號

設計時間：開始時間11月17號，結束時間 11月20號

需求分析時間：開始時間11月14號，結束時間11月16號

這個計劃按照當前是11月13號的情況下，是可行的了。於是我們得到了項目的里程碑。

推薦閱讀：