這次專案的安排看起來幾乎完美無缺，專案分配到的工程師是公司裡的精英工程師團，時程估算也納入了合理的緩衝，在最後風險評估環節時，一位相對比較資淺的工程師怯生生地提出了疑慮：「那個…就是我們這次功能上要使用的視覺化圖表，我看了一下是採用一套比較冷門的 Open Source，我看它的 GitHub 最後一次更新是兩年前，而且好像都只有一個人在維護，就是我有點擔心……」

你感覺到世界忽然安靜了兩秒。

接著，團隊的技術主管笑著擺了擺手：「喔安啦，我們已經都用了這麼久了也沒什麼問題，不會那麼衰啦，真的不行的話我們在自己處理就好了。」

另一位資深的工程師也跟著附和道：「對啊，我們先專注在開發上，不要自己嚇自己。等 App 做出來了，再來考慮備用方案也不遲。」

你看著大家一臉言之有理的神情，雖然心中的確響起微弱的風險警報聲，但在兩個經驗老道的工程師這樣一說完，你心想：「他們說的也對，應該沒什麼問題，先把眼前的事做好再說。」

於是，整個團隊就像鐵達尼號上的乘客一樣，在甲板上開著盛大的派對，渾然不覺在遠方的海平面上，一座巨大的冰山正在靜靜地等著大家。

症狀診斷

如果有類似的狀況，小心你可能是一名「常態偏誤樂觀症候群」的患者。

病根在於我們的大腦天生就存在認知偏誤，特別不擅長處理那些罕見但影響深遠的低機率、高衝擊事件。

這算是人類思維的固有缺陷吧，我們習慣性地從過去經驗推斷未來，傾向於認為歷史會以相似的模式重複。所以當我們經歷了長時間的順利無阻時，我們會下意識地形成了一種錯誤的安全感：既然過去這麼長時間都沒有發生過意外或失敗，未來應該也不會發生。

這種心態導致我們很容易把表面上的「風平浪靜」當作永恆不變的「萬無一失」，而忽視了那些潛藏在水面之下、隨時可能浮現的危險冰山。

所以這時你的工作並不是每天在那邊祈禱不要撞上冰山（其實也可以啦，畢竟運氣也是實力的一種對吧 😆 ），你反而要當一個唱衰者，假設你「一定、高機率、99.9%」會撞上冰山，然後先確認好萬一沉船時，該怎麼安排逃難與救難。

處方籤

第一步：偵測風險訊號

首先，你要學會如何從日常的對話與文件中，識別出潛在的風險訊號，我們必須在日常中讓耳朵永遠是張開的！

以下是建議可以加入在你偷聽、觀察的過程中，要特別關注的風險訊號關鍵字詞：

• 單點故障： 專案是否高度依賴「單一」的人、供應商、或技術？當整個系統或流程只靠一個關鍵環節運作時，這個環節一旦出問題，整個專案就會崩潰。
• 缺乏經驗： 團隊是否正在使用他們從未接觸過的新技術或新流程？當團隊成員面對全新領域時，往往會低估學習曲線的陡峭程度，以及可能遇到的技術障礙。這種情況下，時程規劃往往過於樂觀。
• 資源競爭： 專案是否與其他專案競爭相同的關鍵資源？當多個高優先級專案依賴相同的人員或基礎設施時，資源分配衝突可能導致所有專案都延遲。
• 技術債務： 是否為了趕進度而採取了技術捷徑或暫時性解決方案？這些捷徑雖然短期內能加速進度，但長期來看可能成為系統穩定性和可維護性的隱患。
• 外部依賴： 專案的成功，是否取決於另一個我們無法直接控制或影響的團隊、廠商或系統的進度？外部依賴越多，專案的不確定性就越高，特別是當這些外部單位有自己的優先順序和時程表時。
• 模糊不清： 需求、規格或成功指標，是否存在模糊地帶或多重解釋的空間？當專案目標不夠具體或各方對成功的定義不一致時，即使技術實現完美，最終產品也可能無法滿足利害關係人的真正期望。
• 團隊的直覺： 是否有團隊成員（特別是資淺的）在會議上，表達過一絲絲的「不確定」或「擔憂」？這些微弱的信號往往是重大問題的早期警示。資淺成員雖然缺乏經驗，但往往因為沒有既定思維框架去綑綁，所以反而能察覺到團隊資深成員所忽略的盲點。

第二步：風險分類判別

當我們發現了專案中的可能性風險後，下一步就是判斷它們的嚴重程度和發生機率，才能更合理分配有限的資源來應對，畢竟資源有限，我們必須要把精力優先安排在最重要的事情上。

判斷風險時，通常我會透過以下兩個維度來進行評估：

• 衝擊程度：如果這個風險成真，會對專案造成多大的傷害？
  • 高衝擊：會導致專案重大延遲、成本大幅超支、核心功能無法交付，或是嚴重影響客戶關係
  • 低衝擊：只會造成小規模延遲、輕微成本增加，或是影響非核心功能
