我在大廠管項目：風險管理實戰

編輯導語：任何項目都存在或大或小的風險，而項目的成功與風險的控制與預防有很大的關系。本文作者總結了自己在阿里的項目管理經驗，為我們進行了分享，看看風險管理這場實戰如何才能打贏。

互聯網公司的業務成功離不開一個個大大小小的戰役和項目的成功交付，而這些戰役和項目成功交付的一個重要前提就是對風險進行了有效的管理。

對于項目管理者來說，交付項目的過程猶如在大海中掌舵航行，除了規劃好既定的路線，而管理風險就好比是在整個航行過程中，能提前規劃好風險的應對策略和方案，及時發現航路上的暗礁和突如其來的風暴，有條不紊的采取預案措施，提升項目交付的成功率。

一、“項目風險源于任何項目中都存在不確定性”

互聯網項目處在變化越來越快和復雜的環境里，更多的一些則處在高度競爭的紅海中，更有一些跨境的業務場景。

因為法務，合規，國際形勢等多方面的因素，都增加互聯網項目的不確定性和復雜性，用VUCA這個詞（中文發音為“烏卡”- 20世紀90年代起源于美國軍方，是Volatility（易變性）、Uncertainty（不確定性）、Complexity（復雜性）、Ambiguity（模糊性）的縮寫）來形容今天的項目管理者要面臨的局面再貼切不過。

此外項目的一個重要特征就是不確定性，VUCA的內外部環境和一些項目本身的創新要求也不斷加劇了不確定性和風險的產生。

二、什么是風險？

風險：造成項目目標無法達成的可能性及其產生影響大小（可能性 x 影響大小）的事件或條件。

需要注意的是風險來源于不確定性，所以風險其實是一個一體兩面的概念，一面叫威脅，另一面叫機會。所以好的項目經理在面對風險的時候，不僅要能夠轉危為安，更有佼佼者能夠做到轉危為機，把一個風險轉變為對項目交付有利的因素或機會。

三、互聯網項目風險來源

這里提及的項目風險僅僅是列舉出來了一些典型的可能的共性風險來源，不同公司，不同的業務形態，組織陣型和產品技術特點會有不同的風險來源，需要一一識別，并把這些風險來源作為組織的資產輸入到新的項目以幫助提升對風險認知和識別能力。

四、風險應該由誰來識別上報？

在互聯網公司的戰役（項目集）和項目交付過程中，會有兩種較為典型的交付方式，一種是有項目經理進入戰役和項目，直接承接項目管理的相關工作，另一種是由產品或技術同學來兼任項目經理。

但無論是由專職的項目經理來管理項目，還是兼職的項目經理，風險的識別和上報都應該是一種全員行為，而不應該是單個個人。

還是拿航行來做比喻，每個船員在船上各司其職，一旦有人發現了船體本身可能觸礁或者漏水，發現者都應該第一時間，主動進行風險事件的上報。以風險管理為中心，以全員參與為基礎才有可能最大程度的預知風險。

風險由項目所有成員識別。識別到風險事件的項目成員需在識別到風險事件的第一時間，主動進行風險事件的匯報（形式不限）。

構建風險處理的中樞：

• 在實際的項目管理過程中，有項目經理投入的戰役/項目，以項目經理為風險管理的中樞；
• 在無項目經理投入的戰役/項目中，構建風險管理的“鐵三角”：產品、技術、測試負責人，為風險管理的中樞。

五、風險上報應該包含哪些內容？

一個完整的風險上報內容應該包含如下內容：

• 風險編號：ID
• 風險描述：風險的背景，引發風險的原因等
• 風險類型：屬于范圍/成本/質量等方面的風險
• 風險發生的概率：高中低
• 風險影響評估：高/中/低
• 上報人：誰進行的風險上報
• 風險應對措施：采取怎樣的措施來進行風險的應對處理
• 風險應對措施負責人：誰負責解決該風險
• 預期解決時間：預計應對措施實施的完成時間
• 當前進展：進行中，處理中，已關閉
• 備注：其他備注信息

實踐過程中，我們抽象出風險上報的核心要素來簡化為來降低全員理解和上報風險的成本。

風險上報內容包含：

• 風險描述
• 風險發生概率的評估（已發生 / 發生的可能性）
• 風險影響評估（事件發生帶來的結果、對上下游依賴事件的影響、對項目交付影響的初步評估）
• 風險應對措施（可選）

