不要成為項目風險的奴隸
一個項目經理如果一直在項目中處於救火狀態，那他就不是一個好項目經理。我所接觸到的項目經理中，大家最常犯的一個錯誤，就是低估項目難度導致進度不可控制。
由此，我今天想和大家討論的主題，就是項目風險管理了。
項目中不可能沒有風險，正如理財一樣，沒有風險就沒有收益。低風險低收益，高風險高收益。而我們都知道著名的墨菲定律，既有可能出錯的事就一定會出錯。項目中也一樣，風險如果存在，就代表他一定會發生。
項目經理的主要職責之一，實際就是控制風險，監控風險，把風險扼殺在早期。如果項目風險管理的不好，那項目經理乃至項目團隊就會變成項目風險的奴隸。被風險趕著往前跑，哪裏有窟窿就往哪裏上，被迫放棄正常的開發計劃，導致項目延期。
以下內容，我將會和大家討論一下項目中的風險有哪些，我們應該如何避免：
項目風險有哪些？
在項目管理領域，有對項目風險非常詳細的劃分，但我個人並未學過PMP相關內容，所以以下風險都是從工作中總結而來。
從我個人的經驗來說，我將項目風險分為三種：不可抗力風險、外部風險、內部風險。每類風險都整理出一個列表，當做參考。
不可抗力風險通常來說和項目經理無關，也不是項目經理可以把控和處理的風險。而外部風險和內部風險，都應處於項目經理的監控之下。這兩方面的風險控制好了，項目就得以順利推進。若控制不好，那可能項目中就一直處於救火狀態，甚至搶救不回來導致項目崩盤。
不可抗力風險：
- 甲方資金鏈斷裂
- 甲方中途停止項目
- 投資方撤資
不可抗力風險超出了項目經理和項目團隊的責權範圍，通常不予以考慮。若真遇上這類風險，應報告的是你的上級/老板，以將自身的損失進行控制。
來自外部的風險：
- 需求變更頻繁
- 需求不清晰
- 需求規劃和評審周期較長，擠壓了開發時間和測試時間
- 來自外部的接口或數據無法按預期得到
- 來自外部的接口或數據達不到預期要求
- 與本系統相連的外部系統無法正確工作，導致不可預知的問題
- 測試環境強依賴與外部接口或產品，由於無法得到該接口/產品，無法測試
- 客戶或者主要幹系人對交付產品不滿意
- 客戶或者主要幹系人對頁面樣式/風格不滿意
- 客戶希望預期一個無法達到的交付時間
- 客戶或主要幹系人要求的兼容性比預期要復雜
- 開發設備故障
- 開發設備性能不足，影響開發
- 異地協作，無法當面交流導致的溝通效率降低
來自內部的風險：
- 幹系人不清晰
- 技術選型無法滿足要求
- 項目計劃不合理導致的項目混亂
- 產生了許多不在計劃中的工作
- 樂觀估算導致工期不足
- 任務分配不合理，導致的開發人員工作量不均衡
- 對技術難點評估不足，低估技術難點
- 遺漏或錯誤的估計兼容性對系統的影響
- 遺漏或錯誤的估計性能問題對系統的影響
- 分別設計開發的各子模塊無法快速集成甚至無法集成
- 系統設計質量不高，導致實現困難或花費更多成本
- 使用不熟悉的技術，導致開發周期延長
- 未進行有效code review，導致前期應處理避免問題反復發生
- 代碼版本管理不到位導致版本混亂或代碼被覆蓋
- 開發自測不充分既提測，導致測試困難甚至測試工作阻塞
- 流程過於繁瑣，在流程上浪費了過多時間
- 流程過於簡單，導致有效溝通不足
- 項目組成員無法全身心投入項目（被其他項目或事務拖住）
- 項目組成員間溝通方式不明確
- 項目組內信息傳遞方式不明確
- 項目組內氣氛緊張甚至沖突，導致項目必要溝通缺失
- 項目組士氣低下導致進展緩慢
- 人員變動
如何識別項目風險
類似於上面的項目風險列表是有用的，可以逐一排查列表，去關註項目中的風險點。但每個項目的風險點不盡相同，需要對項目的狀態了然於胸，才能推敲出項目中可能存在的特定風險。你所有的疑問和質疑，都可能是項目中發送風險的地方。
如何應對以避免風險
列表中的風險，我總結為需求風險、溝通風險、計劃風險、技術設計風險、成員風險等五類。我針對每類風險，提供我自己的解決思路。
需求風險
需求變更無可避免，幾乎每個項目都一定會涉及到需求變更。原因不外乎前期溝通雙方理解不一致、幹系人突然冒出新想法等等。
我一般做一下幾點來應對需求風險：
- 需求階段勤溝通、出原型、簽需求定稿承諾等
- 需求周期若過長，則溝通要夠開發時間，否則會坑團隊和自己
- 需求評審階段積極提出自己的疑問和優化意見
溝通風險
溝通風險我認為是在項目中最常見的問題。項目組內，客戶與項目經理，溝通不及時導致大家信息不對稱。可能造成重復工作，互相等待等情況。所以一個有效的溝通機制是很有必要的。
我一般是采取如下方式：
- 項目組內以討論組的形式進行溝通，所有交流公開透明
- 職權分明，沒人在項目組中的工作定義清晰，讓同事想找對應負責人的時候容易找到
- 周會形式，每周周會溝通項目整體情況並解決問題
- 檢查進度過程中，若發現交流問題，督促並協調解決
- 與客戶方指定主要幹系人，僅與主要幹系人溝通
- 需要主要幹系人處理的事情，積極主動推進，不被動等待
- 外部接口和數據工作主動積極的采用郵件方式催促主要幹系人進行處理，並告知其影響的工期
計劃風險
計劃風險一般都是由項目經理自己造成的風險。通常由於對技術難點預估不足，自身經驗不足，對項目考慮不全面等情況造成。
要解決這個問題，我認為除了項目經理提升自己別無他法：
- 提升自己的經驗
- 通過列表形式也好，請教也好，將可能發生的情況考慮全面
- 制定計劃階段輔助於甘特圖等工具，合理安排開發任務
- 如果有可能，將自己的項目計劃與上級和平級進行討論
技術設計風險
技術設計風險一般由架構成員造成，如果類似於我這樣項目經理同時兼任技術經理。那此部分風險造成的原因，也是我們自己的問題。
- 負責技術設計的人一定要確保全面了解需求
- 負責技術設計的人要考慮用戶數量、數據量、兼容性等問題
- 技術選型過程中，項目組要能兜住底。不要出現框架、中間件出了問題自己摟不回來的情況
- 開發早期一定要頻繁進行 code review，最好是每天。早期每天一小時的代碼review，剩下的可能是後期10天的時間
- 采用版本管理工具 SVN 或者 Git 進行版本管理。不能提交的文件需要反復和開發成員強調
- 項目中的技術難點需要仔細推敲，多方考證，確保可以完成，並提前預備解決方案
成員風險
項目經理的一個主要職責還要多關註團隊情況，在團隊士氣低落時，給予激勵。在團隊浮躁時，給予批評和壓力。團隊內起矛盾時，積極調和。發現項目中的不穩定因素時，要提前預備解決辦法。比如調離問題成員；成員離職時，補充人員或任務轉移等。
總結
項目風險是一定會存在的，但我們要盡可能的發現和應對項目風險。把項目風險扼殺於繈褓之中。
正如魏文王見扁鵲一樣。
魏文王召見扁鵲，問他說你家的三個弟兄我聽說都學醫，那麽誰的醫術最高啊？扁鵲脫口而出：我大哥的醫術最高，我二哥其次，我最差。
魏文王就很驚訝，問：那你為什麽名動天下，他們兩人一點名氣沒有？
扁鵲說：我大哥的醫術之高，他一個人可以做到防範於未然。這個人病未起之時，他一望氣色便知，然後用藥把你調理好了，所以天下人都以為他不會治病，他一點名氣都沒有。也就是我們今天所謂的健康保健。
我二哥的能耐是能治病初起之時。一個人以後他要釀成大病，咳嗽感冒的時候，他用藥將他治好了。所以我二哥的名氣僅止於鄉裏，認為是治小病的醫生。
我呢？就因為醫術最差，所以一定要等到這個人病入膏肓、奄奄一息，然後下虎狼之藥、起死回生。好了，全世界以為我是神醫。
希望各位都能把風險扼殺在早期，項目推進過程中一切順利。以上所有內容，我也有許多知道但沒做好的地方，共同努力。
參考書目
《網易一千零一夜》
不要成為項目風險的奴隸