做壞的事自己會走進檢討會；沒出事的事不會——而下一次翻車，通常就藏在沒出事的事裡。

一場多問了一題的會

昨天的 Review 看的是產品：客服主管當場退了一筆測試訂單、財務看了對帳檔、兩個修正排進下一輪。今天這場會，看的是我們自己。

Retro 的開場沒有什麼特別。便利貼分兩欄：做得好的——切片的節奏很穩、AC 讓驗收不用吵；做不好的——聯調環境掛過半天、測試資料重建太麻煩。討論、認領、收斂成兩條改進事項。到這裡為止，是一場標準的、健康的、再二十分鐘就可以散會的 Retro。

但 PM 沒有收會。他在白板最上面多寫了一題：

「這一輪，有哪些事情是因為某個人剛好知道答案，才沒有爆炸？」

會議室安靜了幾秒。跟 Day 01 那種安靜不一樣——那次是沒有人答得出來，這次是每個人都在回想。

然後，負責金流串接的工程師慢慢舉起手。

兩件沒出事的事

第一件，webhook 重送。

AC 裡有一句「重複通知不會退兩次」，第二刀加寬的時候，防護也照著做進了程式。一路平安，平安到沒有人多想過它。

他在 Retro 上把來歷講出來：那句 AC，是寫完成條件那天他提的。因為上一次，那筆被標記兩次的訂單，就是從他串的那段線炸出去的；財務調平帳的那幾天，他被問了幾次，自己都數不清。Day 18 說過，被非同步咬過的人，看到金流兩個字就會先問那一題——現在，這個團隊自己也有被咬過的人了。

「但如果寫 AC 那天我剛好請假，這句就不會在。」他說。「而且防護的寫法在我腦裡，程式裡有做，卻沒有測試守著。下次有人改到 webhook 處理，防線就只剩下我記得提醒。」

第二件，月底鎖帳。

排這一輪部署日的時候，PM 把日期往前挪了三天。有人順口問了為什麼。PM：「避開財務月底鎖帳啊，那幾天不能動帳務相關的東西。」「這條寫在哪？」

PM 想了一下：「……沒有寫在哪。上次月底對帳對不上，財務追到我座位旁邊，我從此記得。」

兩件事的共同點：都沒出事。也正因為沒出事，它們永遠不會出現在「做不好」那一欄。而它們沒出事的原因，不是流程擋住了什麼——是有人剛好知道。

當場落地，兩件都是。重送防護寫成自動化測試：同一筆通知送兩次，斷言只退一次，從此紅燈替他站哨。鎖帳窗口寫進部署 Runbook：檢查清單多一行「今天是不是財務鎖帳日」。一件半天，一件五分鐘。

為什麼平常的 Retro 抓不到

大多數團隊對 Retro 的理解大概是：檢討做不好的，慶祝做得好的，列出幾條改進事項，下一輪追蹤。每句都有道理，而且說真的，很多團隊連這樣的 Retro 都沒有，能做到已經贏過一半的人。

但這個格式有一個結構性的盲點：它只看得見「發生了的事」。

做壞的事有證據——延期、bug、對不上的帳，自己會走上白板。做得好的事有掌聲。而「差點出事、被某人的腦袋擋下來」的事，什麼都沒有留下：沒有延期、沒有 bug、沒有聲音。它被歸檔在「本來就應該這樣」裡，跟空氣一樣自然。

第二部整整七天，講的就是這種空氣。需求有人腦補、介面有人對齊、驗收有人通靈——每一件都沒出事，每一件都在等那個人請假。

出過事的教訓有殘骸當證據；沒出事的「剛好」，無聲無息。

所以 Retro 要多問那一題。不是只問「哪裡做壞了」，還要問「哪裡是靠人救的」——把獵捕範圍從事故，擴大到未遂事故。

把血脈壓制反過來做

