2006-08-10 14:09:04
1.定義結構分工結構圖（WBS）
啟動(dòng)階段結束后，項目進(jìn)入計劃階段，也就正式進(jìn)入實(shí)施。這里概念可能有些不太對頭，其實(shí)是翻譯的緣故，反正大家明白意思就行，不用拘泥于字面。WBS是一組要提交的項目元素，用來(lái)組織定義項目的總體范圍，具體包括從工作內容，資源，成本角度考慮項目范圍；建立一套系統所需要的分層工作結構；把項目分解成易于管理的幾個(gè)細目，這概念有些模糊，其實(shí)跟資源管理器里分目錄是一回事情?？梢哉f(shuō)，WBS是計劃階段的核心。
WBS 會(huì )詳細的分到遞交件，包括給自己人用的項目使用的過(guò)程文件，給客戶(hù)用的模塊和說(shuō)明文檔，完成每個(gè)細目的標準以及如何把這些細目的責任分配到具體的個(gè)人。 WBS有縮進(jìn)式和樹(shù)狀式，我這里也沒(méi)辦法畫(huà)圖，大家參考一些項目管理的書(shū)籍，里面有詳細介紹。我整個(gè)文章只挑我覺(jué)得需要注意的地方，如非必要，對技術(shù)細節或者工具使用不做詳細介紹。WBS的細目并不需要分解到同一水平，最下面的細目叫做工作包，分包的依據是個(gè)人的責任和可信度，也就是說(shuō)到每個(gè)人頭上的任務(wù)是否能落實(shí)，是否有把握完成；還有就是準備對項目進(jìn)行控制的程度，程度越深，WBS樹(shù)也就越深。由于WBS是實(shí)用性的東西，根據個(gè)人理解也不一樣，所以一個(gè)項目可能會(huì )有幾個(gè)正確的WBS，看PM的需要和最適合當前團隊狀態(tài)的進(jìn)行選擇。
WBS 的定義還是很麻煩的。PM要召開(kāi)團隊進(jìn)行討論，向成員提供與項目相關(guān)的所有詳細資料，并把WBS樹(shù)分解到二層三層。然后要花上一段時(shí)間讓成員進(jìn)行頭腦風(fēng)暴式（BRAINING STORM）思考，制訂工作產(chǎn)出和相應人員的職責，記錄每一個(gè)工作包的完成標準。在頭腦風(fēng)暴式思考時(shí)，會(huì )有很激烈的爭論，PM要協(xié)調關(guān)系，調節氣氛，從自己能考慮到的各個(gè)角度旁推側敲，提示成員的思維角度和方向并加以總結。盡管很麻煩，制訂WBS仍然是非常值得的。如同需求分析一樣，WBS準備的越充分，編碼的進(jìn)度越快。
2.風(fēng)險管理
既然是商業(yè)行為，那么項目的風(fēng)險必然存在，相信閱讀這個(gè)帖子的朋友不少人都經(jīng)歷過(guò)或大或小的風(fēng)險。有些風(fēng)險很容易解決，有些風(fēng)險則大大損害利益。不論什么樣的風(fēng)險，能避免盡量避免，所以有必要對風(fēng)險進(jìn)行管理。由于風(fēng)險的不可預知性，風(fēng)險管理難度很大，概念也很難講清楚，只能從一些可行的角度去分析，進(jìn)行管理。
首先要識別風(fēng)險。這是個(gè)難度很高的活。PM要先召開(kāi)風(fēng)險識別會(huì )議，這個(gè)會(huì )議面向公司，高層，跨部門(mén)的有經(jīng)驗的人都將參加。然后審核由項目小組生成的風(fēng)險清單并與重要成員進(jìn)行風(fēng)險溝通，檢查一些重要的風(fēng)險源如WBS，成本（時(shí)間）預估，人員計劃，采購管理等等。最后就要用到PM本身在以前類(lèi)似項目中得到的經(jīng)驗教訓。
識別之后要進(jìn)行分析。我們可以進(jìn)行粗略的量化分析（精確分析是不可能的事情）。有經(jīng)驗的人可以一起參加討論，把提交出來(lái)的風(fēng)險進(jìn)行分類(lèi)。首先按發(fā)生的可能性分，一般分成高，中，低三個(gè)級別，雖然很勉強，但是好歹也有個(gè)量化了；然后按耗去的成本分，也是高，中，低三級。我們可以把這兩種類(lèi)別的三個(gè)級別進(jìn)行組合，碰到可能性也高，成本也高的風(fēng)險就定位為不能接受。碰到這種風(fēng)險只好讓客戶(hù)修改需求或者增加風(fēng)險預留成本，否則一旦虧起來(lái)不是虧一點(diǎn)點(diǎn)，有可能賠的很厲害。高和中，中和中的搭配都是屬于高風(fēng)險，中和低，低和低搭配屬于低，高和低搭配屬于中。
針對出現的可能性，需要采取一些手段降低風(fēng)險。到目前為止也沒(méi)有一個(gè)定論說(shuō)有絕對好的方式，只能盡其所能的避免。有幾種方法可以考慮，第一種是將風(fēng)險納入項目管理計劃并指定負責人，由外部人員定期檢查項目風(fēng)險，一旦風(fēng)險發(fā)生，執行風(fēng)險管理計劃；第二種是保險，這種屬于風(fēng)險轉嫁；第三種方式有點(diǎn)奸，不過(guò)最保險，就是把客戶(hù)拖下水，讓他們一起參與風(fēng)險管理，呵呵，到時(shí)候就好說(shuō)話(huà)了：）風(fēng)險管理作為項目計劃之后，PM需要更新WBS，修改日程計劃和更新風(fēng)險管理計劃。 風(fēng)險預留通常是成本的8%。
3.預估
預估是從量化的角度對項目進(jìn)行評估，主要包括工作量，任務(wù)期限，人力，設備，材料，成本等，要注意預估不是財務(wù)策略或報價(jià)。預估其實(shí)并不是一次性工作，在整個(gè)項目過(guò)程中，預估始終需要。預估似乎沒(méi)什么特別需要提的地方，每個(gè)PM接到項目的時(shí)候自然會(huì )有預估，在項目發(fā)生變更或進(jìn)入下一階段時(shí)也會(huì )預估。預估的作用主要還是讓PM作到心中有個(gè)底，安排計劃時(shí)不至于毫無(wú)頭緒。
4. 進(jìn)度計劃進(jìn)度計劃就是一個(gè)模塊或功能要寫(xiě)多長(cháng)時(shí)間，PM安排個(gè)日期，設立里程碑，叫程序員們不能偷懶。進(jìn)度計劃是從WBS提取過(guò)來(lái)的。對PM來(lái)說(shuō)，合理的安排進(jìn)度計劃對項目控制和激勵團隊士氣有著(zhù)很大的作用。對程序員來(lái)說(shuō)，進(jìn)度計劃毫無(wú)疑問(wèn)是噩夢(mèng)。顯示進(jìn)度計劃一般有先后順序圖，甘特圖和里程碑圖表。上回邵衛老師講課，推薦的工具是m$的PROJECT，這個(gè)工具我還不會(huì )用，因為沒(méi)時(shí)間去摸索。我的頭倒是用的很溜了，近一個(gè)月來(lái)他就用這個(gè)PROJECT畫(huà)了一個(gè)又一個(gè)的里程碑圖，不停的折磨我和同事的神經(jīng)。我們一般都是一邊開(kāi)發(fā)一邊做UNIT TEST，效果上來(lái)看，因為有強大的時(shí)間壓力，效率上比之前確實(shí)要提高不少，可是我們也只能結結巴巴的趕完進(jìn)度。由于TEAM里人少，我們都是一個(gè)人做幾個(gè)人的活。我每天早晨六點(diǎn)多出門(mén)，經(jīng)過(guò)將近兩小時(shí)顛簸，八點(diǎn)多點(diǎn)已經(jīng)坐在位子上，中午吃15分鐘的飯，干到晚上八點(diǎn)下班，到家吃完飯往往已經(jīng)11點(diǎn)了。一個(gè)多月我從來(lái)沒(méi)吃過(guò)早飯，沒(méi)有睡過(guò)六個(gè)小時(shí)以上的懶覺(jué)。雖然強大的壓力使我們能在短時(shí)間內掌握盡可能多的技能，開(kāi)發(fā)更多的模塊，但是對我們的情緒也是有很大的影響。所以說(shuō)，項目里程碑是一把雙刃劍，合理安排才能既促進(jìn)效率也不至于打擊士氣。團隊成員士氣的逐級衰落會(huì )給項目后期的開(kāi)發(fā)帶來(lái)難以估計的影響，進(jìn)度將會(huì )大大延緩。關(guān)于PM和團隊的問(wèn)題我們后面會(huì )講到，這里我先祥林嫂一把，然后跳過(guò)。里程碑圖表的特征是任務(wù)，成員和時(shí)間，任務(wù)和成員用文字標志，時(shí)間用數字描述并輔助以圖線(xiàn)跨度，象階梯一樣非常形象，一目了然。管理起來(lái)非常方便，完了的打個(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等，日程計劃也分四種，一般只提到從前向后和從后向前兩種。從前向后的概念就是某項活動(dòng)必須相同或晚于直接指向這項活動(dòng)的的所有活動(dòng)的最早結束時(shí)間的最晚時(shí)間。有些繞口，我們打個(gè)比方：2階段指向3階段，那么2階段里的4個(gè)子階段也都指向3。假設2.1結束時(shí)間為1月12日，2.2結束時(shí)間為1月22日，2.3結束時(shí)間為1月15日，2.4結束時(shí)間為1月20日，那么，2階段中最晚的結束時(shí)間是2.2的1月22日，所以在3階段中的3個(gè)子階段3.1，3.2，3.3的最早開(kāi)始時(shí)間都不能早于1月22日。至于從后向前的例子大家自己去推吧，我就不舉了，剛才幾個(gè)123打的我累死了：）項目經(jīng)常需要調整進(jìn)度。在不改變項目范圍的情況下，調整進(jìn)度有幾種方法：利用快速跟蹤手段來(lái)改變任務(wù)間的關(guān)系；將串行的任務(wù)改成并行；改變工作方法（可能改變WBS）；改變日期限制，使關(guān)鍵路徑上的任務(wù)開(kāi)始或結束的更早。
雖然方法多樣化，在我看來(lái)只有一條，就是拼命的壓榨程序員的勞動(dòng)力。如何壓榨，還是個(gè)技巧。如前面所分析的，需求分析恨不得多分點(diǎn)時(shí)間給它，壓需求是不太可能；測試階段后期接近完工，羅里巴唆的事情一大堆，忙都忙不完，那時(shí)候PM一門(mén)心思提前/按時(shí)完工，好收錢(qián)，壓那段時(shí)間似乎也不太可能。說(shuō)來(lái)殘酷，最能壓的還是CODING，編碼階段往往是壓縮重點(diǎn)，總之大家埋頭苦干就是了，大項目壓縮的時(shí)候程序員吃喝拉撒都在公司是很正常的事情，相信不少人都有很深的體會(huì )，這里傷心事情也就不提了。只是我總結一下，讓未來(lái)的PM們有壓榨后來(lái)人的依據，呵呵。測試前期也可以適當的壓一壓，那時(shí)候人剛完工，都比較懶散。
國內一般企業(yè)規模都不大，沒(méi)有專(zhuān)門(mén)的質(zhì)量控制部門(mén)，所以質(zhì)量保證和測試往往就是程序員或PM本身。其實(shí)質(zhì)量保證和測試人員的人數和素質(zhì)都應該要高于程序員。在日本和CMM實(shí)施的公司里，編碼壓縮是很容易實(shí)現的事情，因為那些程序員真的是技能熟練的裝配工人，壓起來(lái)方便的很。他們這樣培養人的目的或許就是為了壓縮吧！
（網(wǎng)頁(yè)編輯：
秋月）
