1、進度管理：項目進度的黑洞項目進度控制是項目管理工作中的重要一環，但現在的軟件開發項目進度 失控的例子卻屢見不鮮，甚至進度的延遲總是在快到計劃結束的時刻暴露出 來，然后誰也不知道到底什么時候才能夠結束項目。因此，業內流傳著這樣一 句令人心酸的話： “規劃規劃全是鬼話，計劃計劃全是空話 ”。前不久，我就遇 到了這樣的一個實際項目。“當進度報告上顯示已完成 90時，項目就像遇到了一個黑洞，不斷地吞噬 著項目組隊的時間。你說這是怎么了？ ”在 A 公司工作的一個好友和我談起時， 話語中露出了深深的不解和抱怨。是呀，問題出在哪呢？根據我的經驗，這是 經典的“上梁不正下梁歪 ”問題，我認為要想對項目進度有

2、效的監控與管理，必 須抓好以下兩個方面：q 項目計劃：計劃的可行性和可操作性是進度監控的基礎；q 項目進度度量：對項目進度進行科學的度量，才能夠獲得項目的真實進展 情況，并對項目計劃做出相應調整。首先，我們從 90，這個項目完成百分比的來源說起，項目經理在進度報 告中寫下這個值的時候，他的依據是什么？在這個項目后來的實際情況來看， 當時 90的數字是有誤的，其實只有 50左右，說明獲取這個進度數字時出現 了問題。為了更好地理解這個問題，我們來看一個生活中的實際例子：假設我們驅車從廈門開往福州，在途中我們如何獲得進度信息呢？對于熟 悉這一路段的司機來說這個問題很簡單，可以從窗外的景象來得知已經開

3、到哪 里，從而做出正確的估計。但是對于軟件開發項目而言，項目團隊就像進入了 一個全新的征途，就像一個次駛過這一路段的司機一樣，很難從 “窗外的景象來判斷自己的進度。那對于這樣的情況，該采用什么方法呢？對于司機而言， 他能夠通過路邊的里程碑這一個簡單工具來獲知自己的進度信息，那么為什么項目團隊不為自己設立一些這樣的 程碑”呢？從這個簡單的故事中，我們似乎已經可以得到一些啟示，那么現在問題的 關鍵在于如何合理地設立標識項目進度的 “里程碑 ”，接下來我們來看看具體如 何操作。在一個軟件開發項目中，需要完成的事務很多也很復雜，其復雜度足以讓 任何人無法對其工作量進行有效的估計，因此對工作任務進行分解

4、是十分重 要，這也是設定里程碑的基礎。但如何進行工作任務分解呢？這也許也是困擾 許多人的一個問題。其實工作任務分解可以從兩個方面獲得幫助：q 軟件開發生命周期：不管你打算采用什么樣的軟件開發生命周期模型，它 都可以幫助你將整個軟件開發項目進行階段性的劃分，而這些階段就可以做你 計劃中很重要的里程碑。q 軟件開發需求：軟件開發生命周期只給你的項目計劃提供了一個框架，而 軟件開發需求才是其中的血肉，因此軟件開發需求的整理與規格化，是細化項 目計劃的基礎。也就是說，在制定項目計劃時，應該在你選擇的軟件開發生命 周期模型的框架下，結合軟件開發需求來細分任務和設定里程碑。回顧在這個項目中，他們考慮到項目

5、的復雜性，采用了其熟悉的瀑布型 （軟件開發生命周期），并且在制定計劃時，項目經理認真參考了許多經驗 值，將 2 個月的時間按照經驗值中的百分比給需求分析、系統設計、編碼實 現、系統測試、部署交付五個階段分別安排了時間。并且根據軟件需求說明書 的內容，列出了軟件模塊，并根據每個模塊細化了系統設計和編碼實現的進度安排。一切看起來都很 正常，但是為什么還是沒有效果呢？我從他們對細節的回顧中發現了一些問題：q 所有的項目計劃均是由項目經理的估計值制定的，也就是說項目經理包辦 了整個項目計劃的制定工作；q 在項目計劃中只是簡單地在每個階段的結束時間上標上了一個里程碑符號；q 進度報告中的項目完成百分比，

6、是直接通過 “已經歷的時間 （2 個月） ”計算 得到的；q 項目過程中，需求在變化，但項目計劃卻沒有跟進；q 項目延遲的主要原因在于兩個方面：項目需求增加，以及系統設計和編碼 實現的時間都超過了原先的計劃。這一切就是典型的項目進度失控的直接誘因，相信這些項目中都能夠發現 以上問題的影子。那么如果避免或者解決這些問題呢？在我的資料庫中，包括 以下幾個針對此癥的 “藥方 ”，在我的實踐中收到了良好效果，你也不妨試一 試。個藥方是以面向客戶的角度整理需求。我看到許多軟件項目開發團隊進入 了系統設計和編碼實現階段之后，在整個開發團隊之間的交流里充滿著計算機 領域的東西，卻難得見到問題領域的東西，這樣

