不要成爲項目風險的奴隸

一個項目經理若是一直在項目中處於救火狀態，那他就不是一個好項目經理。我所接觸到的項目經理中，你們最常犯的一個錯誤，就是低估項目難度致使進度不可控制。

由此，我今天想和你們討論的主題，就是項目風險管理了。

項目中不可能沒有風險，正如理財同樣，沒有風險就沒有收益。低風險低收益，高風險高收益。而咱們都知道著名的墨菲定律，既有可能出錯的事就必定會出錯。項目中也同樣，風險若是存在，就表明他必定會發生。

項目經理的主要職責之一，實際就是控制風險，監控風險，把風險扼殺在早期。若是項目風險管理的很差，那項目經理乃至項目團隊就會變成項目風險的奴隸。被風險趕着往前跑，哪裏有窟窿就往哪裏上，被迫放棄正常的開發計劃，致使項目延期。

如下內容，我將會和你們討論一下項目中的風險有哪些，咱們應該如何避免：

項目風險有哪些？

在項目管理領域，有對項目風險很是詳細的劃分，但我我的並未學過PMP相關內容，因此如下風險都是從工做中總結而來。

從我我的的經驗來講，我將項目風險分爲三種：不可抗力風險、外部風險、內部風險。每類風險都整理出一個列表，當作參考。

不可抗力風險一般來講和項目經理無關，也不是項目經理能夠把控和處理的風險。而外部風險和內部風險，都應處於項目經理的監控之下。這兩方面的風險控制好了，項目就得以順利推動。若控制很差，那可能項目中就一直處於救火狀態，甚至搶救不回來致使項目崩盤。

不可抗力風險：

1. 甲方資金鍊斷裂
2. 甲方中途中止項目
3. 投資方撤資

不可抗力風險超出了項目經理和項目團隊的責權範圍，一般不予以考慮。若真趕上這類風險，應報告的是你的上級/老闆，以將自身的損失進行控制。

來自外部的風險：

1. 需求變動頻繁
2. 需求不清晰
3. 需求規劃和評審週期較長，擠壓了開發時間和測試時間
4. 來自外部的接口或數據沒法按預期獲得
5. 來自外部的接口或數據達不到預期要求
6. 與本系統相連的外部系統沒法正確工做，致使不可預知的問題
7. 測試環境強依賴與外部接口或產品，因爲沒法獲得該接口/產品，沒法測試
8. 客戶或者主要干係人對交付產品不滿意
9. 客戶或者主要干係人對頁面樣式/風格不滿意
10. 客戶但願預期一個沒法達到的交付時間
11. 客戶或主要干係人要求的兼容性比預期要複雜
12. 開發設備故障
13. 開發設備性能不足，影響開發
14. 異地協做，沒法當面交流致使的溝通效率下降

來自內部的風險：

1. 干係人不清晰
2. 技術選型沒法知足要求
3. 項目計劃不合理致使的項目混亂
4. 產生了許多不在計劃中的工做
5. 樂觀估算致使工期不足
6. 任務分配不合理，致使的開發人員工做量不均衡
7. 對技術難點評估不足，低估技術難點
8. 遺漏或錯誤的估計兼容性對系統的影響
9. 遺漏或錯誤的估計性能問題對系統的影響
10. 分別設計開發的各子模塊沒法快速集成甚至沒法集成
11. 系統設計質量不高，致使實現困難或花費更多成本
12. 使用不熟悉的技術，致使開發週期延長
13. 未進行有效code review，致使前期應處理避免問題反覆發生
14. 代碼版本管理不到位致使版本混亂或代碼被覆蓋
15. 開發自測不充分既提測，致使測試困難甚至測試工做阻塞
16. 流程過於繁瑣，在流程上浪費了過多時間
17. 流程過於簡單，致使有效溝通不足
18. 項目組成員沒法全身心投入項目（被其餘項目或事務拖住）
19. 項目組成員間溝通方式不明確
20. 項目組內信息傳遞方式不明確
21. 項目組內氣氛緊張甚至衝突，致使項目必要溝通缺失
22. 項目組士氣低下致使進展緩慢
23. 人員變更

如何識別項目風險

相似於上面的項目風險列表是有用的，能夠逐一排查列表，去關注項目中的風險點。但每一個項目的風險點不盡相同，須要對項目的狀態瞭然於胸，才能推敲出項目中可能存在的特定風險。你全部的疑問和質疑，均可能是項目中發送風險的地方。

