PMI 所定義的專案時間管理過程被分為 6 個子過程，分別是定義活動，排列活動順序，估算活動資源，估算活動持續時間，制定專案進度計劃和控制專案進度計劃。這 6 個過程在專案過程中並不一定是順序進行的，而是穿插在專案管理的整個流程中，遵循漸進明細的規律，其中前 5 個子過程時間上屬於專案進度的制定，第六個過程屬於專案進度的監控。

定義活動

即識別為完成專案可交付成果而採取的具體行動的過程。也就是在確定了專案的基本範圍基準的基礎上，將 WBS 分解為更為具體的，粒度更小的工作 item 方便落實到確實可行的具體工作上，過程輸出通常會包括具體的活動清單，相關的屬性（如資源需求，制約因素，假設條件，活動名稱等）以及里程碑活動。該過程並不是一蹴而就的，通常會以漸進明細的方式進行，對於近期要完成的工作詳細規劃，而對遠期要進行的工作只做粗略規劃。在專案進行過程中，某些活動的完成意味著專案取得了關鍵性的進展或是某個專案階段的結束 . 這些重要的時間點被稱作為里程碑。里程碑事件可以用里程碑圖進行表示，有利於就專案的狀態與使用者和組織的上級進行溝通。

排列活動順序

專案所需要完成的具體活動條目之間並不是完全獨立的，存在一定的邏輯關係，該過程就是要識別活動與活動之間的邏輯關係，並進行排序以決定活動之間的先後完成順序並形成專案的進度網路圖。活動與活動之間的邏輯關係包括以下幾種：

1. 完成到開始（FS）：前一個活動完成之後後續活動才能開始
2. 完成到完成（FF）：兩個活動中只有一個完成之後另一個才能完成
3. 開始到開始 (SS)：兩個活動中只有其中一個開始了另外一個才能開始
4. 開始到完成 (SF)：一個活動的開始意味著另一個活動的完成。

在該過程中，常用的方法是在識別活動之間邏輯關係的基礎上利用緊前關係繪圖法（PDM）編制進度，同時需要確定相關依賴關係，包括強制性依賴，選擇性依賴以及外部依賴關係，其中強制性依賴是由工作本身的性質或者客觀條件相關所限制產生的必須滿足的依賴，而外部依賴往往與活動相關卻又不在專案的控制範圍內。此外為了更為準確的表示活動之間的邏輯關係，需要考量時間提前量和時間滯後量。該過程一個重要的輸出是專案進度網路圖，在繪製專案進度網路圖的時候可以利用標準化的進度網路圖模板，可加快活動網路圖的編制進度。除了首尾兩項，每項活動和每個里程碑都至少有一項緊前活動和一項緊後活動。

估算活動資源

資源即財力，物力，人力，裝置用品等，該子過程識別為了完成具體的某一項活動所需要的相關資源的配備，使用和規劃情況。它與活動的具體屬性以及資源的特性和限制等客觀因素相關，因此在該過程中需要將活動屬性和資源日曆作為一個具體的輸入之一，資源日曆包括資源的可用性，時間性等相關資訊。該過程輸出的準確性與否與專案成員的經驗以及所採用的估算技術密切相關，因此經常需要藉助專家判斷，以及一些較為權威的估算資料（如以往類似專案的經驗），或者進行自下而上的估算方法，即先將活動細分，然後估算資源需求然後再進行彙總。

估算活動持續時間

根據資源估算的結果估算完成活動所需要的時間的過程，通常由專案團隊中最熟悉具體活動的小組或個人來提供輸入，該過程也是一個漸進明細的，當專案相關的資訊越來越準確，詳細的時候，該過程的輸出也就越準確。估算往往會受到一些因素的影響，如人員的熟練程式和工作效率，對於未知和突發事件的風險預測，溝通和衝突損失以及活動細節等。如果將風險因素考慮進來，可以採用三點估演算法，該方法給予 PERT 技術，在估算最可能時間 TM，最樂觀時間 TO，最悲觀時間 Tp 的基礎上採用加權平均（TO+4TM+TP）/6。

制定專案進度計劃

