三.計(jì)劃階段

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

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

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

2.風(fēng)險(xiǎn)管理

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

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

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

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

風(fēng)險(xiǎn)管理作為項(xiàng)目計(jì)劃之后，PM需要更新WBS，修改日程計(jì)劃和更新風(fēng)險(xiǎn)管理計(jì)劃。

風(fēng)險(xiǎn)預(yù)留通常是成本的8%。

3.預(yù)估

預(yù)估是從量化的角度對(duì)項(xiàng)目進(jìn)行評(píng)估，主要包括工作量，任務(wù)期限，人力，設(shè)備，材料，成本等，要注意預(yù)估不是財(cái)務(wù)策略或報(bào)價(jià)。

預(yù)估其實(shí)并不是一次性工作，在整個(gè)項(xiàng)目過程中，預(yù)估始終需要。預(yù)估似乎沒什么特別需要提的地方，每個(gè)PM接到項(xiàng)目的時(shí)候自然會(huì)有預(yù)估，在項(xiàng)目發(fā)生變更或進(jìn)入下一階段時(shí)也會(huì)預(yù)估。預(yù)估的作用主要還是讓PM作到心中有個(gè)底，安排計(jì)劃時(shí)不至于毫無頭緒。

4.進(jìn)度計(jì)劃

進(jìn)度計(jì)劃就是一個(gè)模塊或功能要寫多長(zhǎng)時(shí)間，PM安排個(gè)日期，設(shè)立里程碑，叫程序員們不能偷懶。進(jìn)度計(jì)劃是從WBS提取過來的。對(duì)PM來說，合理的安排進(jìn)度計(jì)劃對(duì)項(xiàng)目控制和激勵(lì)團(tuán)隊(duì)士氣有著很大的作用。對(duì)程序員來說，進(jìn)度計(jì)劃毫無疑問是噩夢(mèng)。

顯示進(jìn)度計(jì)劃一般有先后順序圖，甘特圖和里程碑圖表。上回邵衛(wèi)老師講課，推薦的工具是m$的PROJECT，這個(gè)工具我還不會(huì)用，因?yàn)闆]時(shí)間去摸索。我的頭倒是用的很溜了，近一個(gè)月來他就用這個(gè)PROJECT畫了一個(gè)又一個(gè)的里程碑圖，不停的折磨我和同事的神經(jīng)。我們一般都是一邊開發(fā)一邊做UNIT TEST，效果上來看，因?yàn)橛袕?qiáng)大的時(shí)間壓力，效率上比之前確實(shí)要提高不少，可是我們也只能結(jié)結(jié)巴巴的趕完進(jìn)度。由于TEAM里人少，我們都是一個(gè)人做幾個(gè)人的活。我每天早晨六點(diǎn)多出門，經(jīng)過將近兩小時(shí)顛簸，八點(diǎn)多點(diǎn)已經(jīng)坐在位子上，中午吃15分鐘的飯，干到晚上八點(diǎn)下班，到家吃完飯往往已經(jīng)11點(diǎn)了。一個(gè)多月我從來沒吃過早飯，沒有睡過六個(gè)小時(shí)以上的懶覺。雖然強(qiáng)大的壓力使我們能在短時(shí)間內(nèi)掌握盡可能多的技能，開發(fā)更多的模塊，但是對(duì)我們的情緒也是有很大的影響。所以說，項(xiàng)目里程碑是一把雙刃劍，合理安排才能既促進(jìn)效率也不至于打擊士氣。團(tuán)隊(duì)成員士氣的逐級(jí)衰落會(huì)給項(xiàng)目后期的開發(fā)帶來難以估計(jì)的影響，進(jìn)度將會(huì)大大延緩。關(guān)于PM和團(tuán)隊(duì)的問題我們后面會(huì)講到，這里我先祥林嫂一把，然后跳過。

里程碑圖表的特征是任務(wù)，成員和時(shí)間，任務(wù)和成員用文字標(biāo)志，時(shí)間用數(shù)字描述并輔助以圖線跨度，象階梯一樣非常形象，一目了然。管理起來非常方便，完了的打個(gè)鉤就可以了。