• 發生機率：這個風險實際發生的可能性有多大？
  • 高機率：在專案生命週期中很可能發生（50%以上的機率）
  • 低機率：在專案生命週期中不太可能發生（低於50%的機率）

將這兩個維度結合起來，我們就能得到一個2x2的風險矩陣，形成四個風險警戒區：

• 🟢 綠色警戒區 (低衝擊 / 低機率)
• 🔵 藍色警戒區 (低衝擊 / 高機率)
• 🔴 紅色警戒區 (高衝擊 / 高機率)
• 🟡 黃色警戒區 (高衝擊 / 低機率)

第三步：制定行動方案

• 🟢 綠色警戒區 (低衝擊 / 低機率)：
  這些是「就算發生了也無傷大雅」的雜訊。
  • 處方 → 接受並輕輕放下，你不需要為「萬一辦公室停電一小時」這種事，去準備備用發電機。（不過如果你的辦公室裡面有需要 24 小時運作的機器，那麼就不會是在綠色區域，有可能在紅色或是黃色區域唷！）
• 🔵 藍色警戒區 (低衝擊 / 高機率)：
  這些是「很煩人，但不會致命」的日常小病痛。
  • 處方 → 透過優化流程或加強測試來降低發生機率。
• 🔴 紅色警戒區 (高衝擊 / 高機率)：
  如果這種事會發生，那你根本不該啟動這個專案，不然就有如「自殺」行為！
  • 處方 → 現在、馬上進行調整、規避。
• 🟡 黃色警戒區 (高衝擊 / 低機率)：
  它發生的機率很低，但一旦發生，就會讓整艘船沉沒。
  • 處方 → 必須、一定要準備備援方案。

特別門診： 如何判斷風險的衝擊與機率？

有時候我們雖然了解風險評估的框架，但真正困難的是缺少一個衡量標準，來幫助我們比較和定位各種風險。因此，下面是針對衝擊程度和發生機率的評估提供一些實用問題清單，來協助你做出更準確的判斷！

如何判斷風險的衝擊程度？

• 時間影響：這個風險會導致專案延遲多久？
  • 一週以內 → 低衝擊
  • 一個月以上 → 高衝擊
• 成本影響：這個風險會增加多少額外成本？
  • 預算的10%以內 → 低衝擊
  • 預算的30%以上 → 高衝擊
• 範圍影響：這個風險會影響多少產品功能？
  • 次要功能或邊緣案例 → 低衝擊
  • 核心功能或關鍵使用案例 → 高衝擊
• 品質影響：這個風險會如何影響產品品質？
  • 輕微的使用不便 → 低衝擊
  • 嚴重的用戶體驗問題或系統不穩定 → 高衝擊
• 業務影響：這個風險會如何影響業務目標？
  • 輕微延遲實現業務目標 → 低衝擊
  • 無法實現關鍵業務目標或損害客戶關係 → 高衝擊
• 團隊經驗：團隊在處理類似情況上的經驗如何？
  • 團隊有豐富相關經驗 → 低衝擊
  • 團隊缺乏相關經驗 → 高衝擊

如何判斷風險的發生機率？

• 歷史數據：類似風險在過去專案中發生的頻率如何？
  • 從未或極少發生 → 低機率
  • 經常發生 → 高機率
• 技術成熟度：所使用的技術或方法有多成熟？
  • 已被廣泛採用且穩定的技術 → 低機率
  • 新興或實驗性技術 → 高機率
• 控制程度：團隊對風險因素的控制能力如何？
  • 大多數因素在團隊控制範圍內 → 低機率
  • 大多數因素不在團隊控制範圍內 → 高機率
• 複雜性：相關系統或流程有多複雜？
  • 簡單且理解透徹 → 低機率
  • 複雜且包含未知因素 → 高機率

最後補充說明，以上的評估標準並非「標準答案」。

舉例來說，預算超出30%才算高衝擊，你可以根據公司文化和專案的容忍度，將這個門檻調整為 20% 等的不同標準。 所以我們會需要根據自己專案的實際情況，調整這些評估標準，讓這把尺更能夠真實反映你所面對的風險情境。

當我們也建立一套團隊共識的標準後，就能讓每個人都能用相同的尺度來衡量風險，避免因個人經驗或偏好而產生判斷偏差。

臨床演練

好，假設你心中已有一把評估風險的尺度，我現在準備了五個情境，讓我們來練習一下。當你遇到這些狀況時，你會將它們歸類在哪個警戒區呢？

🟢 綠色警戒區 (低衝擊 / 低機率)
🔵 藍色警戒區 (低衝擊 / 高機率)
🔴 紅色警戒區 (高衝擊 / 高機率)
🟡 黃色警戒區 (高衝擊 / 低機率)