該過程通過分析活動順序，持續時間，資源需求以及進度約束來編制專案的進度計劃，目的是確定專案活動的計劃開始日期和計劃完成日期，並確定相應的里程碑。在該過程中常用需要用到多種技術的綜合，如進度網路分析，關鍵路徑法，資源平衡，進度壓縮等，其中關鍵路徑法與網路分析較為常用，有些進度計劃編制工具會直接實現這些方法以達到自動分析的目的，藉助專案管理工具也是一個較為明智的選擇。關鍵路徑決定了專案完成所需要的最短時間，它是網路圖中具有最長總工期的活動序列。在關鍵路徑的計算過程中，需要針對每個活動確定以下四個引數：

1. 最早開始日期 (ES)：活動能夠開始的最早日期（根據該活動的約束和依賴關係確定）。
2. 最早完成日期 (EF)：活動的最早開始時間加上完成此活動所需的時間。
3. 最晚完成日期 (LF)：在不會導致計劃延誤的情況下可以完成活動的最晚時間（根據該活動的約束和依賴關係確定）。
4. 最晚開始日期 (LS)：最晚完成時間減去完成此任務所需的時間。

而關鍵活動就是位於關鍵路徑上的這些活動，這些活動有一些共同特徵，即活動的最早開始時間與最晚開始時間的偏差或最早完成時間與最晚完成時間之間的時間差為零。因此該活動的延遲將會導致專案的延遲。

控制專案進度計劃

該過程監控專案的狀態和進展，在進度基準的基礎上比較專案的實際情況和計劃情況之間的偏差，並通過分析這些偏差以及對進度變更的因素施加影響來促使專案向健康和可控的方向發展。因此該過程不僅依賴於專案的初始進度基準，同時還依賴於具體的專案績效資訊以及相關的變更狀態，在實際過程中可以藉助一些優秀的專案管理軟體，如 RTC，它不僅能自動收集專案相關的績效資訊，而且提供了較為人性的進度管理介面，方便進行偏差分析和資源平衡等來達到進度控制的目的。

表一列出了 PMI 所定義的時間管理的各個子過程的輸入，輸出，工具和技術。

時間管理各子過程的輸入，輸出和工具

現實中需要實施有效的進度控制

1. 制定詳盡的、可行的專案進度的基準計劃

我們知道，計劃是行動的指導，是行動成功的關鍵所在。對於專案進度控制而言，計劃尤顯重要，它影響到資源能否被合理使用，專案能否順利進行，直接關係到專案的成功與否。

進度計劃包括：任務、資源、時間等三部分內容。

任務來源於工作分解結構和活動定義。要進行有效的進度控制，就要求必須有細緻的、可執行的、可檢查的、可控制的活動定義(任務)。任務的粒度要求適中。對於不成熟專案和管理水平不高、資源能力不強的專案而言，粒度不能太大，否則難以實現專案的控制;反之任務的粒度可以適當大一些。每項任務需要有明確的責任人、起止時間和工期。

如果專案管理的水平不是很高的情況下，欲實現有效的進度控制，每項任務的工作量以不大於專案的總體工作量的5%為宜，工期以不大於專案總工期的10%為宜。

2. 建立有效的風險防範計劃。

有效的風險防範計劃可以降低不確定性因素對專案工期的影響，保證專案的順利進展。風險防範的工作可以包含以下方面：

(1) 制定一套專案風險防範的體系，包含：風險識別，風險確認，風險應對等方面的完整內容。這部分工作一般來講，會由公司級專案管理體系來進行定義和規範。

(2) 針對專案，提出專案風險的協調負責人，及相應的協調措施。

(3) 在專案組內部建立對風險識別的特殊機制，如：每個人可以根據自己的工作內容，定期列舉風險指數最高的5個風險，並提出相應的應對方案。

3. 建立良好的專案組內部及專案干係人之間的溝通管理制度。

溝通是掌握各方資訊，進行專案決策和專案協調的基礎。實現有效進度控制對於溝通的要求，主要強調以下幾點：

(1) 及時與專案客戶進行溝通，瞭解其對於專案的特殊進度要求，以實行對工作任務的特殊處理。

(2) 對於需要專案組之外的資源進行配合的工作，及時通過有效的溝通途徑提交給相關人員，以提早準備好配合的工作，免得影響專案的進展。

