3.項目啟動

　　項目啟動要確定項目計劃，與客戶一起實施第一次項目審核，確認(rèn)并對一些產(chǎn)品和服務(wù)向下包廠商下訂單。這個時候的PM會忽然發(fā)現(xiàn)有開不完的會，一天開三到四個會議是很正常的事情。這些會議有與客戶的會議，與下包廠商的，有團隊的，有公司高層的。團隊的會議主要是建立正式的團隊，提供團隊成員的角色和職責(zé)，提供績效管理方法，向成員提供項目范圍和目標(biāo)。與客戶的一個主要會議將是項目啟動會議。在這個會議上PM會與客戶確立正式的交流渠道，項目綜合描述，讓項目參與人員相互了解，建立以PM為核心的管理制度。還有一些零零碎碎的東西甚至包括辦公場地的大小，電話多少部，所有人的聯(lián)系方式等等都要在會議上確立，并做會議記錄。這都是些非常瑣碎的事情，聽起來婆婆***，卻是非常必要，缺一不可。大概就是所謂三軍未動，糧草先行吧。

　　這時候，作為公司高層，應(yīng)該向全公司發(fā)表申明，正式給PM發(fā)布項目經(jīng)理任命書和項目授權(quán)書。這個動作雖然在別人看來有些形式主義，但是對提高PM本人的士氣和責(zé)任感是有很大助力的。

　　三.計劃階段

　　1.定義結(jié)構(gòu)分工結(jié)構(gòu)圖（WBS）

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

　　WBS的定義還是很麻煩的。

　　PM要召開團隊進行討論，向成員提供與項目相關(guān)的所有詳細(xì)資料，并把WBS樹分解到二層三層。然后要花上一段時間讓成員進行頭腦風(fēng)暴式（BRAINING STORM）思考，制訂工作產(chǎn)出和相應(yīng)人員的職責(zé)，記錄每一個工作包的完成標(biāo)準(zhǔn)。在頭腦風(fēng)暴式思考時，會有很激烈的爭論，PM要協(xié)調(diào)關(guān)系，調(diào)節(jié)氣氛，從自己能考慮到的各個角度旁推側(cè)敲，提示成員的思維角度和方向并加以總結(jié)。盡管很麻煩，制訂WBS仍然是非常值得的。如同需求分析一樣，WBS準(zhǔn)備的越充分，編碼的進度越快。

　　2.風(fēng)險管理

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

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

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

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

　　3.預(yù)估

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

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

　　網(wǎng)絡(luò)邏輯圖是表示任務(wù)和邏輯關(guān)系的示意圖，可以用先后次序表示，也可以用關(guān)鍵路徑表示。其實把各個活動劃分為1，2，3，4等階段，每個階段包括小活動1.1，1.2，2.1，2.2，2.3，2.4，3.1，3.2，3.3，4.1，4.2等，日程計劃也分四種，一般只提到從前向后和從后向前兩種。從前向后的概念就是某項活動必須相同或晚于直接指向這項活動的的所有活動的最早結(jié)束時間的最晚時間。有些繞口，我們打個比方：2階段指向3階段，那么2階段里的4個子階段也都指向3。假設(shè)2.1結(jié)束時間為1月12日，2.2結(jié)束時間為1月22日，2.3結(jié)束時間為1月15日，2.4結(jié)束時間為1月20日，那么，2階段中最晚的結(jié)束時間是2.2的1月22日，所以在3階段中的3個子階段3.1，3.2，3.3的最早開始時間都不能早于1月22日。至于從后向前的例子大家自己去推吧，我就不舉了，剛才幾個123打的我累死了：） 項目經(jīng)常需要調(diào)整進度。在不改變項目范圍的情況下，調(diào)整進度有幾種方法：利用快速跟蹤手段來改變?nèi)蝿?wù)間的關(guān)系；將串行的任務(wù)改成并行；改變工作方法（可能改變WBS）；改變?nèi)掌谙拗疲龟P(guān)鍵路徑上的任務(wù)開始或結(jié)束的更早。

 　　雖然方法多樣化，在我看來只有一條，就是拼命的壓榨程序員的勞動力。如何壓榨，還是個技巧。如前面所分析的，需求分析恨不得多分點時間給它，壓需求是不太可能；測試階段后期接近完工，羅里巴唆的事情一大堆，忙都忙不完，那時候PM一門心思提前/按時完工，好收錢，壓那段時間似乎也不太可能。說來殘酷，最能壓的還是CODING，編碼階段往往是壓縮重點，總之大家埋頭苦干就是了，大項目壓縮的時候程序員吃喝拉撒都在公司是很正常的事情，相信不少人都有很深的體會，這里傷心事情也就不提了。只是我總結(jié)一下，讓未來的PM們有壓榨后來人的依據(jù)，呵呵。測試前期也可以適當(dāng)?shù)膲阂粔?，那時候人剛完工，都比較懶散。國內(nèi)一般企業(yè)規(guī)模都不大，沒有專門的質(zhì)量控制部門，所以質(zhì)量保證和測試往往就是程序員或PM本身。其實質(zhì)量保證和測試人員的人數(shù)和素質(zhì)都應(yīng)該要高于程序員。在日本和CMM實施的公司里，編碼壓縮是很容易實現(xiàn)的事情，因為那些程序員真的是技能熟練的裝配工人，壓起來方便的很。他們這樣培養(yǎng)人的目的或許就是為了壓縮吧？！