• 團隊內 1 位入職約 4 個月的工程師在專案期間可能需要請 1 天事假
• 資料寫入頻率為每小時 1000 筆左右的交易資料庫系統，目前備份頻率為每週一次
• 主要功能依賴的 API 服務在壓力測試中出現超時問題，但僅在超過預期流量 200% 時發生
• 產品最關鍵的付款處理系統使用的是新開發的框架，團隊只有一位工程師熟悉此框架
• 產品依賴的雲服務供應商最近宣布某些服務定價將在半年後調整

參考答案

1. 團隊內 1 位入職約 4 個月的工程師在專案期間可能需要請 1 天事假
   → 我會把它歸類為 🟢 綠色警戒區（低衝擊/低機率）
   • 我的分析脈絡
     • 衝擊程度：僅 1 天的請假，對專案進度影響有限，而且 4 個月的工程師通常不會是負責核心功能的主要人員。
     • 發生機率：雖然請假是可能發生的，但只是 1 天，且只影響一位非資深團隊成員
2. 資料寫入頻率為每小時約 1000 筆左右的交易資料庫系統，目前備份頻率為每週一次
   → 我會把它歸類為 🟡 黃色警戒區（高衝擊/低機率）
   • 我的分析脈絡
     • 衝擊程度：如果一發生資料遺失，就會損失將近一週的交易資料，這個資料庫的寫入量累積一個禮拜來看其實是很大量的筆數，尤其又是「交易資料」，一有遺失一定會嚴重影響業務。
     • 發生機率：資料庫系統故障通常並不常見，但每週只備份一次確實增加了風險窗口
3. 主要功能依賴的 API 服務在壓力測試中出現超時問題，但僅在超過預期流量 200% 時發生
   → 我會把它歸類為 🔵 藍色警戒區（低衝擊/高機率）
   • 我的分析脈絡
     • 衝擊程度：只在極端流量下發生，正常使用情況下不影響核心功能
     • 發生機率：流量突增是常見的，但達到預期流量 200% 的機率相對較低
     • 控制程度：團隊已知問題存在，可以提前做好負載平衡或流量控制的準備
4. 產品最關鍵的付款處理系統使用的是新開發的框架，團隊只有一位工程師熟悉此框架
   → 我會把它歸類為 🔴 紅色警戒區（高衝擊/高機率）
   • 我的分析脈絡
     • 衝擊程度：付款處理是核心功能，任何問題都會直接影響收入和用戶體驗，而且知識集中在單一工程師身上，若問題發生又剛好工程師不在，更會讓問題解決時間大幅延長
     • 發生機率：只要是新開發的框架通常 87% 會存在未知問題，畢竟新框架缺乏大規模驗證，風險自然較高。
5. 產品依賴的雲服務供應商最近宣布某些服務定價將在半年後調整
   → 我會把它歸類為 🔵 藍色警戒區（低衝擊/高機率）
   • 我的分析脈絡
     • 衝擊程度：價格調整已經提前通知，有半年相對充足的時間評估替代方案或調整預算，並且供應商做的是價格調整，不是功能性調整，對於專案的可用性不會影響太多
     • 發生機率：已經官方宣布，確定會發生

從這個小練習，我們就能發現評估風險時真的要從多方面設想，把「可能的影響有多大」和「發生機率有多高」這兩個因素一起考慮。在實際做專案時，這樣分類風險超好用的！可以幫我們優先處理那些最需要盯緊的風險，避免掉入「反正不會那麼衰啦」的鐵達尼號思維陷阱。

然後再次強調，上面的參考答案，真的就只是「參考答案」而已！

風險評估本身就帶有主觀性，每個專案團隊可能會根據自身經驗和專案特性，對同樣的風險有不同的判斷。這正是風險評估的價值所在，可以引發團隊成員間的深度討論，從而發現潛在的盲點。所以也非常歡迎你在下方留言處，分享自己對這五個情境狀況的歸類方式以及你的分析脈絡！

最後的醫囑

當你的專案一帆風順時，請務必保持最大的警惕。

最容易沉沒的並不是在狂風暴雨中行駛的船，因為這個時候的大家一定會提高警覺，最容易有意外發生的時間點，反而是在所有人都認為它永不沉沒的那個平靜夜晚。

你的工作並不能只當一個啦啦隊隊長，必須同時做好備援警戒，你的桌上必須放著兩張圖：一張是通往目的地的「航海圖」，另一張，則是標示了所有已知冰山與暗礁的「災難預防圖」。

這也正是為什麼在這系列的文章中，不時會看到一個名為「B計畫」的段落，因為在專案管理的真實世界裡，事情永遠不會完全照著計畫走（真的按照計劃走的話真的是萬幸 😆），一個專業的 PM 不是依靠計畫 A 的完美無缺，而是在於隨時準備好計畫 B、C、甚至計畫 D 的應變能力 :)

先演習過總比真的燒起來好