(3) 充分發揮專案組成員的作用，使之參與到問題解決當中來，如專案偏差的處理，風險的預防等。

(4) 定期舉辦專案進展的溝通會議，瞭解各成員的任務執行情況，通報專案的整體進展情況。

4. 進行進展檢查，並針對檢查結果採取相應的對策。

在進度控制當中，進度檢查是最重要的和最關鍵的工作，如果不能瞭解專案實際進展情況，也就很難說執行什麼進度控制了。

進度檢查可以定期進行或不定期進行。

定期執行的進度檢查是指在預定的檢查週期內執行的檢查工作。檢查週期是由專案組根據專案的實際情況來預先確定，可以為月、半月、周、半周、日等時間階段。對於時間跨度比較大的專案，可以週期相對長一些，如：工期超過兩年的專案，檢查週期可以定為一個月;工期在3個月左右的專案，檢查週期可以定義為1周。對於管理水平較高、資源能力較強，實施較成熟的專案，檢查週期可以適當的長一些，反之亦然。建議檢查週期應該以不高於工期的5～10%為宜，檢查工期不超過1個月，根據工作彙報機制的慣例，對於普通專案檢查工期可以定為1周。

不定期的進度檢查，可以在關鍵任務或里程碑任務的計劃完成時間進行，一般不定期的任務檢查，是有一定的針對性和目的性。

進度檢查工作可以分為四個步驟執行：

第一步：收集專案任務的進展資訊。

收集專案的進展資訊，是進度控制的基礎，它主要是通過各種方式，收集專案的進展資訊，作為執行下步工作的依據。

主要的工作方法有兩種：進度彙報和進度查驗。通常情況下，專案經理採用由下屬進行主動彙報的方式來完成專案進展資訊的收集工作，這被稱為進度彙報;針對於某些工作，專案經理也可以採用直接檢查的方式來獲取進展資訊或驗證彙報資訊的準確性，也就是進度查驗。為了獲得準確的專案進展資訊，專案經理必須將兩種方法進行有效的結合使用。

需要收集的專案進展資訊包括：任務執行狀況和變更資訊。任務執行狀況包括：任務的實際開始和結束時間，當前任務完成的程度等;變更資訊包括：範圍變更、資源變更等諸多與專案進度相關聯的變更內容。

另外，合理選擇任務執行狀況中的任務粒度也是必需掌握的技能。一般情況下，會根據專案進度基準計劃中的工作分解來進行。具體的情況，可以根據實際狀況來決定。對於專案組織內部有較細的結構劃分時，需要採用由下向上逐級檢查，逐級彙報的方式。

這一步驟的工作要求收集的資訊必須準確，否則下面的工作將沒有如何意義，同時也就根本不可能實現有效的進度控制。

第二步：進行專案實際進展資訊與進度基準計劃的比較

將收集到的專案實際進展資訊與專案的進度基準計劃進行比較，看是否出現了進度偏差。如果沒有偏差，進展檢查到此結束，否則執行下一步工作。

第三步：針對出現的進度偏差，尋求最佳解決方案

如果出現了進度偏差，針對這些偏差進行分析和研究，發現其中的問題。如果需要問題解決，則針對問題尋找解決方案;如果需要進度計劃的調整，則修改進度計劃。

專案實施過程中出現進度偏差是在所難免的，實施進度控制就要求能對偏差能進行有效的控制，提出相應的解決方案，使之有利於專案的進展。通常我們可以採取的措施有：

第四步：執行進度調整後的進度計劃和確定的解決方案

根據偏差的處理決定，執行解決方案，調整專案進度計劃。如果需要的話，通知專案干係人。

當進度偏差比較大時，需要考慮縮小檢查週期，以便更好監視糾正措施的效果，以保障專案的按期完成。

5. 預見性的發現和解決專案實施中的問題

在專案的實施過程中，專案的進度延期，實際上有很多的苗頭可以預見性的去發現，發現後就可以及時去採取對策進行問題的解決，這種將問題消滅在萌芽狀態的做法，可以有效的保障專案的順利進行。下面列舉說明可以預見性發現的問題及解決方法：

問題預見性發現問題的方法(解決的方法)：

敏捷專案的進度管理