7、很容易造成軟件開發與客戶需 求的脫節。因此，從一開始就以面向客戶的角度來整理需求，讓這些需求的實 現成為項目團隊共同的目標，這將容易使項目始終保持正確的方向。 UML 中的UseCase特征驅動開發中的Feature、極限編程中的UserStory都是很好的辦法，以這些方式組織的需求，作為項目計劃中的血肉，將更有利于進度的安排 與控制。第二個藥方是項目團隊共同完成項目計劃。項目計劃的一個很重要的前提 是項目估算，項目估算的基礎是經驗值，而軟件工程書籍中的經驗值反應的只 是業界的實踐，并不能夠反應你的團隊，因此在項目估算時應該以自己團隊歷 史經驗值為基礎，讓項目團隊中的每一個成員參與估算，這樣才

8、能夠保證項目 計劃的可行性。從而避免在本例子中出現的系統設計與編碼實現都超出原先的 計劃的情況。根據我的實踐經驗，在制定項目計劃時，可以將承載著客戶需求 的用例、特征或用戶故事分配給具體的開發人員，讓每個開發人員進行估算， 并與項目經理進行協商，達成共識。如果每個用例、特征或用戶故事太大，以 至于估算的時間超過 2 周，就對其進行細分，直到每個任務塊小于 2 周的時 間。后通過任務卡的形式分配給每一個具體的開發人員，這樣就可以保持項目 計劃與個人的進度計劃高度的一致，保證整個項目計劃的可行性。第三個藥方是確保里程碑是可驗證的。經常看到許多項目計劃中，都學會 了像模像樣地設立了里程碑 在用 Pr

9、oject 繪制的甘特圖中標上一些黑色實心 的菱形，但卻又發現這些標記這些菱形的項目經理對里程碑的理解是那樣的脆 弱。的問題就在于很多里程碑沒有相應的驗證標準，也許是有人不小心把公路 上的里程碑概念完全帶入軟件開發項目中來的緣故吧。在軟件開發項目中設立 的里程碑，其作用是在項目進行時確認進度用的，因此需要給出一個清晰的驗 證標準，用來驗證是否達到里程碑。而驗證的標準可以是事件，也可以是工 件，例如 : “已完成規格化的軟件需求說明書的編輯 ”、“軟件需求說明書通過客戶 簽字確認 ”可以做為需求分析完成里程碑的驗證標準。再如： “已擁有程序的可 執行版本，實現了 XX特性，并通過測試”作為編碼實

10、現階段中的一個子里程碑 的驗證標準。第四個藥方是根據項目的變化報考的更新項目計劃。拿破侖曾經說過，沒 有一場戰爭是按照計劃打的，但沒有一場戰爭可以在沒有計劃的情況下贏得 的。這句話深刻地詮釋了事情發展的報考性，因此在項目開發過程中，項目計 劃是不可能保持一成不變的。而是應該根據項目的進展，對一些新的需求、新 的變化、突發因素做出響應，報考的更新項目計劃。例如，當用戶提出新的需 求時，應該分精力進行分析，做出對項目計劃影響的結論，并通過協商與談判 來調整項目計劃。而面對報考變化的環境，采用迭代式的生命周期模型將使你 的項目開發團隊更好地適應變化。第五個藥方是根據里程碑完成情況編寫項目 進度報告。

11、另外，標識里程碑時，應該同時賦予里程碑標識進度值的功能，更 通俗地說，就是讓每個里程碑帶上一個百分比，告訴團隊通過這個里程碑說明 項目完成了多少。這樣，項目進度報告上的完成百分比將顯得更加真實和有意 義。當然隨著項目計劃的報考變化，未到達的里程碑的這一值也應該做出相應 的調整。項目管理是一個實踐學科，理論指導只能夠幫助你正確地做事，為你 的實踐提供一些方法與指南，卻無法保證項目成功。 “銀彈 ”并不存在。在實踐 中去發現問題、解決問題、總結思路，才是有效的辦法。后，也奉勸每一個項 目管理者，不要迷信標識進度的 “已完成百分比 ”，從黑洞中逃離。項目背景： A 公司前不久接下了一個客戶化開發的軟件項目，其主要的內 容是為一個汽車銷售公司做一個 MIS系統，并且要求整個項目將在2個日歷月 之內完成。合同簽署之后，該公司指派了一名項目經理，該項目經理看上去也 十分認真，在經過了需求調查之后，他就向公司提交了一份詳細的項目計劃 書，而且項目完成的時間也完全與合同要求相同，整整 2 個日歷月，一切看起 來是那樣的順利。時間過得很快，項目似乎也進展得很順利，項目經理也嚴格按照規定每周 上交了用 Project制作的漂亮的進度報告，項目完成的百分比也一直和項目計劃保持著一致，很快到了第八周，項目進度指示已完成 90。但是，第九周出了問題，項目無法按時交付，希望能夠再延長兩周