專案（Explore）總結之專案時間管理

§1.4  專案時間管理

專案時間管理包括按時完成必須進行的各項過程。

§1.4.1                  活動定義

活動定義識別處於WBS最下層（稱為工作組合）的可交付成果。專案工作組合有計劃地分解為粒度更小的計劃活動，為估算、安排進度、執行，以及監控專案工作奠定基礎。該過程的產出是活動清單、活動屬性、里程碑清單和可能的變更。

專案啟動時，由於沒有詳細的需求，無法確定細粒度具體的計劃活動，只制定了大體的里程碑清單，同時以粗粒度的模組開發清單作為活動清單。里程碑的制定主要是以系統架構穩定、X1-X6子系統上線等事件作為主要標誌，在實際操作中，由於粒度過粗，時間跨度過長，在專案過程中出現技術風險、需求風險等因素時由於無法在里程碑時點及早發現和解決，導致子系統的進度亦無從監控；活動清單的制定主要是依據之前的開發經驗，如子系統X1，有M1-M66共66個模組，每個模組的開發則視為一個計劃活動，實際上該計劃活動已經包括了需求分析、系統設計、編碼等一系列的活動。

活動屬性中的資源要求、強制性日期要求、制約因素和假設等在整個開發過程中均沒有深入分析。活動之間的邏輯關係則根據之前的經驗在子系統級作了較為粗線條的確認。

計劃活動規範方面，在每個子系統的開發過程中，以周為週期對下週細粒度的活動進行計劃，採用滾動式的規劃方法。

在此專案中，活動定義和制定進度計劃兩個過程沒有明顯的劃分，因而里程碑清單和活動清單整合在MS Project制定的進度計劃中。

§1.4.2                  活動排序

活動排序是指識別與記載計劃活動之間的邏輯關係。活動排序過程主要的新增產出是專案進度網路圖。

在活動定義章節已提過，活動定義、活動排序和制定進度計劃上沒有明顯的劃分，專案整體活動排序依據的是之前的開發經驗以及專案內部和客戶的評審意見。

對於每一個子系統，開發時制定子系統開發計劃，同樣的，這時候同時完成活動定義和活動排序，使用MS Project制定。

§1.4.3                  活動資源估算

活動資源估算確定在實施專案活動時需要何種資源（人員、裝置、物資等）資源的數量以及何時使用資源。

Explorer沒有對每一活動清單進行資源估算，可以說，沒有對活動資源的規劃，基本上是在每一子系統進入開發時才確定參與具體的參與人員，開發過程中如有變化則根據實際情況追加或釋放資源，缺乏計劃，典型的做到那算那。

§1.4.4                  活動持續時間估算

活動持續時間估算依據計劃活動的工作範圍、資源型別、活動資源要求以及資源日曆等資訊對活動的持續時間進行估算的過程。

在專案中，分兩個層次對活動持續時間進行估算：首先，子系統的持續時間在不考慮資源的情況根據客戶的要求等制約因素作一個大概的估算；其次，對於子系統的每一個系統模組，在列入開發計劃時才予以估算。其中，模組開發的估算拆分為需求調研、需求分析、系統設計、編碼、測試、編碼返工等幾個階段分別估算，目的在於提高估算的準確度以及利於後續的任務安排。估算所採用的方式通常是專家判斷和類別估算，即由系統分析員確定大體的估算時間。執行過程中，由於系統設計文件沒有經過同行評審，往往會出現設計不合理而導致長時間耗費資源在某個計劃活動上的情況，PM對此種情況上的溝通和控制力度不夠。

§1.4.5                  制定進度表

制定進度表過程確定專案活動的開始和結束時間，是一個反覆多次的過程。

如前所述，專案開始時，根據招標檔案中的範圍描述，制定了一份專案的總體進度表，在制定進度表的時候大體進行了活動定義、活動持續時間估算等工作。在子系統計劃階段時，每一子系統均會制定相應的進度表。

制定專案進度表使用的工具是MS Project，沒有作關鍵路徑分析，資源分配上面，根據系統的開發情況，在做詳細周計劃時才確定，基本上每一個子系統的開發團隊是相對固定的。專案進度表制定報批後，就給束之高閣了，出現變更或其他政策調整導致計劃變動時均沒有反映到專案進度表上，整體變更控制和進度控制沒有做好，變更沒有反映到計劃上面。

§1.4.6                  進度控制

進度控制過程判斷專案進度的當前狀態、對造成進度變化的因素施加影響、查明進度是否已經改變以及在實際變化出現時對其管理。

專案沒有使用掙值法對專案進度績效資料進行測量，專案進度的當前狀態判斷基本依賴於專案組系統分析員和TeamLeader的經驗，所以經常在例會上客戶問到目前進度多少，什麼時候能不能完成之類的問題時，只能是拍腦袋去回答，經驗很重要但畢竟是定性分析，偏差很大。對於造成進度變化的因素，引致變化的主要因素包括政策變動引起的需求變更、人員離職等，對於這類因素，特別是因為政策引起的變更，是必須滿足客戶要求的，這種情況下，應從技術上著手，以“可適應需求變更”作為軟體開發的一個需求，不過，在專案中出於趕工的原因，在程式碼一級基本沒有做好控制，所謂重用、適應變化也就無從談起了。

       至於進度基準，自從審批過後，就沒有更新過，在最後專案驗收比原基準整整延遲了七個月以上，還是那句話：整體變更沒有控制好，相關的資訊沒有得到及時的更新。當然，話說回來，按照PMBOK的理論，如果事無鉅細的去執行，一旦出現變更更新相關的文件也是一件費時費力的事情。

-------------------------- 本文可任意轉載，但請註明作者和出處 ----------------------------