當了一段時間IT專案經理，把一個軟體開發專案的專案管理的實際過程寫一下供大家討論和參考。IT專案管理跟其它工程專案管理最大的一個不同就是人的管理，專案成員不是簡單的機器，人員的知識技能，團隊建設，專案溝通等內容往往是專案管理的一個很關鍵內容。這個方面可以參考《人有神話》，《軟體工藝》，《最後期限》書籍，我的Blog上也有相關的讀書筆記可以參考。

首先我們用思維導圖把計劃階段的相關活動歸納一下再進行具體的分析：

1．專案目標和範圍

開始一個新專案或版本時候，首先是和使用者一起確認需求，進行專案的範圍規劃。專案是範圍，進度，質量和資源四要素的平衡，使用者對專案進度要求和優先順序高的時候，我們往往要縮小專案範圍，對使用者需求進行優先順序排序，排除優先順序低的需求。另外我們做專案範圍規劃的一個重要依據就是我們的歷史經驗資料，對專案特徵的清楚認識，專案範圍規劃初期需求你進行一個較宏觀的估算，否則你很難判斷清楚或給使用者承諾在現有資源情況下，你3個月時間裡面是否可以完成20個或更多使用者功能。

正規過程好像是先確認專案範圍，然後根據WBS->進度計劃確認實際的專案週期，但實際情況往往很難如此，使用者往往對進度的關注度大於對範圍的關注度，一個專案半年或一年都看不到具體的產品出來使用者肯定是無法接受的，所以我們的軟體專案一般也是按版本增量迭代進行開發。

另外這裡需要強調下專案目標的確定，專案的目標不能簡單理解為在某個時間點完成所有功能。專案另外一個重要目標就是專案的質量目標，你完成的這個專案需要達到那個等級的質量標準，交出的產品BUG洩漏率要控制在什麼範圍內等內容。專案的質量目標不會影響到我們的範圍，但會影響到我們後續評審，測試等時間的安排，直接影響到專案的進度。

PMBOK裡已經明確提到專案範圍定義的另一個重要目的就是專案的績效測量和驗收準則，你交付專案的時候使用者會根據使用者需求說明書內容對專案進行驗收，所有我們專案的範圍的定義必須是明確，量化，可驗證和可測試的，這樣才能夠避免後期無謂的糾紛。

另外在概述階段需要分析專案的假設和約束，假設和約束又分為技術方面和非技術方面，在這裡我們分析的所有假設都可能成為專案的風險。

2．專案進度的確定

專案的目標和範圍確定後，需要開始確定專案的過程，專案整個過程中採用何種生命週期模型？專案過程是否需要對組織級定義的標準過程進行裁剪等相關內容。專案過程定義是進行WBS分解前必須確定的一個環節，你採用瀑布模型和增量迭代模型對WBS分解和進度計劃安排顯然是完全不同的。

專案過程確認清楚後開始進行專案的WBS分解，WBS分解一般是專案組的核心成員參加，但專案經理應該是起主導和協調作用。WBS分解方法一般有基於過程和基於成功兩種方式，但兩種方式可以混合使用，比如在高層分解的時候先分解出子系統和工作包，在底層的時候再按照需求，設計，編碼和測試各個過程進行分解。WBS的最底層工作單元需要是可以獨立核實的產品，需要去下達計劃和任務，工作單元需要有明確的責任人，因此有時候在沒有做仔細的估算時候我們很難讓工作單元滿足這些要求，這樣就難免在進行估算過程中還要對WBS進行最佳化和調整。

WBS分解完成後可以開始進行工作單元的估算，估算一般有專家法，三點法和功能點法估算，由於我們的專案採用專家法估算，因此更需要專案核心成員和有經驗的成員參加，估算一般會針對工作單元的單位和複雜度進行估算，最後估算出專案的總規模，再除以專案的生產率後得到專案的工作量資料。專家法估算一般會進行很多輪，直到所有指標都收斂（收斂標準是組織或專案事先確定清楚了，如偏差<30%就算收斂）。對於一個軟體專案而言，我們用專家法估算其實很難估算出具體的各個功能編碼的程式碼行資料和編碼的具體工作量，所以這裡是需要使用專案的歷史經驗資料，即你在做歷史專案的時候需求：設計：編碼工作量的比例究竟是如何的？然後根據估算得到的需求階段工作量資料去推算出設計和開發的估算工作量。所以從這點上也可以看出為何軟體專案度量和分析很重要，因為你做的度量和分析資料都會做為你後續專案的重要依據。很多專案老說軟體估算很不準，原因就在於你沒有你自己專案的歷史經驗資料的積累。

