結論先講
Retro 和 Postmortem 是團隊進化的引擎。但大多數團隊做得不好——不是變成抱怨大會，就是做完沒有任何改變。關鍵在三件事：(1) Blameless——怪系統不怪人 (2) Action Items 要有負責人和期限 (3) 要追蹤上次的改善有沒有真的執行。沒有這三個，你的 Retro 只是浪費一小時。
Postmortem vs Retrospective：不一樣的東西
先釐清：這兩個常被搞混，但用途不同。
| Postmortem | Retrospective | |
|---|---|---|
| 觸發時機 | 出事的時候（系統故障、重大 bug、專案失敗） | 固定週期（每個 Sprint 結束） |
| 目的 | 找出根因、防止再發生 | 持續改善團隊流程 |
| 範圍 | 針對單一事件 | 整個 Sprint 的各面向 |
| 產出 | 事件報告 + action items | 改善行動 |
| 參與者 | 事件相關人員 | 整個團隊 |
簡單說：Postmortem 是救火後的檢討，Retro 是日常的健身。
Blameless Postmortem：怪系統不怪人
為什麼要 Blameless
如果每次出事都懲罰犯錯的人：
- 人們會隱藏問題（「不說就不會被罵」）
- 人們會推卸責任（「不是我的鍋」）
- 團隊永遠找不到真正的根因
Blameless 不是說「沒人有責任」，而是說「我們先不討論誰的責任，先搞清楚系統哪裡壞了」。
語言很重要
| 指責性語言 | Blameless 語言 |
|---|---|
| 「小明為什麼沒有做測試？」 | 「我們的流程在什麼環節沒有確保測試被執行？」 |
| 「是誰核准了這個部署？」 | 「部署流程的審核機制為什麼沒有攔住這個問題？」 |
| 「設計師給的規格有誤」 | 「規格傳遞的過程中，哪裡出了落差？」 |
Blameless 的邊界
Blameless 不適用於：
- 故意破壞
- 重複犯同樣的錯且拒絕改善
- 違反安全協議
這些情況需要另外的機制處理，不在 Postmortem 的範圍內。
5 Whys：挖出根因
5 Whys 是最簡單也最有效的根因分析工具。
方法
對問題連問五次「為什麼」，每次的答案是下一個為什麼的基礎。
實戰範例：電商結帳故障
事件：週五下午 3 點，結帳功能故障 2 小時，影響約 500 筆訂單。
為什麼 1：結帳為什麼故障？ → 金流 API 回傳 500 錯誤，系統沒有處理，直接顯示白頁。
為什麼 2：為什麼系統沒有處理 500 錯誤？ → 錯誤處理只覆蓋了 400 系列的錯誤，沒有處理 500 系列。
為什麼 3：為什麼只處理了 400 系列？ → 開發時金流測試環境從沒回過 500 錯誤，所以沒考慮到。
為什麼 4：為什麼測試環境沒有模擬 500 錯誤？ → 測試案例是根據金流文件寫的，文件沒有列 500 錯誤的情境。
為什麼 5：為什麼測試案例只依賴文件？ → 沒有做 chaos testing 或 error injection 的流程。
根因：缺乏系統性的異常情境測試流程。
Action Item：建立 error injection 測試標準，所有外部 API 整合都要包含 timeout、500 error、empty response 的測試案例。
5 Whys 的陷阱
- 不要停太早：問到第二個就停，通常只解決表面問題
- 不要變成追責：「為什麼小明沒寫測試？」→ 這是在追人，不是追系統
- 可能不只一條鏈：一個問題可能有多個根因，畫成樹狀圖更好
Postmortem 模板
# Postmortem：[事件名稱]
## 摘要
- **日期**：2026-03-14
- **影響時長**：2 小時（15:00 - 17:00）
- **影響範圍**：所有結帳使用者（~500 筆訂單）
- **嚴重度**：P1
## 時間軸
| 時間 | 事件 |
|------|------|
| 15:00 | 監控告警：結帳 API error rate > 50% |
| 15:05 | 值班工程師確認問題 |
| 15:15 | 定位原因：金流 API 回傳 500 |
| 15:30 | 聯繫金流商確認是他們的問題 |
| 15:45 | 實施暫時方案：切換到備用金流 |
| 16:00 | 備用金流上線，結帳恢復 |
| 17:00 | 金流商修復，切回主要金流 |
## 根因分析
（使用 5 Whys）
根因：缺乏外部 API 異常的系統性測試和 fallback 機制。
## 做對了什麼
- 監控在 5 分鐘內發出告警
- 團隊 15 分鐘內定位問題
- 有備用金流可以切換
## 做錯了什麼
- 沒有自動 fallback 機制（手動切換花了 30 分鐘）
- Error handling 只覆蓋 400 系列錯誤
- 值班手冊沒有金流故障的 SOP
## Action Items
| # | 行動 | 負責人 | 期限 | 優先度 |
|---|------|--------|------|--------|
| 1 | 實作自動 fallback 機制 | 小明 | 3/28 | P1 |
| 2 | 補齊 500 error 的 error handling | 小華 | 3/21 | P1 |
| 3 | 更新值班手冊加入金流 SOP | 小李 | 3/21 | P2 |
| 4 | 建立 error injection 測試流程 | 小明 | 4/1 | P2 |
## 教訓
永遠假設外部 API 會壞——設計 fallback、處理所有錯誤碼、建立自動切換機制。Retrospective 格式大全
1. Start / Stop / Continue
最經典的格式：
| 分類 | 說明 | 範例 |
|---|---|---|
| Start | 我們應該開始做的 | 開始做 code review checklist |
| Stop | 我們應該停止做的 | 停止在 standup 討論技術細節 |
| Continue | 繼續做的好事 | 繼續 pair programming |
適合：新團隊、第一次做 Retro。
2. 4Ls
| 分類 | 說明 |
|---|---|
| Liked | 這個 Sprint 喜歡什麼 |
| Learned | 學到了什麼 |
| Lacked | 缺少了什麼 |
| Longed for | 希望有什麼 |
適合：想要更多正面回饋的場景。
3. Mad / Sad / Glad
| 分類 | 說明 |
|---|---|
| Mad 😡 | 讓你憤怒的事 |
| Sad 😢 | 讓你失望的事 |
| Glad 😊 | 讓你開心的事 |
適合：團隊需要情緒出口的時候。
4. Sailboat（帆船法）
🌟 Star（目標）
|
💨 Wind（助力） → ⛵ 我們 ← ⚓ Anchor（阻力）
|
🪨 Rock（風險）
| 元素 | 問題 |
|---|---|
| 星星 | 我們要往哪裡去？ |
| 風 | 什麼在推動我們前進？ |
| 錨 | 什麼在拖慢我們？ |
| 礁石 | 前方有什麼風險？ |
適合：團隊需要看到全貌的時候。
選哪個格式？
| 情境 | 推薦格式 |
|---|---|
| 新團隊、不熟悉 Retro | Start/Stop/Continue |
| 想聚焦情緒和士氣 | Mad/Sad/Glad |
| 需要策略性思考 | Sailboat |
| 想要正面導向 | 4Ls |
| 做了太多次同一格式 | 換一個！ |
Action Items 必須可追蹤
Retro 最常見的問題不是「沒有討論」，而是「討論了沒做」。
好的 Action Item
| 要素 | 說明 | 範例 |
|---|---|---|
| Who | 誰負責 | 小明 |
| What | 做什麼（具體） | 建立 code review checklist |
| When | 什麼時候完成 | 下個 Sprint 結束前 |
| How to verify | 怎麼驗證完成 | Checklist 在 Notion 上且團隊知道 |
壞的 Action Item
- 「我們應該溝通更好」（怎麼溝通更好？）
- 「大家要注意程式碼品質」（什麼叫注意？怎麼衡量？）
- 「改善部署流程」（怎麼改？改成什麼樣？）
追蹤機制
每次 Retro 的前 10 分鐘回顧上次的 Action Items：
| Action Item | 狀態 | 備註 |
|---|---|---|
| 建立 code review checklist | ✅ Done | Notion 連結 |
| 改善 CI/CD 速度 | 🔄 進行中 | 已降到 8 分鐘，目標 5 分鐘 |
| 每週一次 knowledge sharing | ❌ 沒執行 | 重新討論要不要繼續 |
沒做到的，討論為什麼：是不重要了？還是太難了？還是忘了？然後決定：繼續做、調整、或放棄。
Retro Anti-patterns
1. 沒有 follow-up
每次 Retro 都提出改善，但沒人追蹤。三個月後同樣的問題再出現。
解法：把 Action Items 放進 Sprint Backlog，跟功能 ticket 一起管理。
2. 永遠在抱怨同一件事
「溝通不好」「需求不清楚」「開會太多」——每次都講，但從來沒解決。
解法：把大問題拆成小行動。「溝通不好」→ 「每個 PR 都要有 description 模板」。
3. 只有負面沒有正面
Retro 變成批鬥大會，士氣越來越低。
解法：強制加入正面環節。「每個人至少說一件這個 Sprint 做得好的事。」
4. 強勢的人主導討論
某個人講很多，其他人都不說話。
解法：先用便利貼（或線上工具）讓每個人寫下想法，再投票選主題討論。保證每個人都有發言的機會。
5. 主管在場不敢說真話
大家都很客氣，真正的問題沒人敢提。
解法：主管可以先離開讓團隊討論，或使用匿名回饋工具（如 Retrium、EasyRetro）。
心理安全感：讓人敢說真話
心理安全感是 Google 的 Aristotle 計畫發現的高效團隊第一要素。沒有心理安全感，Retro 只會聽到「一切都很好」。
怎麼建立
1. Leader 先示範脆弱
「這個 Sprint 我做錯了一個決定——我應該先做 spike 再估算，而不是直接拍一個數字。」
主管先承認錯誤，其他人才敢跟著說。
2. 回應方式決定一切
當有人說「我覺得我們的 code review 流程有問題」：
| 回應 | 效果 |
|---|---|
| 「你自己的 code 也沒多好」 | 💀 以後沒人敢講 |
| 「有嗎？我覺得還好啊」 | 😶 下次不會再提 |
| 「可以多說一點嗎？你觀察到什麼？」 | 💚 對話打開了 |
3. 不秋後算帳
Retro 裡提的問題，不能在績效考核裡翻舊帳。如果小華在 Retro 說「我在 deployment 時犯了一個錯」，主管不能在年底考核寫「deployment 出過問題」。
4. 讚美具體行為
不要說「做得好」，說「你主動在 Slack 上同步金流串接的進度，讓整個團隊都知道狀況，這很棒」。具體的讚美讓人知道什麼行為是被鼓勵的。
Retro 會議流程模板
| 步驟 | 時間 | 活動 |
|---|---|---|
| 1 | 5 分鐘 | 回顧上次 Action Items 進度 |
| 2 | 10 分鐘 | 個人靜默寫便利貼（按選定的格式） |
| 3 | 10 分鐘 | 分享和分組（把相似的歸類） |
| 4 | 5 分鐘 | 投票選出要深入討論的主題（每人 3 票） |
| 5 | 20 分鐘 | 討論前 2-3 個主題，產出 Action Items |
| 6 | 5 分鐘 | 確認 Action Items（Who / What / When） |
| 7 | 5 分鐘 | Retro 的 Retro（這次 Retro 本身做得怎樣） |
總計：60 分鐘
工具推薦
| 工具 | 特點 | 價格 |
|---|---|---|
| EasyRetro | 簡單好用、匿名投票 | 免費方案可用 |
| Retrium | 多種格式、有引導 | $29/月起 |
| Miro | 自由度高、可客製 | 免費方案可用 |
| FigJam | 設計師愛用 | Figma 付費用戶免費 |
| Notion | 跟其他文件整合 | $10/月起 |
對於小團隊，EasyRetro 的免費方案就很夠用了。
FAQ
Q1：每個 Sprint 都做 Retro 會不會太頻繁？
不會。但如果每次都講一樣的事、沒有改善，那確實會變成浪費時間。解法不是減少頻率，是確保每次都有 follow-up。如果真的覺得太頻繁，試試每兩個 Sprint 做一次，但每次拉長到 90 分鐘。
Q2：Retro 跟 1-on-1 有什麼差別？
Retro 是團隊層面的改善，1-on-1 是個人層面的。有些事適合在 Retro 說（「我們的 deploy 流程太慢」），有些適合在 1-on-1 說（「我跟小明合作有困難」）。兩者互補，不能互相替代。
Q3：遠端團隊怎麼做 Retro？
用 EasyRetro 或 Miro 取代實體白板。流程不變，但要注意：(1) 靜默寫便利貼的時間可以拉長（少了面對面的壓力，有些人需要更多思考時間） (2) 討論時用 round-robin 確保每個人都說話 (3) 開鏡頭，看到表情很重要。
Q4：Postmortem 要公開嗎？
建議公開（至少在工程團隊內部）。公開的 Postmortem 有兩個好處：(1) 其他團隊可以學習，避免犯同樣的錯 (2) 展示 blameless 文化——公開討論錯誤不會被懲罰。Google、GitLab 都公開他們的 Postmortem。
Q5：如果 Action Items 一直做不完怎麼辦？
可能是因為 Action Items 太大、太模糊、或沒人真的在意。解法：(1) 把 Action Item 拆到一天能完成的大小 (2) 放進 Sprint Backlog 當正式的 ticket (3) 如果連續兩次 Retro 同一個 Action Item 都沒做，問團隊：「這真的重要嗎？如果不重要就刪掉。」
系列總結
恭喜你看完了整個專案管理系列！快速回顧八篇的核心觀念：
- 需求拆分：小到可以估、清楚到不用問
- 工時估算：給範圍不給數字、用歷史數據校準
- Agile：心態比儀式重要
- Backlog：用框架排序、用數據說不
- Sprint Planning：圍繞 Goal、留 buffer、等量交換
- 專案追蹤：指標是溫度計不是目標
- 向上管理：用對方聽得懂的語言、帶選項不帶問題
- Retro & Postmortem：Blameless + Action Items + Follow-up
專案管理沒有銀彈。但掌握這些基本功，至少能讓你的團隊少踩一些坑。