如何應對以免風險

列表中的風險，我總結爲需求風險、溝通風險、計劃風險、技術設計風險、成員風險等五類。我針對每類風險，提供我本身的解決思路。

需求風險

需求變動無可避免，幾乎每一個項目都必定會涉及到需求變動。緣由不外乎前期溝通雙方理解不一致、干係人忽然冒出新想法等等。

我通常作一下幾點來應對需求風險：

1. 需求階段勤溝通、出原型、籤需求定稿承諾等
2. 需求週期若過長，則溝通要夠開發時間，不然會坑團隊和本身
3. 需求評審階段積極提出本身的疑問和優化意見

溝通風險

溝通風險我認爲是在項目中最多見的問題。項目組內，客戶與項目經理，溝通不及時致使你們信息不對稱。可能形成重複工做，互相等待等狀況。因此一個有效的溝通機制是頗有必要的。

我通常是採起以下方式：

1. 項目組內以討論組的形式進行溝通，全部交流公開透明
2. 職權分明，沒人在項目組中的工做定義清晰，讓同事想找對應負責人的時候容易找到
3. 週會形式，每週週會溝通項目總體狀況並解決問題
4. 檢查進度過程當中，若發現交流問題，督促並協調解決
5. 與客戶方指定主要干係人，僅與主要干係人溝通
6. 須要主要干係人處理的事情，積極主動推動，不被動等待
7. 外部接口和數據工做主動積極的採用郵件方式催促主要干係人進行處理，並告知其影響的工期

計劃風險

計劃風險通常都是由項目經理本身形成的風險。一般因爲對技術難點預估不足，自身經驗不足，對項目考慮不全面等狀況形成。

要解決這個問題，我認爲除了項目經理提高本身別無他法：

1. 提高本身的經驗
2. 經過列表形式也好，請教也好，將可能發生的狀況考慮全面
3. 制定計劃階段輔助於甘特圖等工具，合理安排開發任務
4. 若是有可能，將本身的項目計劃與上級和平級進行討論

技術設計風險

技術設計風險通常由架構成員形成，若是相似於我這樣項目經理同時兼任技術經理。那此部分風險形成的緣由，也是咱們本身的問題。

1. 負責技術設計的人必定要確保全面瞭解需求
2. 負責技術設計的人要考慮用戶數量、數據量、兼容性等問題
3. 技術選型過程當中，項目組要能兜住底。不要出現框架、中間件出了問題本身摟不回來的狀況
4. 開發早期必定要頻繁進行 code review，最好是天天。早期天天一小時的代碼review，剩下的多是後期10天的時間
5. 採用版本管理工具 SVN 或者 Git 進行版本管理。不能提交的文件須要反覆和開發成員強調
6. 項目中的技術難點須要仔細推敲，多方考證，確保能夠完成，並提早預備解決方案

成員風險

項目經理的一個主要職責還要多關注團隊狀況，在團隊士氣低落時，給予激勵。在團隊浮躁時，給予批評和壓力。團隊內起矛盾時，積極調和。發現項目中的不穩定因素時，要提早預備解決辦法。好比調離問題成員；成員離職時，補充人員或任務轉移等。

總結

項目風險是必定會存在的，但咱們要儘量的發現和應對項目風險。把項目風險扼殺於襁褓之中。

正如魏文王見扁鵲同樣。

魏文王召見扁鵲，問他說你家的三個弟兄我據說都學醫，那麼誰的醫術最高啊？扁鵲脫口而出：我大哥的醫術最高，我二哥其次，我最差。
魏文王就很驚訝，問：那你爲何名動天下，他們兩人一點名氣沒有？
扁鵲說：我大哥的醫術之高，他一我的能夠作到防範於未然。這我的病未起之時，他一望氣色便知，而後用藥把你調理好了，因此天下人都覺得他不會治病，他一點名氣都沒有。也就是咱們今天所謂的健康保健。
我二哥的能耐是能治病初起之時。一我的之後他要釀成大病，咳嗽感冒的時候，他用藥將他治好了。因此我二哥的名氣僅止於鄉里，認爲是治小病的醫生。
我呢？就由於醫術最差，因此必定要等到這我的病入膏肓、奄奄一息，而後下虎狼之藥、起死回生。好了，全世界覺得我是神醫。

但願各位都能把風險扼殺在早期，項目推動過程當中一切順利。以上全部內容，我也有許多知道但沒作好的地方，共同努力。

參考書目

《網易一千零一晚上》