Pre-mortem 在華語團隊跑不起來的 3 個理由（以及怎麼救）

Pre-mortem（事前驗屍）由心理學家 Gary Klein 在 2007 年 HBR 那篇經典短文提出：在專案啟動前，假設它一年後失敗了，請團隊寫下失敗原因。研究顯示這個練習能讓潛在風險的辨識度提高約 30%。

但我們在輔導華語團隊跑 Pre-mortem 時，遇到的失敗模式遠多於成功。問題不在框架本身，而在框架預設的會議文化——一個假設大家敢說、會互相挑戰、不會因為打槍主管而吃癟的環境。這在東亞職場不是常態。

失敗模式一：主管先講話，於是大家都同意主管

西方 Pre-mortem 的標準流程是「請每個人獨立寫下失敗劇本」，但在華語會議裡，主管常常會先「定調」——「我覺得這個專案最大的風險可能是...」一旦定調，後面的人不是補充就是同意，幾乎不會有真正獨立的視角浮現。

結構性救法：強制「先寫後說」

開場前發白紙或數位表單，要求每個人在 10 分鐘內獨立寫完三個失敗原因——主管也要寫，但主管最後一個分享。寫完之前任何人不能說話。這個動作打破了「先發言的人定調」的權力結構。

在 Apexhone 內部，我們的 Pre-mortem 一律在主管缺席的前半小時完成書寫，主管後加入聽。

失敗模式二：面子文化讓「批評」變成人身攻擊

「這個專案會失敗」在華語語境裡，常被聽成「你會把它做失敗」。即使刻意用「假設」語氣，被指認的負責人還是會感到被攻擊。結果是大家集體進入禮貌模式——只說那種「不會傷到任何人面子」的安全失敗原因，比如「市場時機」「景氣不好」「政策變動」。真正的風險（人員配置不對、技術選型錯誤、利益衝突）永遠說不出口。

結構性救法：用「角色而非個人」承擔風險

把失敗原因的句式從「XX 沒做好」改成「XX 角色被以下因素拖累」。例如不是「PM 估時太樂觀」，而是「PM 這個角色面對 Q4 三個專案併發時，估時很難精準」。這個框架借用了 Six Thinking Hats 的角色分離邏輯——讓人批評角色而不是批評那個人。

失敗模式三：失敗劇本寫完沒人接住

就算前兩關過了，第三關常常斷在執行：失敗劇本寫了一頁，會議結束，紀錄歸檔，沒人負責把這些風險轉成實際的緩解動作。三個月後專案果然出問題，主管說「當時 Pre-mortem 都討論過了啊」——但沒人記得當時討論的具體緩解計畫是什麼，因為根本沒有寫下來。

結構性救法：每個失敗劇本配一個「啟動條件」與「負責人」

把 Pre-mortem 的輸出格式從「風險清單」改成「監測條件 + 觸發行動 + 行動負責人」的三欄表。例如：「（監測）每週技術 sprint review 出現第二次 scope creep —— （觸發）暫停新功能、做一次 30 分鐘技術債清查 —— （負責人）Tech Lead」。

這樣 Pre-mortem 才會從「儀式」變成「保險」。Apexhone 在 /new 紀錄 Pre-mortem 時也會引導你寫下回顧時機——這就是把失敗劇本拉回現實的機制。

一個沒有人喜歡的真相

Pre-mortem 之所以難跑，不是因為框架難，而是因為它逼整個團隊面對「我們可能會失敗」這件事，而多數組織的預設是維持「我們會成功」的集體幻覺。框架只是工具，文化才是門檻。

好消息是，這三個結構性救法不需要改變文化——它們是用會議設計繞過文化障礙。當 Pre-mortem 在你的團隊跑成功一次，下一次會容易很多。

想在團隊試一次有結構的 Pre-mortem？開 新增決策，選 Pre-mortem 框架，照系統引導的提問順序跑——把這篇文章傳給團隊，用上面三個救法當開會的設計守則。