關於敏捷專案進度管理中縮短專案工期的實踐、進度資訊的獲取與核實、進度資訊的展現、傳播及其激勵作用。並介紹了專案進度管理與風險管理、期望值管理間的關聯。

優化專案計劃

敏捷開發的基本特徵是迭代開發。而迭代開發的強調的是"小批量、頻繁交付"。因此，每次迭代所要實現的需求相對較少。這使得迭代開發中的專案計劃制定相對容易，制定專案計劃時任務與任務間的邏輯關係也比較容易掌握。但是，由於迭代開發往往採用時間盒（Time-box）的方式進行，即要求每次迭代的時間是固定的（業界推薦的是 2~4 周）。而每次迭代所要實現的需求（Story）的個數及其難度都不盡相同。這就要求我們在某些情況下要儘可能地優化專案計劃，以保證工期不會超出時間盒的範圍。

優化專案計劃的常見方法是儘可能地使各個任務並行。比如，有兩個功能的開發任務，其中一個功能 A 依賴於另外一個功能 B。但這並不意味著我們必須將這兩個功能的開發任務序列安排（即先開發 B 功能，再開發 A 功能）。此時，可以使用測試樁（Testing Stub）來模擬 B 功能的實現，這樣使得 A 功能的開發和測試可以先獨立於 B 功能的實現。因此這兩個功能的開發可以並行。

計劃安排時考慮避免重複勞作也是縮短工期的一個常見方法。在 Story 驅動的一個迭代開發過程中，從第二個迭代開始，往往存在多個 Story 的實現涉及同一個模組的程式碼修改。此時，計劃可以安排多個人並行開發這幾個 Story、但是轉 Story 測試時，這幾個 Story 可以合併成一個"大 Story"一起轉測試。從而避免了多次測試同一個模組帶來的浪費。

出於應對風險的需要在安排計劃時留出所謂的緩衝時間有其合理性。但是，這個緩衝時間延長了任務的持續時間。而關鍵任務持續時間的延長則延長了整個迭代持續的時間。值得注意的帕金森定律（Parkinson's Law）所闡述的現象卻給了我們在某些情況下要適當壓縮任務尤其是關鍵任務的持續時間。帕金森定律告訴我們：只要還有可用的時間，一件工作消耗的時間就會不斷地擴充套件，直到用完所有的可用的時間。也就是說，一件任務如果需要 3 天時間完成，而計劃安排的持續時間是 5 天的話，這個任務會消耗 5 天甚至更多的時間才能完成。這種現象的方面給了我們一個啟示：如果一件任務如果需要 3 天時間完成，而計劃安排的持續時間是 2 天，那麼這件任務真的可能在 2 天內完成，最多也可能是 4 天時間完成。這也比將該任務計劃為 5 天完成節省時間。可見，過於寬鬆的機會反而可能拖慢了進度，而有一定緊迫感的計劃所帶來的適當壓力可以激發人的動力和潛能反而可以加快進度。

對於迭代中的技術風險點要優先安排進行驗證。比如，對於從未使用過的技術或者新技術，要優先安排原型的驗證，避免中途才發現技術障礙。

進度資訊的獲取

由於團隊開發中的每個團隊成員的日常工作之間都存在或多或少的依賴關係：某個人的工作要以其他人的一件工作產出為輸入，同時其工作的輸出又是另一個人的某件工作的輸入。

從團隊自我管理的角度來說，進度資訊是將團隊成員的工作自主得銜接起來的重要因素。因此，敏捷開發團隊中，進度不應該是隻有專案經理才關心的事情，而是整個團隊成員都應該關心的事情。但事實上，團隊成員往往傾向於只關心自己手頭上的工作。因此，專案經理需要引導和鼓勵團隊成員主動關注自己手頭上的任務所依賴的任務的進度。

另一方面，進度是整個團隊應該關心的事情，這就要求在團隊內有一個統一的進度資訊獲取與釋出的平臺和途徑。這個平臺可以是一個管理軟體，比如工作流軟體。也可以是一個即時通訊軟體。不管採用什麼樣的平臺，專案經理應該引導和鼓勵團隊成員主動將各自的進度資訊推送到這個平臺，而不是每個人進度還要等其他人來詢問。

