開會前先「驗屍」：五分鐘 pre-mortem 能救回多少專案

上週我幫一位朋友複盤了一次產品改版。新版本上線兩週，核心轉換率掉了 11%，團隊的第一反應是「使用者變了」、「大盤不好」，開了三次會都沒找出誰是兇手。後來一位同事問了句：「如果現在告訴你這次改版徹底失敗了，最可能的原因是什麼？」會議室安靜了三秒，然後七個人寫出了九條原因，其中兩條是建立在「我們假設使用者看得懂新導航」上的錯誤假設——而這正是導致轉換率下滑的直接原因。事後看來，如果上線前花五分鐘做一遍 pre-mortem，這兩條假設會被當場攔截。

一句話規則

**在投入之前，先假設這件事已經失敗了，用五分鐘寫下「它是怎麼死的」，把寫出來的每一條當成待驗證的風險清單。**

注意順序：預設「會失敗」，然後找死因。它不是普通的腦力激盪，而是強行將人的樂觀偏差調低一档。

具體使用場景

**1. 重大發布或改版前。** 新功能上線、定價調整、全站改版。開場白固定：「假設現在是三週後，這次改版失敗了。為什麼？」每人獨立寫 3 條，再合併去重。重點盯著「我們沒意識到自己在假設什麼」的那幾條——失敗幾乎都死在隱藏假設上。

**2. 做出重要承諾之前。** 答應客戶三天交付、答應主管月底前上線。先問：什麼情況下我會交不出貨？資源不夠、依賴方拖延、範圍蔓延、自己高估速度。哪條最可能，今天就先處理哪條，而不是等它發生。

**3. 寫第一篇長文或提案之前。** 長文或提案的下馬威不是「寫得差」，而是「寫給錯的人」或「前提就是錯的」。假設三個月後這篇文章沒人轉發／這個提案被駁回，最可能的原因是什麼？答不上來就先別動筆。

**4. 接手不熟悉的系統進行第一次大改。** 修改舊程式碼、動到舊設定前，先寫「這次改動會怎麼搞出事故」：有哪些地方依賴它？復原要走幾步？誰會被通知？寫不出事故鏈的人，往往是因為沒真正理解這個系統。

什麼情況不需要 pre-mortem

- **三分鐘內能做完的小事**：回個訊息、改個錯字、部署一次只改了一個常數的熱修復（hotfix）。驗屍的成本比事故本身還大，純屬浪費。

- **風險極高到「隨時可能掛掉」的場景**：生產環境資料正在遺失、安全事件正在發生。這時候的動作是止血和復原，不是坐下來討論它為什麼死。

- **你已經做過三期同類專案、流程全熟**：pre-mortem 的價值在於暴露未知，熟手的重複專案裡它產出的是套話，帶一個新人一起做反而更值。

五分鐘執行清單

- [ ] 開頭那句話是「假設它已經失敗了」，不是「你覺得有什麼風險」（後者會得到客氣的標準答案）

- [ ] 每人**獨立寫**，禁止邊寫邊討論——人會在討論中把自己的想法說圓、把尖銳的懷疑磨掉

- [ ] 每條風險寫下來後補一句「**怎麼驗證它不存在**」，驗證不了的風險等於實錘

- [ ] 合併後只挑**最可能發生的前 2-3 條**處理，不追求列盡所有可能

- [ ] 給這 2-3 條指定負責人和檢查時間，寫進待辦事項；沒有負責人的風險清單 ＝ 廢紙

容易踩的坑

**坑一：把 pre-mortem 開成追責會。** 一旦有人在找「誰寫的這個爛需求」，後面的人就會集體沉默。事前討論失敗是安全的，事後討論失敗才危險。主持人看到火苗立刻拉回來：「對事不對人，我們討論的是假設中的失敗。」

**坑二：只寫「不會發生」的那幾條。** 大家習慣性地列出熟悉的、可控的風險（伺服器掛了、人手不夠），然後互相點頭「哦這個我們有預案」，會就散了。真正值錢的答案是那些讓人「嗯」了一聲、忘了反駁的——追問它。

**坑三：無期限地用它防風險。** 每個決定都做 pre-mortem，等於每次出手前都要慢 20 秒，團隊會開始跳過它或敷衍它。只對「撤銷成本高、影響面大」的決策做，小的照常。

收尾

pre-mortem 的產物不是那份清單，而是清單裡那兩三條被提前攔截的死因。下次要發版、要承諾、要動舊系統之前，先問出那句「假設它已經失敗了」。五分鐘，換一次不用複盤的運氣。