預先驗屍 Pre-Mortem
假設專案已經失敗，回頭找出「到底是怎麼死的」——在開工前就把風險攤開來。
什麼時候該用它？
Pre-Mortem 最適合在你和團隊「已經決定要做，但還沒開始做」的那個時間點。不是用來決定做不做，而是在確定要做之後，系統性地找出「可能怎麼死」。
- 新專案啟動前：團隊士氣高昂、過度樂觀的時候，正是需要冷靜想想風險的時候
- 重大產品決策前：要投入大量資源之前，先模擬失敗場景
- Sprint Planning 時：這個 Sprint 目標有什麼可能搞砸的？
- 跨部門協作開始前：不同團隊對「成功」的定義不一樣，先把各自擔心的地方攤開
- 老闆很興奮但你覺得有坑的時候：用結構化的方式提出疑慮，比直接說「我覺得不行」有效得多
跟一般風險評估有什麼不同？
傳統風險評估問的是「可能會出什麼問題」，但人的心理防衛機制會讓你傾向說「應該不會吧」。Pre-Mortem 的關鍵翻轉是：假設失敗已經發生，問的是「它是怎麼失敗的」。這個心理轉換讓團隊成員從「防禦者」變成「偵探」，更願意說出真正的擔憂。
框架結構
Pre-Mortem 的核心來自認知心理學的「預見性後見之明」(Prospective Hindsight)——研究證明，當你假設結果已經發生時，你找出原因的能力會提升 30%。
五步執行法
Step 1：設定場景 (2 分鐘)
主持人宣布：
「想像現在是六個月後。我們的專案徹底失敗了。不是小失敗，是那種會被拿來當反面教材的失敗。」
關鍵：用具體、戲劇化的描述讓團隊進入情境。別說「可能會有風險」，要說「已經失敗了」。
Step 2：個人靜默書寫 (5-8 分鐘)
每個人獨立寫下：「這個專案是怎麼失敗的？」
- 每人至少寫 3 個原因
- 不需要合理，直覺也行
- 匿名更好（用便利貼或線上工具）
為什麼要靜默？避免群體思考 (Groupthink)。如果先開放討論，聲音最大的人會主導方向。
Step 3：輪流分享 (10-15 分鐘)
按座位順序，每人輪流唸出一個失敗原因。注意：
- 每次只講一個，輪完一圈再來第二輪
- 不評論、不反駁、不解釋
- 有重複的直接跳過
- 持續到所有原因都被說出來
Step 4：分類與排序 (10 分鐘)
把所有失敗原因分成幾類：
| 類型 | 範例 |
|---|---|
| 技術風險 | 第三方 API 不穩定、效能無法承受流量 |
| 人的風險 | 關鍵工程師離職、跨部門溝通斷裂 |
| 市場風險 | 使用者根本不需要這個功能、競品搶先 |
| 流程風險 | 需求不斷膨脹、時程被壓縮 |
| 外部風險 | 法規變更、合作夥伴跳票 |
然後用投票（每人 3 票）選出「最可能且最致命」的 Top 3。
Step 5：制定預防計畫 (10-15 分鐘)
針對 Top 3 風險，各指定一位負責人，回答：
- 監測信號：什麼跡象出現時代表這個風險正在發生？
- 預防措施：現在可以做什麼降低機率？
- 應變方案：如果真的發生了，Plan B 是什麼？
發展歷程
| 年代 | 事件 |
|---|---|
| 1989 | Mitchell、Russo 和 Pennington 發表「預見性後見之明」研究，證明假設結果已知時人的推理能力更強 |
| 2007 | Gary Klein 在 Harvard Business Review 發表 Performing a Project Premortem，將學術概念轉化為實用管理工具 |
| 2011 | Daniel Kahneman 在《快思慢想》中推薦 Pre-Mortem 作為對抗過度樂觀偏誤的武器 |
| 2018 | Spotify、Google、Amazon 等科技公司將 Pre-Mortem 納入專案啟動標準流程 |
真實案例
案例一：台灣電商的雙十一備戰
一家台灣電商平台在雙十一前做了 Pre-Mortem：
團隊列出的失敗原因中，排名第一的不是「系統掛掉」（技術團隊對此很有信心），而是「物流商在第三天就爆倉，客服被退貨電話淹沒」。
結果他們提前跟物流商談了緊急擴容方案，並準備了自動退貨系統。事後證明：系統果然沒掛，但物流真的差點爆倉。
案例二：新功能上線前
一個 SaaS 產品團隊在推出新計費模式前做 Pre-Mortem。最意外的發現：產品經理和工程師對「免費試用結束後的行為」有完全不同的假設。PM 認為會自動降級，工程師認為會直接鎖帳號。
如果沒做 Pre-Mortem，這個分歧會在上線當天變成客訴海嘯。
實戰步驟
準備
- 邀請 5-10 人，包含不同角色（PM、工程、設計、QA、營運）
- 準備便利貼或 Miro/FigJam 白板
- 指定一位主持人（最好不是專案負責人，避免防禦心態）
執行
- 設定場景：「專案已經失敗了」
- 靜默書寫 5-8 分鐘
- 輪流分享，記錄所有原因
- 分類 → 投票 → 選出 Top 3
- 針對 Top 3 制定預防/應變計畫
產出
- 風險清單（含分類與嚴重度排序）
- Top 3 風險的負責人、監測信號、預防措施、應變方案
- 下次檢查點（建議 2-4 週後回顧）
Do’s and Don’ts
Do
- 強調「沒有笨問題」，鼓勵說出直覺式的擔憂
- 讓資淺成員先發言（避免被主管意見帶走）
- 會後真的追蹤 Top 3 風險，不要做完就忘
- 定期回顧：專案進行中每月做一次 mini Pre-Mortem
Don’t
- 不要讓它變成「找戰犯」的會議
- 不要只列技術風險而忽略人和流程的問題
- 不要在 Pre-Mortem 後還是一切照舊——那只是在浪費時間
- 不要在團隊壓力最大的時候做（會變成集體抱怨大會）
Maki’s Take
Pre-Mortem 是我見過 CP 值最高的風險管理工具——花 30 分鐘，可能省掉三個月的冤枉路。
在台灣的團隊文化裡，很多人不好意思在啟動會議上說「我覺得這個會失敗」，因為會被認為不夠積極。Pre-Mortem 的妙處在於它給了你一個正當理由去說出擔憂：「不是我悲觀，是流程要求我們這樣做。」
我特別推薦在以下情境使用：
- 老闆的寵物專案：大家都不敢說不，但心裡都有疑慮
- 跨部門協作：每個團隊都有自己的「已知但不說的風險」
- 趕工趕到天昏地暗時：強迫自己停下來想 30 分鐘，比衝完才發現方向錯好太多
跟「逆向思維 (Inversion)」很像？核心差異是：Pre-Mortem 聚焦在特定專案的風險辨識，Inversion 是更通用的思維工具，用來拆解任何問題。Pre-Mortem 問「這個專案怎麼死的」，Inversion 問「怎麼做才能確保失敗」。前者是風險管理，後者是策略思維。
容易搞混？
這些框架看起來很像，但用途不同。