【研究報告解密】專案風險總是想不全？或許你缺的不是經驗，而是一份 RBS

對於專案風險，我觀察到大家通常會陷入兩種極端。一種是「過度紀錄」，風險登記表（Risk Register）上寫滿了密密麻麻的項目，填滿了各種優先級、機率係數。但也因為資訊過多且雜亂，反而難以引起管理層的關注。
既然老闆不看，就導致了另一個極端——「徹底放棄」。許多PM心想：反正登記了也爭取不到資源來做預防或應變，乾脆就不寫了。

正是因為這兩種極端都無助於專案成功，我開始尋找是否有更好的方法，能既保留細節，又能讓管理層一目了然。於是我找到了David Hillson於2003年發表的經典報告：《在專案管理中使用風險分解結構》（Using a Risk Breakdown Structure in project management）。

這份報告介紹了什麼是「風險分解結構」（RBS），以及它如何幫助我們更有系統地識別與報告風險。如果你是剛接手專案的新手，或者正苦惱於如何向老闆匯報風險，這篇文章介紹的技巧或許能幫你打開局面。

什麼是風險分解結構

一般來說，專案經理對風險的理解、溝通和分析，大多是透過「風險登記表」（Risk Register）來呈現的。團隊的目光往往聚焦在列表中的單一項目，或是那些被標注為「高優先級」的紅色警戒區。雖然這是專案管理的常見做法，但其缺點也十分明顯——容易讓我們「見樹不見林」。

在這種模式下，團隊難以全面掌握專案面臨的整體局勢，管理層也只能接收到碎片化的風險資訊。因此，我們需要一種更高效、更有結構的策略，來幫助每一位專案參與者從宏觀角度理解潛在問題。

如果您接觸過專案管理，一定聽過「工作分解結構」（WBS）。這是團隊為了產出專案最終交付成果，將工作層層拆解出的具體工作包（Work Packages）。WBS 的層級越往下，工作定義就越具體。我們之所以依賴 WBS，是因為當專案資訊量龐大時，唯有透過「結構化」的處理，才能確保核心資訊被完整產出且正確理解。

風險分解結構（RBS）的設計理念與 WBS 有異曲同工之妙。 它是將專案中原本零散的風險數據，依照「風險來源」進行組織，構建成一個有層級的樹狀結構。這不僅僅是分類，更是為了促進團隊對風險的深度理解、溝通與管理。RBS 與普通列表最大的一個區別在於：它強迫我們關注「風險從哪裡來」，而不是「會發生什麼壞事」。 列表上的「進度延誤」只是症狀，RBS 引導我們去技術層、外部環境層尋找導致延誤的「病根」。這對於後續制定治本的對策至關重要。

正如不同行業的專案會有截然不同的 WBS（例如軟體開發 vs. 建築工程），RBS 也具有高度的行業特異性。雖然 PMI（美國專案管理協會）曾提出通用的 RBS 模型，但由於設計得較為宏觀模糊，直接套用到具體專案時往往顯得難以落地。因此，企業若想發揮 RBS 的價值，必須依據自身的專案屬性，開發並演進屬於自己的 RBS 模型。

接下來，我整理了 David Hillson 在報告中提出的一些 RBS 範例。各位專案管理者可以將這些範例視為起步的「種子」，以此為基礎進行剪裁與客製化，發展出最適合你們團隊的風險分解結構。

RBS的核心價值

讓我們回到現實場景。正如我在前言所提，假設你是一位高階主管，下屬遞給你一份包含數百項風險的清單。雖然理智告訴你應該細讀，但礙於時間有限，這密密麻麻的文字只會讓你產生「決策疲勞」。最後，許多高管會得出一個簡單粗暴的結論：「專案經理既然被聘請來，就該搞定這些事。如果風險發生了，那是他要負責處理的，我不需要盯著這些細節。」雖然我們都知道這種想法不合理，但這卻是許多高管心中真實的潛臺詞。

鏡頭轉到另一邊，作為專案經理的你，召集團隊開會討論風險。面對一張空白的風險登記表，成員們往往面面相覷，腦袋一片空白。即使他們能想到某些問題，也常抱持著「見招拆招」或「我自己扛就好」的心態，認為沒必要大張旗鼓地寫出來。

RBS 的出現，正是為了解決這兩種極端困境。 以下是 David Hillson 報告中提到的幾個 RBS 核心價值，看看它如何改變我們的遊戲規則：