站立會議也是進度資訊的釋出和獲取的一個常見途徑。站立會議中，每個團隊成員都要介紹自己昨天完成了什麼，今天計劃做什麼。這樣，每個人的進度資訊都可以讓其他人瞭解到。

定義完成的標準和進度資訊的核實

獲取進度資訊後，要及時對其進行核實。敏捷開發中的優秀實踐"定義完成的標準"（Definition of Done）可以幫助我們對進度資訊進行核實。

下面我們討論什麼是完成的標準、定義完成的標準的作用以及如何定義完成的標準。

曾經有個剛剛開始帶領團隊的人向我諮詢這樣一個問題：他向他的組員分配一個任務，然後他不定期得檢查這個任務的進度。可是每次他檢查進度的時候，他的結論都是這個組員的工作成果沒有達到他所期望的，而這個組員卻是認為自己已經完成了當天的任務。這種情形導致這種組員不斷得為返工而加班，最後導致其身心俱疲，提出離職申請。事實上，這樣一個問題產生是因為任務的分配者和執行者事先沒有約定好什麼叫做"完成"。雙方都只是在依照自己心中的"標準"來判斷是否完成，從而導致了對於進度認定的衝突。

可見，在我們斷定一個任務是否完成、進行到什麼情況前，首先要規定什麼叫"完成"，否則就會在衡量進度的時候產生上述例子中的衝突。這種對於什麼才叫做完成的規定就叫做完成的標準。顯然，進度不能在脫離質量的前提下孤立得衡量，因此完成的標準不僅定義了質量要求（通常是最低質量標準），也是進度衡量的重要依據。

比如，如果你讓一個沒有什麼工作經驗的人去安裝一個數據庫管理系統（DBMS），他很可能就是把安裝程式執行一遍，若執行過程中沒有遇到安裝程式提示錯誤就認為是完成了軟體的安裝。而最後，其他人都不知道這個已經安裝"完成"的軟體的訪問資訊，比如它所在機器的 IP 地址、偵聽埠。甚至知道了這些資訊後，在實際使用時卻發現所安裝的軟體根本就無法正常運作。

其實，對於這樣一個任務我們可以定義一個完成標準：所安裝的 DBMS 要經過驗證（比如使用 SQL 能夠在資料庫中插入一條記錄，並能夠使用相應 SQL 查詢到插入的記錄），並輸出軟體的相關使用資訊（如軟體所在機器的 IP 地址、軟體的偵聽埠）。

可見，完成的標準不僅定義了質量要求（通常是一個最低質量要求），也定義了任務所要交付的產出物。完成的標準所定義的產出物和質量要求正是評估任務進度的依據。一個任務在整個團隊中有了一個大家一致認同的完成標準時，任務完成的質量和進度的衡量才不會出現衝突。

進度風險控制

進度管理中很重要的一個方面是進度風險控制。

提高進度資訊的獲取頻率可以儘可能早得發現進度障礙，為消除障礙爭取了最大時間，從而有效減低進度風險。由於敏捷開發中的一個迭代週期持續的時間較之傳統專案要短得多，進度資訊的獲取頻率也要相應有所體現。筆者通常每天對專案進度資訊進行彙總。

任務採用認領的方式而非採用分配的方式落實到人，也有助於規避人力風險導致的進度風險。

比如，在需求評審與分析的時候，筆者並不指定誰負責哪個 Story，而是要求全體成員對本次迭代的所有需求都要有所理解，並能夠講解自己對本次迭代中的任意一個需求的理解。敏捷開發採用迭代的方式，每次迭代所要實現的需求量同傳統專案比較要少得多，這使得每個團隊成員對本次迭代的所有需求都進行理解成為可能。在確認每個團隊成員對本次迭代所要實現的所有需求都有所理解之後，筆者才讓團隊成員對相應需求的開發測試任務進行認領，具體落實到人。採用這種任務認領的方式，使得每個團隊成員對本次迭代的所有需求都有所理解。從而，在人力變更（如原先負責某個需求的開發人員請假了）時，可以快速得找到能夠承接任務的人。進而規避了進度風險。從一開始就將需求落實到相應的開發測試人員，很容易就造成團隊成員只關注自己手頭上的"一畝三分田"，從而使得對於需求的理解沒有備份人力，一旦人力變更則很容易影響專案進度。

