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