網(wǎng)絡(luò)邏輯圖是表示任務(wù)和邏輯關(guān)系的示意圖，可以用先后次序表示，也可以用關(guān)鍵路徑表示。其實(shí)把各個(gè)活動(dòng)劃分為1，2，3，4等階段，每個(gè)階段包括小活動(dòng)1.1，1.2，2.1，2.2，2.3，2.4，3.1，3.2，3.3，4.1，4.2等，日程計(jì)劃也分四種，一般只提到從前向后和從后向前兩種。從前向后的概念就是某項(xiàng)活動(dòng)必須相同或晚于直接指向這項(xiàng)活動(dòng)的的所有活動(dòng)的最早結(jié)束時(shí)間的最晚時(shí)間。有些繞口，我們打個(gè)比方：2階段指向3階段，那么2階段里的4個(gè)子階段也都指向3。假設(shè)2.1結(jié)束時(shí)間為1月12日，2.2結(jié)束時(shí)間為1月22日，2.3結(jié)束時(shí)間為1月15日，2.4結(jié)束時(shí)間為1月20日，那么，2階段中最晚的結(jié)束時(shí)間是2.2的1月22日，所以在3階段中的3個(gè)子階段3.1，3.2，3.3的最早開始時(shí)間都不能早于1月22日。至于從后向前的例子大家自己去推吧，我就不舉了，剛才幾個(gè)123打的我累死了：）

項(xiàng)目經(jīng)常需要調(diào)整進(jìn)度。在不改變項(xiàng)目范圍的情況下，調(diào)整進(jìn)度有幾種方法：利用快速跟蹤手段來改變?nèi)蝿?wù)間的關(guān)系；將串行的任務(wù)改成并行；改變工作方法（可能改變WBS）；改變?nèi)掌谙拗?，使關(guān)鍵路徑上的任務(wù)開始或結(jié)束的更早。雖然方法多樣化，在我看來只有一條，就是拼命的壓榨程序員的勞動(dòng)力。如何壓榨，還是個(gè)技巧。如前面所分析的，需求分析恨不得多分點(diǎn)時(shí)間給它，壓需求是不太可能；測(cè)試階段后期接近完工，羅里巴唆的事情一大堆，忙都忙不完，那時(shí)候PM一門心思提前/按時(shí)完工，好收錢，壓那段時(shí)間似乎也不太可能。說來殘酷，最能壓的還是CODING，編碼階段往往是壓縮重點(diǎn)，總之大家埋頭苦干就是了，大項(xiàng)目壓縮的時(shí)候程序員吃喝拉撒都在公司是很正常的事情，相信不少人都有很深的體會(huì)，這里傷心事情也就不提了。只是我總結(jié)一下，讓未來的PM們有壓榨后來人的依據(jù)，呵呵。測(cè)試前期也可以適當(dāng)?shù)膲阂粔?，那時(shí)候人剛完工，都比較懶散。國內(nèi)一般企業(yè)規(guī)模都不大，沒有專門的質(zhì)量控制部門，所以質(zhì)量保證和測(cè)試往往就是程序員或PM本身。其實(shí)質(zhì)量保證和測(cè)試人員的人數(shù)和素質(zhì)都應(yīng)該要高于程序員。在日本和CMM實(shí)施的公司里，編碼壓縮是很容易實(shí)現(xiàn)的事情，因?yàn)槟切┏绦騿T真的是技能熟練的裝配工人，壓起來方便的很。他們這樣培養(yǎng)人的目的或許就是為了壓縮吧？！

四.控制和執(zhí)行階段

1.軟件開發(fā)

實(shí)在沒什么好說的，也是大家最不愿意談的，平時(shí)在公司里談的已經(jīng)夠多的了，還要在這里受我嘮叨。需要提醒的依然是團(tuán)隊(duì)合作精神和完善的文檔管理制度。SOURCESAFE這些工具有時(shí)候還是有必要使用的。經(jīng)?？吹接腥苏f天才程序員不寫注釋什么的。我相信有這種天才程序員，因?yàn)槲遗龅竭^幾個(gè)。我愛人公司里也有一個(gè)，他們的一套產(chǎn)品核心代碼就是這個(gè)人寫的，4年過去了，周邊代碼換了好幾茬，核心算法始終沒換過，可惜這小子跟了李洪痔，如今已經(jīng)不知所蹤了。但是他的代碼似乎也要有點(diǎn)注釋的，沒有注釋過段時(shí)間再天才的程序員也不能保證他是最有記憶力的。而且，對(duì)一個(gè)項(xiàng)目的編碼來說，靠一兩個(gè)人打天下如今是不可能了。別人的公司都是團(tuán)隊(duì)，兩人智慧勝一人，這頭還在靠一個(gè)天才支撐門面，實(shí)際上市場(chǎng)可就別人搶了去，那時(shí)候再天才也沒用了。編碼的時(shí)候講究技術(shù)公開，程序員不要藏著掖著，對(duì)大家沒好處，PM要想辦法調(diào)動(dòng)大家創(chuàng)新思維的積極性，營造良好的技術(shù)討論氛圍，碰到技術(shù)難關(guān)的時(shí)候就容易攻破了。

