【正文】 目的風(fēng)險必然存在，相信閱讀這個帖子的朋友不少人都經(jīng)歷過或大或小的風(fēng)險。 首先要識別風(fēng)險。最后就要用到 PM 本身在以前類似項目中得到的經(jīng)驗教訓(xùn)。首先按發(fā)生的可能性分，一般分成高，中，低三個級別，雖然很勉強，但是好歹也有 個量化了；然后按耗去的成本分，也是高，中，低三級。 針對出現(xiàn)的可能性，需要采取一些手段降低風(fēng)險。 預(yù)估是從量化的角度對項目進行評估，主要包括工作量，任務(wù)期限，人力，設(shè)備，材料，成本等，要注意預(yù)估不是財務(wù)策略或報價。 進度計劃就是一個模塊或功能要寫多長時間， PM 安排個日期，設(shè)立里程碑，叫程序員們不能偷懶。 顯示進度計劃一般有先后順序圖，甘特圖和里程碑圖表。由于 TEAM 里人少，我們都是一個人做幾個人的活。所以說，項目里程碑是一把雙刃劍，合理安排才能既促進效率也不至于打擊士氣。管理起來非常方便，完了的打個鉤就可以了。有些繞口，我們打個比方： 2 階段指向 3 階段，那么 2 階段里的 4 個子階段也都指向 3。 雖然方法多樣化，在我看來只有一條，就是拼命的壓榨程序員的勞動力。只是我總結(jié)一下，讓未來的 PM 們有壓榨后來人的依據(jù)，呵呵。在日本和 CMM 實施的公司里，編碼壓縮是很容易實現(xiàn)的事情，因為那些程序員真的是技能熟練的裝配工人，壓起來方便的很。經(jīng)?？吹接腥苏f天才程序員不寫注釋什么的。而且，對一個項目的編碼來說，靠一兩個人打天下如今是不可能了。沒有經(jīng)驗的程序員往往會拿著 C++或者 JAVA 的資格證書或者擁有一兩個開發(fā)工具的一些經(jīng)驗而得意洋洋。只有建立了這樣的思維，才有可能轉(zhuǎn)為 PM，否則一輩子都是技術(shù)工人，最多就是個技術(shù)總監(jiān)。 需求做的好，文檔清晰又有客戶簽字，那么后期客戶提出的變更就超出了合同的范圍，需要另外收費。 需求做的不好，客戶抓住漏洞或者非常不講道理，麻煩就大了。一般這種情況都是到了項目后期，做重大的更改幾乎是不可能的事情，如果白做就要虧錢。還有一種辦法就是裝可憐，要裝的非常的象，在對方的領(lǐng)導(dǎo)面前裝，而且不能讓人看出是裝的樣子，要讓你自己都覺得你自己是真的可憐，那么就算這次客戶硬是要求改了，下回他也必然不好意思再叫你改。 大公司有質(zhì)量管理部門（ QA）， QA 的成員基本上都是由非常有經(jīng)驗的 PM 轉(zhuǎn)型過來的老狐貍，是老總接班人的有力爭奪者。如果 PM 得了個 D，那可不太妙，不但 世界級的 QA 會每個月要收報告，地區(qū) QA 會一個星期找來面談一次，訓(xùn)一頓。 PM 經(jīng)常通過控制進度和預(yù)估來控制成本。 項目結(jié)束意味著可以收錢了。一個人首次承擔(dān) PM，如果沒有人帶，多半會失敗 。 項目結(jié)束時，依然要開會，不過少多了。也沒什么好廢話的，該表揚就表揚，該發(fā)多少獎金就發(fā)多少獎金，畢竟大家都累死累活的干了那么長時間。 形勢也好，歷史記錄也好，盡管項目結(jié)束的時候客戶滿意度 PM心中已經(jīng)有底了，但是還是有必要向客戶各個層次的項目代表發(fā)一張信息反饋表，收回的 信息將反應(yīng)客戶的滿意度。 。第一就是付錢付的快，如果客戶不滿意，一分錢藏在他牙縫里你也很難摳出來；第二就是二期，二期非常非常重要，因為這里已經(jīng)是屬于一種無銷售成本的項目，又有一期的經(jīng)驗，可以說二期的錢是最好賺的。這樣下一個項目需要他們的時候他們才會為你賣命。這時候開會很輕松，目的也很明確，做完了大家好聚好散，或者以后有機會再合作。在美國，每年至少有 40%的項目無法實施被擱淺。不過收錢未必代表著賺錢，要看項目是否按時完工?？傊?， PM 要管理好成本，注意節(jié) 約，但并非是拼命剝削程序員，該花的還是要花。在沒有 QA 的公司，質(zhì)量控制只能由經(jīng)過授權(quán)的團隊成員進行，效果就要差的多了。 PM 和 QA 有些象貓和老鼠，不停的通過報表傳遞一些心照不宣的假數(shù)字。各人有各人的方式，八仙過海，各顯神通吧。然而由于已經(jīng)到后期，客戶代表不會輕易更換，對方這次沒有改成，必然心懷不滿，下回在別的模塊依然會找麻煩或者在談二期 的時候動動手腳，都是很讓 PM 傷腦筋的事情，這方面目前還沒有什么好的解決方法，所以盡可能的做好需求比什么都重要。 PM 在客戶關(guān)系和短期利益兩方面難以取舍，一般都是向客戶妥協(xié)，最終形成惡性循環(huán)。 在客戶提出變更請求時，要建立變更申請登記表和變更申請表，并讓客戶簽字。對一個需求分析做的很好的項目來說，基準文件定義的范圍越詳細清晰，用戶跟 PM 扯皮的幌子就越少。管你什么 C++， DELPHI， PB 還是 JAVA，只要能做的出來， VFP 都可以用。 編碼的時候講究技術(shù)公開 ，程序員不要藏著掖著，對大家沒好處， PM 要想辦法調(diào)動大家創(chuàng)新思維的積極性，營造良好的技術(shù)討論氛圍，碰到技術(shù)難關(guān)的時候就容易攻破了。 我愛人公司里也有一個，他們的一套產(chǎn)品核心代碼就是這個人寫的， 4 年過去了，周邊代碼換了好幾茬，核心算法始終沒換過，可惜這小子跟了李洪痔，如今已經(jīng)不知所蹤了。需要提醒的依然是團隊合作精神和完善的文檔管理制度。國內(nèi)一般企業(yè)規(guī)模都不大，沒有專 門的質(zhì)量控制部門，所以質(zhì)量保證和測試往往就是程序員或 PM 本身。如前面 所分析的，需求分析恨不得多分點時間給它，壓需求是不太可能；測試階段后期接近完工，羅里巴唆的事情一大堆，忙都忙不完，那時候 PM 一門心思提前 /按時完工，好收錢，壓那段時間似乎也不太可能。至于從后向前的例子大家自己去推吧，我就不舉了，剛才幾個 123 打的我累死了：） 項目經(jīng)常需要調(diào)整進度。其實把各個活動劃分為 1， 2， 3， 4 等階段，每個階段包括小活動， ， ， ， ， ， ， ， ， ， 等，日程計劃也分四種，一般只提到從前向后和從后向前兩種。關(guān)于 PM 和團隊的問題我們后面會講到，這里我先祥林嫂一把，然后跳過。一個多月我從來沒吃過早飯，沒有睡過六個小時以上的懶覺。我的 頭倒是用的很溜了，近一個月來他就用這個 PROJECT 畫了一個又一個的里程碑圖，不停的折磨我和同事的神經(jīng)。對 PM 來說，合理的安排進度計劃對項目控制和激勵團隊士氣有著很大的作用。預(yù)估似乎沒什么特別需要提的地方，每個 PM 接到項目的 時候自然會有預(yù)估，在項目發(fā)生變更或進入下一階段時也會預(yù)估。有幾種方法可以考慮，第一種是將風(fēng)險納入項目管理計劃并指定負責(zé)人，由外部人員定期檢查項目風(fēng) 險，一旦風(fēng)險發(fā)生，執(zhí)行風(fēng)險管理計劃；第二種是保險，這種屬于風(fēng)險轉(zhuǎn)嫁；第三種方式有點奸，不過最保險，就是把客戶拖下水，讓他們一起參與風(fēng)險管理，呵呵，到時候就好說話了：） 風(fēng)險管理作為項目計劃之后， PM