凡事預則立：談專案開發計劃（轉）

在開發活動中，專案計劃是專案啟動後的頭一件重大事件，但也是經常被忽略的一件事。

專案計劃好比是一份專案的交通圖，指導專案準確的達到目標，即使它沒有被形成規範文件，它至少會在專案經理的腦子裡，只不過比較粗糙和模糊罷了。

　　為什麼每個專案都需要一份專案計劃，並且要形成規範的文件呢？這是因為：

　　第一、透過制定計劃，使得小組和有關管理人員，對專案有關事項，如資源配備、風險化解、人員安排、時間進度、內外介面等形成共識，形成事先約定，避免事後爭吵不清；

　　第二、透過計劃，可以使得一些支援性工作以及並行工作及時得到安排，避免因計劃不周造成各子流程之間的相互牽掣。比如測試工具的研發，人員的培訓都是需要及早計劃和安排的。

　　第二、可以使專案實施人員明確自己的職責，便於自我管理和自我激勵；

　　第三、計劃可以有效的支援管理，作為專案經理、業務經理、QA經理、測試經理們對開發工作跟蹤和檢查的依據；

　　第四、做好事先計劃，就可以使注意力專心於解決問題，而不用再去想下一步做什麼？

　　第五、計劃是專案總結的輸入之一，專案總結其實就是把實際執行情況與專案計劃不斷比較以提煉經驗教訓的過程。透過計劃和總結，專案過程中的經驗和教訓別很好的記錄和昇華，成為“組織財富”。

　　制定專案計劃的過程被稱為專案策劃。在專案策劃時，要儘量讓員工估計自己的工期，使團隊成員積極參與到專案中來，而且由於技術發展如此迅速，往往只有具體模組開發人員對那部分工作最瞭解；但是專案經理也不是完全消極的，他應該積累專案管理資料，推動開發過程能力成熟度的提高，以便可以協同開發人員進行越來越準確的專案估計。計劃常以文字文件和圖形文件結合的形式出現，文字主要記錄專案的約束和限制、風險、資源、介面約定等方面的內容，對於進度和資源分解、職責分解、目標分解最好透過專案管理軟體工具（如普遍應用的Microsoft Project）來進行規劃和管理，不要分散在文件的若干個地方，那樣非常不利於同步修改。專案計劃需要設計成“可檢查”的檔案，這要求任務的劃分要細到具體產品，如果存在有形產品的輸出，要羅列出來。比如測試這一任務，不要簡單分解為測試準備、測試執行，而是分解為測試環境搭建、測試方案編制、測試執行、測試報告編制為好。

　　使用Microsoft Project編制的檔案可以稱為計劃進度表，可以用來規劃專案時間進度，輔助專案跟蹤。計劃進度表的制定步驟是：工作分解和定義（WBS）、任務排序、活動歷史估算、編制。

　　估算是計劃活動的基礎之一，有工作規模估算、工作量估算、成本估算等。估算要求有歷史資料，要求在專案過程中透過不斷的維護專案資料庫積累歷史資料。這些資料既可以分析和總結本專案，又可作為後續專案的歷史資料。

　　在計劃實施過程中需要注意的一點是，不能把計劃“固定化”。“計劃趕不上變化”，但“要跟上變化”。實際運作中，要對計劃進行週期性維護。開發計劃會受到很多影響，比如相關計劃（質量保證計劃、採購計劃、測試計劃、驗收計劃等）的影響，實際進度變動的影響、資源變動的影響、專案目標變動的影響、還有隨著需求的逐漸明確引起的專案計劃細化，如果在這些變化發生後，沒有及時維護開發計劃，開發計劃於實際的偏離會越來越大，最後變得沒有價值，人們就會不再閱讀它。所以實際工作中要有具體的責任人和一套指導書來對計劃實施指導和維護。計劃變更時，要保　　留舊的版本，在總結階段需要閱讀舊版本的資訊以對專案過程的變更歷史作評價。總之：變化的計劃才有生命力！

　　實際工作執行專案計劃常常遇到各種困難。有的組織文化中有種觀念認為計劃是一種約束，反正大家努力往前趕就對了，沒必要自己捆住手腳；另外一種情況是大家沒有按照計劃工作的習慣，計劃雖然做好了，做的時候還是我行我素，管理人員也沒有維護計劃的習慣，專案開始沒多久，計劃就被完全撂了一邊；還有一種情況是資源不能保障，比如，裝置不能到位，人員也頻繁被抽調從事計劃外活動，每天改計劃都來不及，只好放棄計劃，這種情況常見於一些規模較小的還在“求生存階段”的公司。

　　事實上，不僅是在專案計劃這一問題上，在其它引入制度化的場合都遇到了類似的困惑。據說，美國家庭常會對做家庭清掃這樣的事情列出一張“責任矩陣表”，按表的內容順序進行掃除活動，完成一項作一個記號，這其實就是一種簡單的專案管理，他們在如此自然的運用，對於中國人是不可想象的。但是制度化是商業社會的基石，遲早要滲透到社會生活的每一個縫隙。具體到專案管理中的計劃活動，除了儘量把計劃做的更具可行性以外，努力在組織內傳播和培育制度化的組織文化將是專案經理們的一項長期責任，除此，別無選擇。[@more@]