筆者在專案組中強調一個個人規避進度風險的原則。該原則要求團隊成員在遇到問題時，通過個人的努力消耗了 30 分鐘而仍然未能將問題解決時，要及時尋求幫助，而不是繼續在問題上打轉，甚至於走進問題的死衚衕。當然，團隊成員在遇到自己無法解決的問題時，可能會覺得不好意思讓被人知道，而專案經理要消除他們的這種顧慮。尤其是一些工作經驗不長的員工，由於個人經驗、能力等方面的限制，在遇到問題時候，往往容易只是一門心思地想著要解決問題，而完全沒有顧及到時間。這往往使得他們對於問題的解決就像是走進了一條死衚衕，心裡明明想要走出去，可是越是往前走，就越是走不出去，而時間卻悄然而逝！

進度資訊的展示、傳播及其激勵作用

Scrum 中提倡的採用燃盡圖（Burn-down Chart）來直觀得展現專案總體進度。它展示了時間和專案剩餘總體工作量間的關係，如圖 1 所示。

圖 1. 燃盡圖

筆者認為，燃盡圖更多得是給人以一種壓迫感－－－讓人清晰直觀得感受到隨著時間的推移，專案所剩的工作量逐天減少！因此，燃盡圖也受到了一定的批判。

而燃起圖（Burn-up Chart）則直觀地展現了時間與已完成的工作間的關係，如圖 2 所示。

圖 2. 燃起圖

傳統專案由於專案週期較長，團隊成員往往在漫長的開發過程中看不到自己的工作成果，慢慢得失去工作的熱情。因此，讓團隊成員看見其工作成果，對其來說也是一種激勵。敏捷開發由於採用迭代的方式，一定程度上能夠讓員工更快得看到自己的勞動成果。而燃起圖則更加有助於展示團隊的工作成果。因為它將團隊成員的工作成果直觀得展現出來。因此，某種程度上燃起圖不僅僅展示了專案進度，也是對團隊成員的一種激勵形式。

狀態牆則直觀得展示了每個任務的進度。許多推行敏捷專案管理的團隊，都採用這種方式來管理進度。如圖 3 所示。

圖 3. 狀態牆

消除浪費

時間是軟體開發過程中最為稀缺並不可替代的資源。其浪費將直接影響專案的進度。而軟體開發過程中存在各種各樣的浪費。因此，消除浪費是加快進度的一種重要途徑。

返工則是軟體開發過程中常見的一種浪費。避免返工不僅有利於加快進度，同時也能夠提升軟體的質量。敏捷開發中的一些優秀實踐，如"定義完成的標準"、"結對程式設計"、"測試驅動開發"（TDD）等都有助於避免返工。

"定義完成的標準"通過定義質量要求和產出物避免返工。"結對程式設計"通過及時的 code review 避免缺陷在後期才被發現而造成返工。"測試驅動開發"則是通過明確需求，避免因需求理解錯誤引入缺陷而造成的返工。

過度設計也是一種常見的浪費。所謂"過度設計"，指在設計階段為未來可能發生的變化做過多的預測，並針對這些預測在設計上做過多預防。正如俗話所說"計劃不如變化快"，過早地為這些可能根本就不會出現的變化做處理成了一種浪費。因此，敏捷開發中提倡的是"簡單設計"（Simple Design）。所謂簡單設計並不是沒有設計，而是採用儘可能簡單的設計方案。事實上，真正能夠以"不變應萬變"的設計方案是不存在的。如果它存在，它必然是一種簡單的方案，因為其簡單，它可以被輕易得推倒重來，這才是適應"萬變"的方法。

迭代速率（Velocity）與期望值管理