這些上報上來的風險通常會有如下一些問題，比如風險描述不夠準確，評估不夠量化和定性，臨時的處理措施不一定非常恰當。

還有一些屬于局部可能的延期風險，但在局部負責同學的眼中可能就是一個高風險，但并非在項目交付的關鍵路徑上，對項目里程碑等關鍵節點也無影響，也可能會造成對風險的優先級定義不準確，一定程度稱為風險信息噪音；

所以在風險上報上來之后，項目經理和項目鐵三角在風險上報后進行的應對驅動，對于非疑似風險問題進行篩選，同時對于風險事件描述和影響評估的準確度進行評估。并最終根據根據風險發生的概率和對項目整體交付造成的影響對風險定級，并制定對應的應對處理措施。

六、風險定級和定量分析

風險的定級一般通過概率和影響矩陣來判斷和分析，在一個較大的團隊范圍內，為了方便全員對于風險有一個清晰的定級，我們簡化為一個3X3的風險等級矩陣，并且用一些易于理解的概率和影響描述來加深理解，建議在實施的過程中，增加一些實際的案例加深認知。

下面我們來看兩個風險案例：

1. 風險案例一

1）引發風險的原因

• 測試人員總共5個人，主要負責功能A和功能B功能測試；
• 2個測試同學需要在下周一參與臨時高優先級項目保障，影響本項目測試投入15人日；
• 綜合a和b條件，業務功能測試工作量共55人日，根據項目提測時間，只能覆蓋25人日（在加班情況下），但仍存在有30人日測試缺口。

 2）對關鍵時間節點的影響預估（可能對關鍵時間節點的達成造成X天的延期等） 

基于現狀測試資源情況，當前只能確保“功能A”在既定發布時間上線。功能B無法確保在8月20日發布上線，按現有人力重新預估發布時間需延期至9月10日。

這是一個定性和定量詳細分析風險事件的例子，該風險評估為高風險（發生概率非常大，影響程度很大）。

2. 風險案例二

【XXX項目】XXX領域技術人員5月30日之后才能投入，會造成項目延期。這個風險上報非常模糊，不明確的人員投入缺口，模糊的項目影響，以至于看到的時候沒法準確評估該項目的風險等級。

定性和定量分析是一個風險解決的一半，只有定性定量對關鍵里程碑和項目目標的達成影響才會讓項目利益相關方有體感和觸動！制定應對措施才會有的放矢。

七、如何應對風險？

1. 對風險應對措施的持續跟蹤管理

首先要明確的是風險應對措施一旦制定出來，那么對于風險應對措施的結果就要進行持續的跟蹤和回溯。

因為當下制定的風險應對措施不一定是能夠緩解和解決風險問題，這也是風險應對過程當中的不確定性造成的。如果發現當下的應對措施并沒有有效緩解或解決風險的發生，就需要及時思考更多的對策。

2. 建立風險的上升機制

在項目初期，和項目團隊約定風險的上升機制會讓你在風險升級的過程中不腳忙手亂，也能找到對應的更高階的處理人及時介入。

3. 調整應對風險的心態

1）修正免責心態

在一個矩陣或是項目制的組織結構中，很多項目的負責人在風險應對過程中的心態是免責，風險上報，采取了一些不痛不癢的措施就萬事大吉了。風險應對的的目標是緩解或者解決可能產生的風險，一定是在期望解決的時間得到既定的措施實施。

2）英雄主義心態

風險應對從來都不是一個人的是事情，一些同學習慣于自己獨自應對風險或問題，但當這個風險無法解決或者單憑個人無法解決的時候，已經需要投入更多的人力和成本去解決了。英雄主義，單兵作戰都是不可取。

4. 聽取其他項目成員的意見

他山之石可以攻玉，在一個較大的組織內，有很多坑或者是風險是其他團隊已經趟過一遍的了，不管你知道不知道，經驗就在那里，需要把視野打開，去聽取更多外部的建議。

5. 實時的溝通和同步

在項目交付過程中，和相關的干系人保持好及時的溝通和同步，尤其是一些高危風險出現時候，溝通和同步的頻次都需要增加。

一般的原則是：

• 高危風險的處理結果和進展每日進行核心小組同步；
• 中低風險的處理結果和進展每周或項目例會上進行同步；

八、總結

祝愿每個在帶領項目前行的“船長”們都能如約交付，安全抵達。

 

本文由 @拾初 原創發布于人人都是產品經理，未經許可，禁止轉載

題圖來自 Unsplash，基于 CC0 協議