作為提示詞

就像現在流行的生成式 AI 一樣，想要 AI 給出高品質的答案，我們必須提供精準的「提示詞」（Prompts）。RBS 在風險識別中扮演的正是這個角色。面對空白的紙張，團隊很難憑空想像風險；但如果我們拿著 RBS，指著上面一個個具體的分類（如：產品需求、系統功能設計），成員們的思緒就會被「激活」，討論也能更有重心。

更進階的做法是，專案經理可以依據 RBS 的不同分類來組織會議。例如，今天這場會議專門討論「系統設計」，只邀請架構師與資深工程師參加；下一場討論「外部採購」，則邀請法務與採購。這種「分而治之」的策略，遠比把所有人關在房間裡漫無目的地「頭腦風暴」要高效得多。

還有一點值得補充，團隊通常由技術人員組成，大家很容易只盯著「技術風險」聊個不停，而忽略了「溝通風險」或「合約風險」。RBS 強制將所有類別列出來，強迫團隊把目光移向那些他們不熟悉、但不代表不存在的領域。

作為檢查表

不知道身為專案經理的你有沒有這種焦慮：看著填好的風險登記表，心裡卻在問：「我到底有沒有遺漏什麼？」往往那些被我們忽略的盲點，最後卻成了導致專案失敗的致命傷。因此，風險想得越周全，專案執行的底氣就越足。

RBS 提供了一個絕佳的全景地圖。我們可以用它來進行「健康檢查」：看看 RBS 上的每一個分支，是否都有對應的風險被識別出來？如果發現某個來源（例如：人力資源）下面空空如也，或者風險寥寥無幾，這就是一個警訊。它提示團隊需要重新審視該領域，確保這不是「盲點」而是真的安全。

此外，RBS 是一個活的文件。即使有它的幫助，專案中仍可能出現全新的風險源。這時，專案經理應該將這個新發現的來源補充進 RBS 中。這不僅是為了當下的專案，更是為了將這份經驗傳承給未來的專案，避免同一個坑踩兩次。

識別風險熱點

試想一下，當你和團隊腦力激盪出大大小小的風險後，你該如何判斷哪裡才是專案的「重災區」？換句話說，我們要如何運用 80/20 法則，找出那 20% 影響專案成敗的關鍵風險？

如果只盯著一長串的列表看，這就像在大海撈針。但當我們將識別出的風險「掛」回 RBS 樹上時，神奇的事情發生了——我們可以觀察風險的密度與分佈。

假設你發現「高影響」和「高機率」的風險，並通過一些權重的計算得知有很大比重都集中在 RBS 的「需求不明確」這個分支下。這就是一個強烈的訊號：這個專案的根本問題不在技術，而在於需求管理。這時，PM 的策略就不該是一個個去解風險（治標），而是要回頭去解決「需求確認流程」這個系統性問題（治本）。簡單來說，你應該集中精力和時間，盡可能與用戶明確需求，而不是花時間在詳細的系統設計上。

跨專案的橫向對比

RBS 的另一個強大之處在於標準化。只要企業內部的專案都使用同一套 RBS 框架，我們就能橫向對比不同專案的風險體質。

例如，透過 RBS 的數據匯總，我們能直觀地發現：專案 A 的風險主要集中在「需求不確定性」；而專案 B 的需求很明確，風險卻集中在「新技術運用」上。

這種宏觀視野對於高層管理至關重要。通過對比每個專案的風險配置，管理層能更客觀地評估投資決策。這能避免資源被錯誤地投放在那些「領導感興趣但風險極高、回報不明」的專案上，從而實現企業資源的優化配置。例如高層管理覺得需求不確定只要通過調配資深的分析師就能解決，而新技術的運用卻要花費金錢和時間來培訓員工，他就能更加有依據地做決定。

讓報告「說人話」

如開頭所述，高層領導不可能有時間細讀每一項風險。因此，一份經過匯總的風險報告至關重要。我們可以按照 RBS 的不同來源，將風險匯總成具體的數字，甚至製作成圓餅圖或雷達圖。

這種報告方式能讓複雜的風險變得一目了然，不僅能讓領導快速掌握局勢，更能體現你作為專案經理的專業度。只有當報告能直接觸動領導的神經，讓他看懂問題的嚴重性與分佈，你才更有機會爭取到高層的支持與資源，從而真正降低專案風險。