在估算資料出來後，可以使用Project工具安排整個專案的進度計劃，在專案進度計劃安排中的兩個重要內容就是關鍵人力資源的確定和關鍵路徑的確定。在這兩個因素確認清楚後要排出整個專案的進度計劃就很簡單了。對於專案關鍵人力資源確定一般可以採用工作單元－>人員的責任矩陣進行分析，對於關鍵路徑一般直接用運籌學中的關鍵路徑分析法確定ES，EF，LE和LF四個時間即可。

在專案進度計劃基本排出來後就可以規劃和確定專案的里程碑和基線了，專案的里程碑和基線是專案重要的跟蹤控制檢查點，在里程碑專案還會做專門的里程碑報告，對專案的當前狀態，專案的進度，工作量，規模，缺陷等各項指標的偏離進行分析。

整個專案進度計劃基本出來後需要和專案組的所有專案成員確認，獲取專案的內部承諾，專案成員應該對整個進度計劃安排基本達成一致。專案計劃還有需要支援計劃需要制定，專案進度計劃出來後整個可以通知QA和配置管理員分別制定質量保證計劃和配置管理計劃，專案經理協助測試負責人制定專案的系統測試計劃。

3．專案計劃的其它關鍵因素分析和確認

專案的方法，技術，工具和標準
這是專案計劃中需要確定的一個重要內容，即專案過程需要使用哪些方法和技術，採用哪些工具，專案各個階段的輸出應該滿足哪些檢查標準等。一個專案中除了使用到常用的開發工具外，還會使用到需求管理，設計建模，配置管理，變更管理，IM溝通等諸多工具；使用到面對物件分析和設計，開發語言，資料庫，測試等多種技術，在這裡都需要分析和定義清楚，這將成為後續技能評估和培訓的一個重要依據。

干係人分析：
所有對你專案有直接和間接影響的相關人員都是專案的干係人，在這裡我們一般會按專案內部角色和外部角色進行劃分。在對所有的干係人分析清楚後，還應該透過責任矩陣來分析各個干係人說涉及到的專案各階段的相關活動。

專案成員技能和培訓：
其實這是專案計劃的一個重要內容，就是要對專案中的各個成員的技能進行評估，根據專案評估的結果來制定專案的培訓計劃，並對培訓的效果進行跟蹤。在這裡常用的方法和工具有《專案成員培訓需求收集表》，《專案成員技能評估表》，《專案成員技能溝通確認表》，《專案培訓計劃》

專案的關鍵依賴和承諾
專案的內部關鍵依賴和承諾一般會直接體現到專案進度計劃中，但專案的外部依賴和承諾必須有專門的地方進行記錄和定期進行跟蹤。因為當你外部關鍵依賴無法得到滿足時候將直接影響到整個專案的進度，打亂整個專案的步調。

專案風險分析
風險管理是專案管理的一個重要知識領域，也是CMMI評估的一個關鍵過程域。整個專案管理的過程就是不斷的去分析，跟蹤和減輕專案風險的過程。我們在分析專案風險過程中可以藉助風險庫，風險檢查單，專家法，頭腦風暴法等多種手段。一個風險主要包括了風險的機率，後果，影響範圍，處理期限等方面的內容；風險的應對措施主要有減輕，承擔，緩解和轉移等；風險分析一個重要內容就是分析風險的根源，然後根據根源去制定專門的應對措施。風險管理貫穿整個專案管理過程，需要定期的對風險進行跟蹤和重新評估，對於轉變成了問題的風險還需要事先制定相關的應急計劃。[@more@]

IT專案管理-計劃階段（轉）

相關文章