把錯誤寫進帳本：用 Mistake Log 讓團隊不重複摔同一跤

上週我們複盤一個上線事故，發現同一個設定參數在三個月內踩了三次坑。第一次是 A 同事，第二次是 B 同事，第三次是我們自己。每一次都「修好了」，但經驗只停留在事故群組的滾動訊息裡，沒人沉澱，更沒人接住。

這就是大多數團隊的真實狀態：踩坑的成本付了，學習的收益沒拿到。

什麼是 Mistake Log

Mistake Log（錯誤帳本）就是一個公開文件，只記錄「我們犯過的錯」，不追究個人責任。每條記錄只回答四個問題：

1. 現象：使用者或系統看到了什麼
2. 根因：為什麼會發生（不是「誰手滑」，而是哪個環節缺了防護）
3. 修復：這次怎麼解決的
4. 防再犯：加了什麼規則、檢查或自動化，讓下一次不會重複

注意第四條是核心。沒有「防再犯」欄位的錯誤記錄，只是事故日記。

什麼時候用它

• 團隊超過 3 個人，記憶開始不可靠
• 同一個問題被不同人重複問或重複犯
• 新成員入職，想讓他少走彎路
• 出過線上事故，需要制度化複盤

什麼時候別用

• 一次性的小專案，溝通成本高於維護成本
• 團隊文化還靠「甩鍋」運作——先解決信任問題，再開帳本
• 把它當成績效考核工具。一旦記錯＝扣分，帳本三天內就會變成空文件

最小可用格式

每條記錄控制在 200 字以內，夠用就行：

[日期] [標題]
現象：xxx
根因：xxx
修復：xxx
防再犯：xxx（對應哪條檢查/文件/自動化）

格式越長，填寫率越低。200 字是實踐中的甜蜜點。

使用清單

• 錯誤帳本放在全團隊可見的位置，和任務看板同層
• 每條記錄必須有「防再犯」欄位，否則打回補全
• 每週站會用 2 分鐘過一遍本週新增條目
• 新人入職第一週，通讀一遍帳本
• 每季清理一次：把已被自動化覆蓋的條目標記為「已固化」
• 只寫系統層根因，不寫人名

常見坑

1. 寫成追責工具：標題裡出現人名，貢獻率立刻歸零。規則寫死：標題只寫問題，不寫人。
2. 只記不閉環：「防再犯」寫了「加強注意」等於沒寫。注意不是機制，檢查項和自動化才是。
3. 搜尋性為零：標題寫「週二那個 bug」，半年後沒人搜得到。標題要寫現象關鍵字，讓未來的你能搜到過去的你。
4. 寫得像小說：500 字的事故故事沒人讀。壓縮到四行以內，細節放事故群組的原始記錄裡，帳本裡貼個連結。
5. 只記技術錯誤：需求理解偏差、流程溝通失誤同樣是高頻坑，而且往往損失更大，一併記。

兩週能落地的路徑

第一天建文件、定格式；第一週每次複盤後順手記一條；第二週站會開始例行過帳本；一個月後你會發現，新人的問題清單明顯變短了——因為答案都在帳本裡。

錯誤本身不可怕，可怕的是每次都把學費交一次。

一句話總結

Mistake Log 的門檻極低：一個文件、一個格式、每週兩分鐘。它的價值在於把「個人的教訓」變成「組織的資產」——今天你踩過的坑，明天接手的同事不必再踩一遍。先寫下一條，比想好標準更重要。