而對於團隊內部，成員也能按 RBS 的分類，針對各自領域（如：開發組、測試組）報告最新的風險動態。這種有目的性的溝通，能避免會議淪為流水帳，讓大家的時間都花在最值得討論的事項上。

RBS 最大的貢獻之一，是統一了組織內的「風險詞彙」。當我們說「這是技術風險」時，所有人都知道我們指的是 Level 1 的技術類，而不是某個供應商的技術問題。這種標準化大幅降低了溝通成本。

經驗教訓的傳承

前面說了這麼多，RBS 最後一個、也是最長遠的價值，就是知識管理。

試想一個新專案即將啟動，作為 PM 的你希望能參考過往專案的風險紀錄。但如果面對的是傳統密密麻麻的登記冊，你大概打開看兩眼就想關掉了——因為內容分散、難以閱讀，且難以判斷與當下專案的關聯性。就這樣，寶貴的歷史經驗被束之高閣，新專案繼續踩舊專案踩過的坑，這是相當可惜的。

若使用 RBS，它就像一個有索引的圖書館。例如，這次專案的團隊對「系統整合」感到擔憂，你可以直接在舊專案的 RBS 中檢索「技術-系統整合」這一分支，快速查看過去發生過什麼風險，以及前人採取了什麼應對措施。這樣，你就能在開工前將這些預防措施納入計劃，真正實現「站在巨人的肩膀上」。

小結

以上就是使用 RBS 的核心價值。我個人認為，它雖然概念簡單，卻是一個能大幅提升風險處理與溝通效率的強力工具。當然，任何工具從「知道」到「做到」，再到真正發揮價值，必然會經歷一段磨合期。接下來，讓我結合親身經歷，聊聊各位在實際落地 RBS 時，可能會面臨的主要挑戰。

運用RBS上的一些挑戰

在閱讀完上述 RBS 的強大價值後，我們很容易產生一種美好的幻想：似乎只要把它引進專案，風險管理就能一勞永逸，高層也能瞬間看懂問題所在。

但幻想總是豐滿的，現實卻往往是骨感的。要讓 RBS 真正發揮 David Hillson 報告中所述的價值，需要專案經理不斷地實踐、試錯與調整。作為過來人，我在初次運用 RBS 時也曾跌跌撞撞。為了讓各位讀者少走彎路，接下來我想分享幾個我親身踩過的「坑」，以及如何避開它們。

尋找「完美 RBS」的陷阱

就像 WBS 沒有標準答案一樣，RBS 也沒有所謂的「最優架構」。如果你在 Google 搜尋「軟體開發專案 RBS」，螢幕上會跳出十幾種截然不同的版本，這往往是選擇困難症的開始。

曾經的我就陷入了這個誤區。我花費大量時間比對各種版本的 RBS，試圖找出一個能完美對應我過往所有專案經驗的「終極版本」。結果，我在尋尋覓覓中耗盡了熱情，卻始終覺得每個模板都差了那麼一點點。於是，運用 RBS 的計畫就這樣被無限期延後，「完美」反而成了「完成」的敵人。

我的建議是：先求有，再求好。 任何一個通用的模板都可以是起點，重點是在實戰中根據你專案的特性去剪裁它，而不是在開始前就試圖打造完美的框架。

定義模糊導致的溝通斷層

當我終於痛定思痛，決定隨便抓一個排名第一的 RBS 模板先用起來時，現實又給了我一記重擊——我看著上面的字，卻不懂它具體指什麼。

有一次，我自信滿滿地召集團隊，指著 RBS 上的一個分支說：「大家來討論一下『開發流程』類別下有什麼風險吧！」結果，團隊成員面面相覷，有人面露難色地反問：「PM，你指的『開發流程』具體是什麼？是指我們寫程式不夠規範？還是指敏捷開發的儀式感不足？還是你是覺得我們做事沒系統？」

那一刻我被問倒了，場面一度十分尷尬。我才意識到，RBS 上那些簡短的標題如果沒有具體的定義（RBS Dictionary），對團隊來說只是一堆抽象的名詞。 這種模糊不清不僅無法引導討論，反而容易讓團隊覺得你在質疑他們的工作能力。

從此以後，我學乖了。在開會前，我絕不會只帶著一張冷冰冰的 RBS 去現場。我會預先思考每個來源底下可能包含的具體場景（例如：「開發流程」可能包含「Code Review 執行不徹底」或「需求變更未經評估」）。在會議上，我會先拋出這些具體例子作為引子，打開話匣子，讓大家覺得我們是在「一起解決問題」，而不是我在「挑毛病」。