迭代速率反映了一個團隊在固定的時間（一個迭代週期）內所能交付的 Story 個數。它反映了團隊的生產能力。前文我們討論的是如何從進度的角度提升這個生產能力――加快以及如何保證迭代進度。另外值得注意的是，有時候我們有必要適當得放慢進度，進而"減低"團隊生產力。所謂"得寸進尺"，這反映了專案管理中很重要的一面――期望值管理。"得寸進尺"式的期望值提升告訴我們當團隊生產能力越大，組織上層和客戶對團隊的期望值也就越大。但是，作為團隊的管理者要適當控制他們的期望值的提升，因為團隊的生產能力應該有它的上限，而期望值的提升取可能遠比團隊的生產力的提升要來得快，但這無論對於組織和客戶還是團隊來說都不是好事。因此，在進度管理中使得控制迭代進度，不要使其讓人感覺過快，也是進度管理中很重要的一方面。

計劃偏差分析與控制

布魯克斯法則 ( Brook's Law ) 告訴我們往一個已經滯後的專案增加人力會使這個專案更加滯後。不幸的是，當一個專案滯後的時候，往往管理層首先想到的是增加人力，因為這樣他們會安心些。值得注意的是，此時增加的人是否反而使專案更加滯後，某種程度上說取決於我們如何使用新增的人力。雖然新增的人力由於對本專案並不熟悉、而本專案原有人力也不可能抽出時間給這些"新人"培訓。但是，我們卻可以以揚長避短的方式去發揮新增人力的作用――把一些不需要專案背景知識的工作交由這些人做，從而使原有的開發人員能夠集中精力做他們最值得做的事情。比如，可以把開發過程需要使用的與專案背景沒有直接聯絡的函式交給"新人"開發。也可以將一些非專案開發相關的而平時大家又不得不做的一些例行任務（即通常所謂"專案干擾"）交由這些人做。

從長期的角度看，對計劃偏差進行分析和控制要求我們做以下幾件事情：

精確記錄任務消耗的實際時間

愛因斯坦曾經幽默地解釋什麼是相對論：坐在美女旁邊一小時就像是一分鐘，坐在火爐旁一分鐘則像一小時。可見，人對時間的感知在缺乏時間衡量的情況下是多麼不可靠。所以，要計算計劃偏差（通常是偏慢了），必須要有精確的實際消耗時間。一些軟體比如 JIRA 可以幫助我們輕鬆得記錄每個任務的實際消耗時間。

量化任務的計劃偏差

度量計劃偏差通常有持續時間偏差和進度偏差，其計算公式如下：

持續時間偏差 (%) =(( 實際持續時間 - 計劃持續時間 )/ 計劃持續時間 )*100［持續時間不包含非工作日］

進度偏差 (%)=(( 實際結束時間 - 計劃結束時間 )/ 計劃持續時間 )*100

持續時間偏差反映了任務實際消耗工作時間與任務計劃持續工作時間的偏移程度，而進度偏差則反映了任務實際結束時間與計劃結束時間的偏移程度。對於專案中的關鍵任務，進度偏差反映了專案總體進度的偏差。

將任務的計劃偏差進行量化可以讓人清晰、準確認識到偏差的程度。通常，筆者會讓導致計劃偏差的人員自己去計算這兩個指標的值，而不是由"專職人員"來計算。因為只有讓問題的引入者自己清晰得地意識到問題，這個問題才能從根本上解決。

對計劃偏差進行根因分析（Root Cause Analysis）

有了計劃偏差度量值後，固然要對這些度量值進行根因分析，以便找到規避和改進的措施。

但是，這些規避和改進措施，通過由專人（比如，專案經理自己）給出然後交由開發、測試人員去執行其效果不見得落實到位，因為這些措施對於其執行者來說，它們都是"別人"的，不是執行者"自己"的東西。

筆者則將根因分析的方法教給團隊成員，然後由團隊成員自行對偏差進行分析，並給出他們自己的規避和改進措施。筆者在組織全體成員對這些分析和改進措施進行討論，然後幫助團隊成員跟蹤和落實這些改進措施。

之後我們附一個English version 模板

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

如有想了解更多軟體研發 , 系統 IT整合 , 企業資訊化，專案管理，企業管理 等資訊，請關注我的微信訂閱號：

作者：Petter Liu
出處：http://www.cnblogs.com/wintersun/
本文版權歸作者和部落格園共有，歡迎轉載，但未經作者同意必須保留此段宣告，且在文章頁面明顯位置給出原文連線，否則保留追究法律責任的權利。
該文章也同時釋出在我的獨立部落格中-Petter Liu Blog。