起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識如何用墨菲定律來管理項目風險？
編輯導語：產品經理在管理每一個項目時，都是有很大的風險存在的，那么應該如何規避和化解這些風險呢？本文作者另辟蹊徑，用墨菲定律來進行項目的風險管理。并且結合相關案例，為我們做了細致的分析，希望看完后能夠對你有所幫助。
前一段時間，在總結風險管理的時候發現“風險”這個東西很空，很難總結。
嘗試了用文字去歸納“風險”，發現風險出現的形式、頻率、概率都跟每個項目相關，無法歸納成通用的概念。
又嘗試了用案例去總結分析，發現案例終歸只能是案例，它不會完整地出現第二次，即便第二次出現，形勢和內容也一定會發生或多或少的變化。
后來我明白了，項目中一定有人參與，有人參與的話“人”就是其中最大的風險變量，這讓我的總結歸納陷入了僵局。
直到最近讀書的時候，偶然翻到了《墨菲定律》這本書，看完其中的內容后我豁然開朗。《墨菲定律》不就是對人一生的風險總結結果嗎？為什么我不能嘗試用墨菲定律來研究總結風險管理呢！
仔細琢磨后還真有所突破，下面我們先來總結一部分：
一、只要某個部分可能出問題，那么最后它一定會出錯
在項目開始初期，產品經理或者項目經理們都會梳理整個產品或者項目的總體流程以及關鍵節點，這個時候我們經常會突然靈光一現，發現這邊有個小問題，這個小問題在項目后期可能會產出有一定影響的BUG。
很多時候我們“依據經驗”的覺得：“這點小問題以小張的代碼能力一定不會出錯的”、“老李做架構這么久了不可能連這點小問題都看不到”等等。
但是偏偏他們就會出錯，他們就是看不到！
Tips1：
在進行項目管理時，所有梳理出來的無論大小的問題都要記錄，當做一定會出現的“風險”來跟團隊成員溝通處理，哪怕他們會覺得你啰嗦。
二、出問題的部分一定是最重要且基礎的部分
每個項目執行過程中都會有一些“關鍵路徑”，也就是比較重要的部分——這些部分可能是電商產品的支付能力、OA產品的工作流引擎、IM產品的push通道等等。
它們很重要，但又很普通，普通到我們會認為這就是基礎能力，甚至有時我們都不會注意到它們。
但是沒錯，一旦它們扮演了這種重要的角色，在項目執行過程的尾聲，它們一定會出問題！
記得有一次我在做一個地產項目的電商產品，過程很順利，產品功能策劃、設計、溝通匯報都做的很完美，在研發的伙伴們進行開發時我甚至開始跟客戶暢想功能上線之后每天過萬流水的場景了。
但是在預估的研發完成時間前一天，研發老大給我打來的電話：“客戶微信公眾號的支付目錄沒有申請過，需要走流程申請，順利的話大概會延期兩個星期?！?/p>
我當場崩潰式發表：“支付目錄這么基礎的東西為什么現在才提出來，開發時沒有人注意過嗎？”
最終得到的所有反饋都是“這個能力太基礎了，我們接觸到的所有客戶都具備這個能力，只有你的客戶沒有。”
Tips2：
前期項目梳理的時候，著重關注那些重要且基礎的能力部分，無論是支付能力、服務器、數據庫、工作流、存儲還是其他，只要它重要且基礎，就會出錯！
三、每當感覺一切順利，就更大的問題等著你
我本人是做項目管理的，服務過數十個企業客戶，交付過N多產品和服務，幾乎沒有完完全全按照項目初期制定的項目計劃完整執行下來的項目，并且絕大多數項目都或多或少的遇到了一些問題。
有一次在給某個大型股份制企業做一個百萬級的項目，項目過半，一切都進行得非常順利——流程一切順利、BUG也都在客戶察覺之前修復完畢、上線準備工作準備就緒、運營方案也已經跟對接人討論妥當，都沒有問題。
可是就在甲乙雙方都認為這會是一次完美的項目交付時，一個大大的意外降臨了。
在我開心地準備驗收文檔的某一天，客戶突然給我打電話：“強仔啊，有個壞消息跟你說一下，我們總經理突然給咱們項目指派了一個顧問，小道消息是這個顧問想取代你們做這個項目，而且顧問跟總經理關系很好，你早做準備！”
隨后而來的就是一系列的找茬式審核項目，收尾工作異?？部?。
Tips3：
不要被表象迷惑，每個項目都會出現問題的，甚至完全不出問題才是最大的問題（因為一定會存在隱藏問題）。所以當項目進行的時候，如果你發現過程特別順利，那么一定要從頭檢查，并且跟團隊成員多溝通一下，是不是遺漏了什么。
四、進度報告越長，工作進展越小
在項目推進過程中，很多管理人員會要求團隊成員定期寫日報、周報等來給自己匯報工作。
如果您恰好也是接收日報、周報的人，那么您一定看到過這么兩種報告：
- 一種是只有幾行文字，內容為一些關鍵結果；
- 另一種是一些長篇大論，內容精彩、過程完善，讓你感覺ta處理的實在是太漂亮了。
但仔細研究這兩類報告就會發現：
- 第一種只有關鍵結果的，就真的是解決了很關鍵的問題，項目推進了不少；
- 但長篇大論的，往往沒有解決什么問題，甚至還遺留了一些尾巴。
作為一個剛擺脫寫報告沒幾年的項目經理，每每在查看團隊人員的報告時，我的腦海中都能浮現出來他們的心理斗爭：“我推進了這么多，還要寫匯報，項目經理都看不到嗎？真是的，把結果寫完了就得了！”
“又是摸魚的一天，啥都沒干，怎么應付日報呢？把今天跟那個誰的聊天記錄潤色潤色多寫寫吧，字數多了興許項目經理就不看了。”
Tips4：
有時不要太相信自己的第一感受，認為報告內容越多工作量越大、進展越大，大多數結果都是相反的。
五、開大會常常是省下來幾分鐘，浪費了幾小時
2017年，我們接了一個鄉鎮企業建立的大型地產園區的智慧化項目，當時這個園區的樓還沒蓋完，我們是和這個園區的弱電總包同時進場開工，負責弱電和我們智慧化項目的甲方是同一個人，我們都喜歡叫他老關。
年底，我們智慧化這邊已經上線完畢，事情都做完了，弱電這邊的項目卻出現了很大的延期問題。
作為一個老派管理人員的典型代表，老關異常喜歡召開匯報大會，每周都會聚集弱電相關企業對接人加上我（由于我們跟某些企業要做數據對接，所以我也被迫要參加）一共30+人，在一個大型會議室里逐個匯報工作和難點，老關現場解決問題。
但是問題真的有被解決么？
答案當然是否定的。因為每個供應商出現的問題都有很合理的理由，合理到老關幫不上忙，但老關也急，所以每次供應商大會老關都會開成進度催促大會，占用大家一上午的時間然后散場。
會議的結果是什么呢？
也許老關不知道，每次會議散場之后，各個供應商之間交流得出的結果都是：還需要繼續延期！也就是說，每周的這個進度匯報會完全沒有任何作用。
互聯網公司沒有同樣的問題么，當然有，而且還不少，各位自己體會。
Tips5：
大型會議是個浪費時間的好東西，很多重點問題也許不需要召開全員大會，找到幾個關鍵負責人開一個小型站會，可能5分鐘不到就解決了。
六、客戶最需要的東西你現在一定沒有
剛做項目經理的那兩年，項目進行到驗收階段的時候，我們去跟客戶溝通驗收流程，總是會發現客戶需要各種各樣的驗收材料，比如詳設文檔、數據庫設計原理、產品原型及說明文檔、相關證書等等。
這些材料也許往往都是我已經有了ABC，但客戶那邊一定要ABCD。
實際交付給客戶的需求也同理，往往都是我們上線了ABC功能，客戶一定要ABCDE功能。
Tips6：
在項目交付的任何時期，都要定期與客戶溝通客戶的期望以及需求，不管是功能方面、運營方面、驗收方面還是什么，能想到就要溝通，否則就會出現遺漏性問題。
七、獲得了意外的錢財，一定會帶來相同金額的意外損失
其實這一點跟那句俗話很像，“貪小便宜吃大虧”，而且這里的“錢財”不一定就真的特指真金白銀，有時候給項目進行“鍍金”也是同理。
還是2017年，在年底為了推進一個國企項目的順利驗收，項目組決定將公司新推出的一個產品功能F贈送給客戶，作為回報，客戶將給我們的初次驗收流程開綠燈。
但是意外發生了，在2018年初公司認為F功能比較累贅，且除了贈送的這個客戶沒有其他客戶愿意購買，遂決定砍掉F功能不再更新維護。
2018年年中在推進這個過期客戶進行終驗的時候，客戶表示F功能BUG較多且功能不完善，雖然是贈送的功能但也要保證質量交付，所以我們不得不再次協調了20多個研發工作日來去將這個功能完善，給公司內部造成了一定的損失。
Tips7：
給項目或產品鍍金要慎重，小心貪小便宜吃大虧，接到意外的項目同理。
八、問題無法解決，就當它是一種特色吧
在每個項目上，我們都做不到盡善盡美，讓客戶對所有功能點都滿意的情況不太可能出現。有些問題既然無法解決，不如就去擁抱它，并將它轉化為自己的特色。
2018年在做一個地產公司合同管理的項目時，我們就遇到了這樣的問題.由于我們設計的合同管理相關流程十分復雜，無法最終解決“小白可以上手即用”的問題，客戶對此也提出了質疑。
后來經過內部數次流程梳理得出結論：無法解決。
隨后我們調整了對客戶的應答方向，將原本的“功能十分好用”改為了“我們將提供完善的售后服務”，功能上線后派出專人對客戶進行培訓，并且現場指導一周，將所有人教會。
結果也很不錯，客戶對功能不是特別滿意，但是對我們的售后服務贊不絕口。
Tips8：
沒人能預判出所有風險，沒人能解決完所有的問題，但遇到了就要去面對它，說不定有可能將風險轉化為商機呢。
風險管理相關絕不止于這么一點點，墨菲定律在項目管理的應用場景也絕不止于軟件交付項目，感覺展開的話內容可以寫完一本10萬字的書，今天就先到這，各位同僚共勉。
本文由 @李強~ 原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基于CC0協議
牛逼！