凡事預則立：談項目開發計劃

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

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

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

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

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

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

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

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

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

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

使用microsoft project編制的文件可以稱為計劃進度表，可以用來規劃項目時間進度，輔助項目跟蹤。計劃進度表的制定步驟是：工作分解和定義（wbs）、任務排序、活動歷史估算、編制。

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

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

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

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