專 案 管 理 輕 鬆 學

紀錄專案目標、範疇、專案經理、專案發起人(委製單位)、專案期間、專案預期成本、假設與限制等，大致上就是Project Charter中所記載內容的80%。 

主要工作項目

專案執行過程中，會包含專案管理類工作(主要是PM的工作)、專案支援類工作(包含建構管理、QA、QC、教育訓練、重工等)、需求發展(取得需求列表、獲取內部承諾、外部承諾等)、系統分析與設計(SA、SD相關工作)、撰寫程式等主要工作項目的計畫，這部分可以參考專案的WBS。 

專案里程碑 

專案主要的里程碑，一般來說最少會有兩個里程碑，及啟動會議(Kick-off meeting)與驗收結案，這部分加上專案基本資訊，大致上就是Charter的內容了。 

需求訪談規劃 

紀錄專案中主系統、各模組的需求訪談對象、時程、負責人員、進行方式(面談、問卷等)、訪談要點(要獲得的結果)，這部分的重點在找誰談，以及要獲得什麼結論，通常需求的來源者很多，這份資料應該是要持續被維護的，因為需求提供人員可能會隨著專案的進行逐漸增加。 

變更管理

記錄專案如何進行Change Manangement，針對專案管理需求(變更時程、成本、範疇)、客戶需求、內部需求(讓設計更靈活、更美觀等)我們如何處理這些變更，必須要記載由誰發起，由誰核可等相關程序。 

專案組織與組織圖

記載專案的組織，記載了利害關係人、專案經理、專案成員扮演的角色與主要工作範圍，對PM來說，專案團隊最好是專案型團隊，PM可以管理到所有的人，大家只有一個共同的頭頭，那就是PM；如果是矩陣型的團隊，那Kick-off時的團隊成員承諾就變得異常重要，絕對要成員承諾在專案進行的時候必須要全力配合，否則將形成風險。 

人力資源

從專案組之中做衍生，記錄每個人的稱呼、聯絡方式、因專案所需欠缺的技能以及補強方式，例如今天我缺乏了OOAD的技能，那就必須要註明如何補強OOAD的技能，是由老手帶領、開教育訓練課程還是到外頭上課等。 

人員責任矩陣(ARCI)

記錄專案中每項主要工作的A(Accountable)、R(Response)、C(Consult)、I(Informed)人員名稱，這邊要注意的是R、C、I可能都有多個，但A一般來說只有一個。 

專案監控與品質活動 

記錄如何做專案監控？何時、何人來進行？要監控的項目？例如在第二個里程碑之前，為了讓專案走的更順，可能會定每週一次進度審查，有問題的話就進行矯正；進入專案中期，可能會改成每兩週進行一次；末期在改成每週進行一次，也就是說讓專案的監控更具有規範性，不會漫無章法的亂開會，而品質活動也相同，必須要定義何時、何人來進行品質活動，以確保專案的品質符合一開始定義的範圍。 

驗證與確認(V&V)

註記每一項工作流程(可能會對應到工作產品)的驗證方式、負責人，例如軟體架構設計由系統架構師來進行驗證。 

建構管理 

定義專案各項基準中應該包含哪些內容，例如開發基準可能需要包含系統設計規格、原始碼；產品基準可能包還原始碼、產品文件等，除此之外還要註明建構管理員如何進行建構管理以及建構管理區的R/W權限表。 

資料管理

記載專案開發過程中文件、原始碼、規格等資料的放置位置，作為專案開發時的依歸，也避免大家將資料擺放在不同的位置或者隨意放置，到時候要找尋相關文件時會變得非常麻煩。 

資源需求

包含專案管理、需求管理、議題追蹤、開發管理、原始碼管制、建構管理等相關工作衍生出來的資源需求，包含軟硬體。 

專案工作環境

成員的工作環境，例如使用Windows 2008/SQL Server 2008/Office 2007/VS 2008等，一般來說專案成員必須要使用相同的開發環境才不會出現大家執行出來的結果不相同。 

部署計畫

說明專案部署方式、部署負責人等，例如部署時應該使用特定工具、經由特定步驟來執行，且Production環境應只有部署負責人有權限進行操作，不應交由每個人來進行，會上到Production環境的通常是經過測試環境驗證過的程式，而非部署負責人本機或者開發人員提供的程式。 

風險管理計畫 

定義風險來源、說明風險參數定義(包含影響性、機率與可偵測性，而什麼叫『高』影響性、『低』機率，這些定義應該被記載)、風險回應人員、風險回應計畫與策略、專案風險清單、風險監控方式與頻率等等。 
一份專案計畫應該包含以上內容，而因專案特性不同，每個專案都會再增加或者修改一些內容，以我們手上這個專案來說，大約有28個不同項目要規劃，對專案團隊來說，一份清楚的專案執行計畫非常有助於專案團隊溝通。 
以上提供給大家參考參考。

作者：gipi

Blog：http://www.dotblogs.com.tw/jimmyyu/Default.aspx