「這個風險該放在哪？」的分類焦慮

如果你有整理筆記的習慣，一定遇過這種糾結：一條關於「團隊激勵」的筆記，到底該歸類在「管理學」、「領導力」還是「個人成長」？當我們試圖將複雜的現實硬塞進單一的分類盒子裡，這種難題必然會發生。RBS 的運用也是如此。

想像一下，會議中大家正熱烈討論著「系統整合」的問題。有人提出一個擔憂，隨著討論深入，大家發現它既像是「環境風險」，又像是「網路風險」，甚至還帶點「溝通風險」。每位成員言之成理，但風險卡片拿在手上，就是不知道該貼在 RBS 的哪個樹枝上。

面對這種情況，我有兩個實戰建議：

策略 A：選擇「最大影響力」的分類（效率優先）
如果團隊認為只要解決了該風險中最核心的部分，其他連帶問題就會迎刃而解，那麼直接將其歸入「影響力最大」或「最根源」的那個分類即可。別忘了，RBS 的目的是管理風險，不是學術分類，不要為了完美的歸檔而癱瘓了進度。

策略 B：進一步拆解風險（精細度優先）
有時候，分類困難是因為風險定義得太籠統。這時可以試著將它拆解。例如，原本籠統的「系統整合風險」可以拆分為：

• 沒有測試環境可供調試 → 歸入「環境風險」

• 接口資料定義不明確 → 歸入「需求/系統風險」

• 內網開發機無法連線外部接口 → 歸入「網絡風險」

雖然進一步拆解會花費更多時間，甚至產生許多細微的風險項目，但它的好處是能更精準地呈現專案在各個面向的風險暴露情況。至於要選擇哪種策略？這取決於你當下需要的是「快速推進」還是「深度剖析」，由身為專案經理的你來權衡。

其他潛在陷阱

除了上述挑戰，還有兩個常見的心理誤區值得注意：

• 隧道視野： 這是 RBS 的副作用。團隊容易產生「RBS 列什麼我就只看什麼」的思維惰性，導致 RBS 沒列出的潛在風險被集體忽視。因此，請務必保留一個「其他」類別，時刻提醒大家跳出框架。

• 不敢刪減的僵化思維： 很多新手 PM 拿到通用的 RBS 模板後，即使發現某些分支（如「法律風險」）在當前專案完全不適用，也不敢刪除，生怕「刪了就不完整」。結果導致 RBS 上掛著一大堆空白的分支，嚴重影響可讀性。請記住，RBS 是為專案服務的，該剪裁時請大膽剪裁。

小結

不管工具多麼強大，引入一個新方法必然伴隨著學習曲線。RBS 不會在你下載模板的那一刻就自動解決所有問題，它需要專案經理花時間去實踐、去磨合、去調整。

它可能無法在第一天就發揮 100% 的功效，但隨著你對它的理解加深，它將成為你手中最強力的決策雷達。因此，請不要因為初次嘗試的挫折就輕言放棄。慢慢把它內化成你自己的思維模型，這正是從「做專案的人」蛻變為「有價值的 PM」的必經之路。

總結

至此，我們終於完成了對 David Hillson 這份經典報告的解讀與延伸。

回顧這趟旅程，我們從「RBS 是什麼」的基礎概念出發，探討了它如何作為「提示詞」與「檢查表」來激活團隊的風險意識，最後也毫不避諱地剖析了實戰中可能面臨的「分類難題」與「完美主義陷阱」。

但我必須再次強調：工具是死的，人是活的。

RBS 再好，如果只是躺在電腦硬碟裡的一份精美文檔，那它毫無價值。它真正的威力，來自於專案經理在每一次會議、每一次決策中對它的靈活運用與思考。不要期待第一次使用就能完美無缺，也不要因為遇到歸類難題就停滯不前。

現在就是最好的開始時機。 下一次專案啟動會議，不妨試著帶上一份簡單的 RBS，觀察它如何改變團隊討論風險的氛圍。

最後，專案管理的智慧往往來自於「踩坑」的經驗。如果你在運用 RBS 的過程中有其他獨特的發現，或者碰過文中沒提到的「坑」，非常歡迎你在留言區分享補充。讓我們一起把這份「避坑指南」變得更完整，幫助更多走在路上的 PM 們。