三、計劃階段

　　1.定義結構分工結構圖（WBS）

　　啟動階段結束後，項目進入計劃階段，也就正式進入實施。這裡概念可能有些不太對頭，其實是翻譯的緣故，反正大家明白意思就行，不用拘泥於字面。WBS是一組要提交的項目元素，用來組織定義項目的總體范圍，具體包括從工作內容，資源，成本角度考慮項目范圍；建立一套系統所需要的分層工作結構；把項目分解成易於管理的幾個細目，這概念有些模糊，其實跟資源管理器裡分目錄是一回事情。可以說，WBS是計劃階段的核心。WBS會詳細的分到遞交件，包括給自己人用的項目使用的過程文件，給客戶用的模塊和說明文檔，完成每個細目的以及如何把這些細目的責任分配到具體的個人。WBS有縮進式和樹狀式，我這裡也沒辦法畫圖，大家參考一些項目管理的書籍，裡面有詳細介紹。我整個文章只挑我覺得需要注意的地方，如非必要，對技術細節或者工具使用不做詳細介紹。WBS的細目並不需要分解到同一水平，最下面的細目叫做工作包，分包的依據是個人的責任和可信度，也就是說到每個人頭上的任務是否能落實，是否有把握完成；還有就是准備對項目進行控制的程度，程度越深，WBS樹也就越深。由於WBS是實用性的東西，根據個人理解也不一樣，所以一個項目可能會有幾個正確的WBS，看PM的需要和最適合當前團隊狀態的進行選擇。

　　WBS的定義還是很麻煩的。

　　PM要召開團隊進行討論，向成員提供與項目相關的所有詳細，並把WBS樹分解到二層三層。然後要花上一段時間讓成員進行頭腦風暴式（BRAINING STORM）思考，制訂工作產出和相應人員的職責，記錄每一個工作包的完成標准。在頭腦風暴式思考時，會有很激烈的爭論，PM要協調關系，調節氣氛，從自己能考慮到的各個角度旁推側敲，提示成員的思維角度和方向並加以總結。盡管很麻煩，制訂WBS仍然是非常值得的。如同需求分析一樣，WBS准備的越充分，編碼的進度越快。

　　2.風險管理

　　既然是商業行為，那麼項目的風險必然存在，相信閱讀這個帖子的朋友不少人都經歷過或大或小的風險。有些風險很容易解決，有些風險則大大損害利益。不論什麼樣的風險，能避免盡量避免，所以有必要對風險進行管理。由於風險的不可預知性，風險管理難度很大，概念也很難講清楚，只能從一些可行的角度去分析，進行管理。

　　首先要識別風險。這是個難度很高的活。 PM要先召開風險識別會議，這個會議面向公司，高層，跨部門的有經驗的人都將參加。然後審核由項目小組生成的風險清單並與重要成員進行風險溝通，檢查一些重要的風險源如WBS，成本（時間）預估，人員計劃，采購管理等等。最後就要用到PM本身在以前類似項目中得到的經驗教訓。

　　識別之後要進行分析。我們可以進行粗略的量化分析（精確分析是不可能的事情）。有經驗的人可以一起參加討論，把提交出來的風險進行分類。首先按發生的可能性分，一般分成高，中，低三個級別，雖然很勉強，但是好歹也有個量化了；然後按耗去的成本分，也是高，中，低三級。我們可以把這兩種類別的三個級別進行組合，碰到可能性也高，成本也高的風險就定位為不能接受。碰到這種風險只好讓客戶修改需求或者增加風險預留成本，否則一旦虧起來不是虧一點點，有可能賠的很厲害。高和中，中和中的搭配都是屬於高風險，中和低，低和低搭配屬於低，高和低搭配屬於中。

　　針對出現的可能性，需要采取一些手段降低風險。到目前為止也沒有一個定論說有絕對好的方式，只能盡其所能的避免。有幾種方法可以考慮，第一種是將風險納入項目管理計劃並指定負責人，由外部人員定期檢查項目風險，一旦風險發生，執行風險管理計劃；第二種是保險，這種屬於風險轉嫁；第三種方式有點奸，不過最保險，就是把客戶拖下水，讓他們一起參與風險管理，呵呵，到時候就好說話了：） 風險管理作為項目計劃之後，PM需要更新WBS，修改日程計劃和更新風險管理計劃。 風險預留通常是成本的8%。

　　3.預估

　　預估是從量化的角度對項目進行評估，主要包括工作量，任務期限，人力，設備，材料，成本等，要注意預估不是財務策略或報價。預估其實並不是一次性工作，在整個項目過程中，預估始終需要。預估似乎沒什麼特別需要提的地方，每個PM接到項目的時候自然會有預估，在項目發生變更或進入下一階段時也會預估。預估的作用主要還是讓PM作到心中有個底，安排計劃時不至於毫無頭緒。

　　4.進度計劃

　　進度計劃就是一個模塊或功能要寫多長時間，PM安排個日期，設立裡程碑，叫程序員們不能偷懶。進度計劃是從WBS提取過來的。對PM來說，合理的安排進度計劃對項目控制和激勵團隊士氣有著很大的作用。對程序員來說，進度計劃毫無疑問是噩夢。顯示進度計劃一般有先後順序圖，甘特圖和裡程碑圖表。上回邵衛老師講課，推薦的工具是m$的PROJECT，這個工具我還不會用，因為沒時間去摸索。我的頭倒是用的很溜了，近一個月來他就用這個PROJECT畫了一個又一個的裡程碑圖，不停的折磨我和同事的神經。我們一般都是一邊開發一邊做UNIT TEST，效果上來看，因為有強大的時間壓力，效率上比之前確實要提高不少，可是我們也只能結結巴巴的趕完進度。由於TEAM裡人少，我們都是一個人做幾個人的活。我每天早晨六點多出門，經過將近兩小時顛簸，八點多點已經坐在位子上，中午吃15分鐘的飯，干到晚上八點下班，到家吃完飯往往已經11點了。一個多月我從來沒吃過早飯，沒有睡過六個小時以上的懶覺。雖然強大的壓力使我們能在短時間內掌握盡可能多的技能，開發更多的模塊，但是對我們的情緒也是有很大的影響。所以說，項目裡程碑是一把雙刃劍，合理安排才能既促進效率也不至於打擊士氣。團隊成員士氣的逐級衰落會給項目後期的開發帶來難以估計的影響，進度將會大大延緩。關於PM和團隊的問題我們後面會講到，這裡我先祥林嫂一把，然後跳過。裡程碑圖表的特征是任務，成員和時間，任務和成員用文字標志，時間用數字描述並輔助以圖線跨度，象階梯一樣非常形象，一目了然。管理起來非常方便，完了的打個鉤就可以了。