有個(gè)問題需要單獨(dú)對(duì)還沒有PM覺悟的程序員說，其實(shí)是在調(diào)研的時(shí)候就定了的，就是使用什么樣的開發(fā)工具。沒有經(jīng)驗(yàn)的程序員往往會(huì)拿著C++或者JAVA的資格證書或者擁有一兩個(gè)開發(fā)工具的一些經(jīng)驗(yàn)而得意洋洋。其實(shí)老板和PM根本不看重這個(gè)，他們關(guān)心的是使用什么樣的工具能盡快的達(dá)到目的。管你什么C++，DELPHI，PB還是JAVA，只要能做的出來，VFP都可以用。我舉這個(gè)例子并非說不看中工具，而是提醒想轉(zhuǎn)型為PM的程序員，第一要把工具當(dāng)作工具，而不要被工具套進(jìn)去，鉆研一些一輩子都用不上的技術(shù)；第二要掌握的并非是單獨(dú)的一個(gè)工具，而是流行的程序設(shè)計(jì)的思想，以及在最短時(shí)間內(nèi)掌握一門陌生工具的能力。只有建立了這樣的思維，才有可能轉(zhuǎn)為PM，否則一輩子都是技術(shù)工人，最多就是個(gè)技術(shù)總監(jiān)。

2.變更

對(duì)任何項(xiàng)目，變更無可避免，無從逃避，只能去積極應(yīng)對(duì)，這個(gè)應(yīng)對(duì)應(yīng)該是從需求分析就開始了。對(duì)一個(gè)需求分析做的很好的項(xiàng)目來說，基準(zhǔn)文件定義的范圍越詳細(xì)清晰，用戶跟PM扯皮的幌子就越少。而需求沒做好，基準(zhǔn)文件里的范圍含糊不清，被客戶抓住空子搞你一下是非常頭疼的事情，往往要付出無謂的犧牲，有時(shí)候甚至非?；鸫蟆?/p>

需求做的好，文檔清晰又有客戶簽字，那么后期客戶提出的變更就超出了合同的范圍，需要另外收費(fèi)。這個(gè)時(shí)候千萬不能手軟，并非要刻意賺取客戶的錢財(cái)，而是不能養(yǎng)成客戶經(jīng)常變更的習(xí)慣，否則后患無窮，維護(hù)的成本會(huì)讓PM吃不消。在客戶提出變更請(qǐng)求時(shí)，要建立變更申請(qǐng)登記表和變更申請(qǐng)表，并讓客戶簽字。當(dāng)然，有時(shí)候一些不是非常關(guān)鍵的模塊PM也不至于一點(diǎn)不講情面，該賣面子的時(shí)候還是要賣，尤其是當(dāng)著對(duì)方領(lǐng)導(dǎo)的面，千萬要賣面子，但是也別賣的太干脆，不要讓他們得到的太容易。

需求做的不好，客戶抓住漏洞或者非常不講道理，麻煩就大了。有時(shí)候爭(zhēng)論會(huì)很厲害，到非常白熱化的地步，PM與客戶代表幾乎溝通不了。PM在客戶關(guān)系和短期利益兩方面難以取舍，一般都是向客戶妥協(xié)，最終形成惡性循環(huán)。這種情況非常難辦。一般這種情況都是到了項(xiàng)目后期，做重大的更改幾乎是不可能的事情，如果白做就要虧錢。而這個(gè)時(shí)候如果PM跟對(duì)方高層的人關(guān)系搞的定，可以透過對(duì)方高層把事情壓住。然而由于已經(jīng)到后期，客戶代表不會(huì)輕易更換，對(duì)方這次沒有改成，必然心懷不滿，下回在別的模塊依然會(huì)找麻煩或者在談二期的時(shí)候動(dòng)動(dòng)手腳，都是很讓PM傷腦筋的事情，這方面目前還沒有什么好的解決方法，所以盡可能的做好需求比什么都重要。相對(duì)需求來說，什么WBS，風(fēng)險(xiǎn)管理，計(jì)劃進(jìn)度都是扯淡，需求做好了，一帆風(fēng)順。還有一種辦法就是裝可憐，要裝的非常的象，在對(duì)方的領(lǐng)導(dǎo)面前裝，而且不能讓人看出是裝的樣子，要讓你自己都覺得你自己是真的可憐，那么就算這次客戶硬是要求改了，下回他也必然不好意思再叫你改。其實(shí)人心都是肉長(zhǎng)的，如果可能的話，我還是不贊同使用一些手段的，但是有時(shí)候客戶非常難以在短時(shí)間打動(dòng)而工期又將接近，這種情況下就要靠PM耍一些手段了。各人有各人的方式，八仙過海，各顯神通吧。

PM在變更管理中需要做的是分析變更請(qǐng)求，評(píng)估變更可能帶來的風(fēng)險(xiǎn)和修改基準(zhǔn)文件。