Day 14 給這個結構起過名字：血脈壓制。高能力的人用隱性知識補足流程缺口，讓錯的流程一直給出對的結果，組織因此相信流程沒有問題。

Day 14 也說過為什麼不能用蠻力解：要求大神「把知道的全部寫下來」是不可能的，隱性知識之所以隱性，是連本人都不覺得那是知識。金流串接工程師不覺得「webhook 會重送」需要寫下來——對他來說那是常識；PM 不覺得「月底鎖帳」是文件——那只是他的痛。要求一次搬家，只會得到一部誰都不看的百科全書。

Retro 多問的那一題，是把搬家改成分期付款：

每一輪，獵捕兩三件「還好有人剛好知道」
   ↓
問：如果他不在場，會發生什麼？
   ↓
挑最痛的，落地成最小的形式
   ↓
規則類 → Acceptance Criteria／Test
決策類 → ADR
操作類 → Runbook／Checklist
交界類 → Interface Contract
   ↓
下一輪，再兩三件

注意，這不是在消滅大神，是把血脈壓制反過來做。第二部的方向是：流程缺一塊，人補上，缺口原封不動。這裡的方向是：人補上的那一刻，正是缺口現形的一刻——趁它現形，把它變成不需要人的東西。

還有一件事，這一輪看得特別清楚：大神仍然不在——資深工程師還在另一個專案救火——可是「剛好知道」並沒有因此絕跡。金流串接工程師之於重送、PM 之於鎖帳：每個人都是某幾件事的大神。血脈壓制從來不是某一個人的問題，是知識存放位置的問題。所以那一題不是問給最資深的人的，是問給白板前的每一個人。

順帶一提，這個責任瀑布不是沒想過。它的答案叫 Lessons Learned，放在結案之後——立意正確，時機致命：人散了、記憶涼了、下個專案的人不會回來讀。敏捷把同一個責任搬進每一輪的節奏裡，趁記憶還熱、人還在場、下一輪馬上用得到。差別跟 Day 03 講回饋時一樣：不是有沒有做，是它離現場多遠、來不來得及改變下一步。

這次到底誰在吸收代價？

老規矩。

Scope       □   下一輪照常排：Review 的兩個修正＋Retro 的兩件落地
Time        ■   一小時的會、半天的測試、五分鐘的 Runbook——有意識地付
Cost        □
Quality     □
Risk        □   兩件事的 Bus Factor，從一變成不需要
人          □   ← 本輪兩件「剛好知道」已落地，沒有人需要繼續當防線

對照第二部：同樣是「有人剛好知道」，Day 08 到 13 的團隊把它記成「還好有他在」，人那一格連勾六次；這一輪的團隊把它記成「這裡有個洞，順便補掉」，用一小時加半天，把兩條防線從人腦換成測試與 Runbook。

差別不在誰比較強。差別在有沒有一個固定的時刻，讓「剛好」被看見。

今日 Artifact｜隱性知識落地記錄

在 Retro 尾聲加十分鐘，每輪填個兩三組就好，不要貪多：

□ 這一輪，＿＿＿＿剛好知道＿＿＿＿，我們才沒有＿＿＿＿
□ 如果他不在場，會發生：＿＿＿＿＿＿
□ 落地成：＿＿＿＿（AC／Test／ADR／Runbook／Contract／Checklist）
□ 誰負責、哪一輪完成：＿＿＿＿

填的時候會發現，它跟 Day 14 的大神依賴盤點表長得很像。沒錯，就是同一件事——差別是那張表是一次性的健檢，這張是裝進節奏裡的例行檢查。健檢查得出病，治慢性病靠的是例行。

今日一句

每一句「還好他剛好知道」，都是一份還沒寫的文件、一顆還沒爆的雷；Retro 多問的那一題，是趕在爆炸之前拆彈。

該補的防線補上了，重做的退款專案，之後順利上線。

明天是系列最後一天。我們回到 Day 01，回答第一天問的那兩個問題。