事後檢討入門 不究責的事故回顧看板|依時間順序寫下發生的事,找出機制原因與防止再發的任務

專案與開發

事後檢討入門 不究責的事故回顧看板|依時間順序寫下發生的事,找出機制原因與防止再發的任務

適合第一次進行事後檢討(postmortem)的開發與營運團隊使用的入門範本。故障或重大失誤收尾後的一週內,可以不追究個人責任地依時間順序整理發生的事,並定下機制層面的原因與防止再發的任務。白板共 4 張:第 1 張確認不究責的約定,寫下事故概要,並定下要收集的資料與帶來資料的人;第 2 張把從發生到確認穩定的經過排成 6 段時間線,用數字寫出影響;第 3 張用 5 Whys(五問法)挖掘機制層面的原因,並依效果與精力選出對策;第 4 張把對策分派為有負責人與期限的任務,並定下分享的對象、日期與下次要確認的事。任務看板分為「收集資料」「討論中」「對策執行中」「效果確認中」「已完成」5 欄,放有與 4 張白板對應的父任務 4 項,每項各 3 件子任務。不知道怎麼寫事後檢討時,把白板②~④寫進概要,⑦寫進影響,⑫寫進根本原因,⑰寫進教訓,⑭寫進防止再發的措施,報告就成形了。採用不追究個人、而是看機制的「無責(Blameless)」流程,所以即使是第一次,也能和限定公開團隊的成員一起寫,討論不容易變成互相指責。

0 讚 0 複製 作者: WeProcess
事後檢討 故障應對 回顧 防止再發 五問法
免費註冊並使用此範本

免費註冊後,即可從範本市集複製並使用此範本

白板預覽

預覽模式 事後檢討入門 不究責的事故回顧看板|依時間順序寫下發生的事,找出機制原因與防止再發的任務

白板預覽

① 回顧的約定(從這裡開始,先由全員一起讀) ② 發生了什麼 ③ 從何時到何時 ④ 誘因(在已知範圍內) ⑤ 要收集的資料與帶來的人(討論前一天之前) ⑥ 依時間順序的時間線(依⑤收集的資料排列) ⑦ 影響的大小(用事實與數字書寫) ⑧ 還不清楚的事(不要斷定,先分開放) ⑨ 順利的事(來自⑥的時間線) ⑩ 不順利的事(來自⑥) ⑪ 運氣好的事(來自⑥) ⑬ 選擇對策(把對⑫的原因有效的對策放進來) 效果大 × 精力投入多 效果大 × 精力投入少 效果小 × 精力投入多 效果小 × 精力投入少 ⑭ 防止再發的任務(來自⑬選出的對策) ⑮ 要分享回顧的對象 ⑯ 分享的日子與傳達方式 ⑰ 教訓(直接寫進報告) ⑱ 下次回顧時要確認的事 事後檢討入門看板(不究責的事故回顧) 使用方式(共 4 張):① 確認不... 決定的事、對策 約定、負責人 故障、不順利的事 發現、順利的事 1/4 營造不究責的氛圍 Ctrl+F / ⌘F : 2/4... → 2/4 2/4 依時間順序整理 ↙ 3/4 看的是機制,而不是人不問「誰犯了錯」而是談「為什麼容易犯錯」 當時的判斷有其理由不以事後才知道的事來究責。例:依當時看得到的資訊來思考 區分事實與推測推測的部分要註明「推測」二字。例:推測:設定的變更可能是原因 例:下單頁面打不開了 例:客戶無法下單 照看到的症狀原樣寫下 原因先不寫(在第 3 張中挖掘) 例:開始 10月6日 14:05 例:結束 10月6日 15:20 例:現在已恢復正常 時間以紀錄為準,並用 24 小時制書寫 例:14:00 發布了頁面更新 例:推測:設定值一直是舊的 尚未釐清的寫「不明」 推測的部分註明「推測」二字 要收集的資料 帶來資料的人 截止時間 系統紀錄 例:錯誤紀錄、存取量圖表 負責人:____ 例:回顧會前一天之前 聯絡紀錄 例:聊天對話、電話備忘 負責人:____ 例:回顧會前一天之前 客戶的聲音 例:詢問件數與內容 負責人:____ 例:回顧會前一天之前 發生 14:05發生的事例:下單頁面打不開了 發現 14:20誰、用什麼發現的例:接到詢問的客服人員發現了 通知 14:30通知了誰、怎麼通知的例:在開發團隊的聊天群組裡通知 處理 14:40做了什麼例:開始把 14:00 的更新復原 復原 15:20何時恢復原狀例:下單頁面可以再次打開了 確認穩定 16:00如何確認的例:訂單數恢復到平常的水準 用數字寫出 確認所依據的紀錄 可靠程度 受影響的人 例:無法下單的人 約 120 人 例:存取紀錄 例:推測(正在確認計算方式) 停止的時間 例:75 分鐘(14:05~15:20) 例:錯誤紀錄 例:事實 詢問 例:8 件 例:詢問清單 例:事實 停擺的工作 例:出貨準備延後了 1 小時 例:倉庫的通知 例:事實 還不清楚的事例:14:05~14:20 之間,為什麼沒有收到通知 負責調查的人與期限負責人:____ / 期限:__/__ 查明後補寫的位置例:補寫到⑥的時間線與⑦的表格裡 3/4 挖掘機制層面的原因 → 4/4 4/4 分派防止再發的任務 例:客服人員立即通知了開發團隊 例:復原的步驟寫在手冊裡 寫下下次也能同樣應對的理由 例:更新後下單頁面打不開了 例:直到發現花了 15 分鐘 主語寫事件,而不是人 例:剛好是客戶較少的時段 例:熟悉狀況的人剛好在座位上 下次不能靠運氣,所以列為對策候選 ⑫ 五問法(5 Whys):從⑩選... 為什麼1 例:為什麼打不開?→ 設定值一直是舊的 為什麼2 例:為什麼一直是舊的?→ 發布前沒有在測試環境驗證 為什麼3 例:為什麼沒驗證?→ 手冊裡沒有驗證的步驟 為什麼4 例:為什麼沒有?→ 沒有決定由誰負責修訂手冊 為什麼5 例:為什麼沒決定?→ 即使改了步驟,也沒有修訂手冊的規定 根本原因 例:步驟變更與手冊更新沒有連動(機制層面的原因) 縦軸: 效果(上=大) / 横軸:... 規劃後推進。例:做一個發布前自動驗證的機制 最優先做。例:在手冊裡加上「發布前驗證」 這次先擱置。寫明理由並留下紀錄 順手做。例:把聯絡人名單更新到最新 做什麼 誰來做 何時之前 如何確認 對策 1 例:在手冊裡加上「發布前驗證」 負責人:____ 例:1 週後 例:看下次發布是否照步驟進行 對策 2 例:規定改步驟時也要同步修訂手冊 負責人:____ 例:2 週後 例:團隊一起對照確認這項規定 對策 3 例:錯誤增加時要能收到通知 負責人:____ 例:2 週後 例:刻意製造錯誤,看有沒有收到通知 對策 4 例:做一個發布前自動驗證的機制 負責人:____ 例:1 個月後 例:統計機制擋下的件數 例:客服團隊 例:主管與相關部門 例:使用同一機制的其他團隊 例:10 月 10 日的例行會議上花 10 分鐘 例:在聊天群組分享報告 日期:__/__ / 負責人:____ 例:發布前驗證的步驟不寫進手冊就會漏掉 例:客服越早聯絡,復原也越快 寫下關於機制而非個人的心得 要確認的日子例:1 個月後的例行會議日期:__/__ 要確認的數字例:⑭的對策完成了幾項例:同樣的故障有沒有再次發生 確認的人負責人:____結果請補寫到本白板的⑭裡 → 2/4 依時間順序整理 ↙ 3/4 挖掘機制層面的原因 → 4/4 分派防止再發的任務
100%

拖曳可移動,滾動滑鼠滾輪可縮放

任務看板內容

收集資料 16 項

營造不究責的氛圍
依時間順序整理
挖掘機制層面的原因
分派防止再發的任務
逐條朗讀不究責的約定
寫下故障概要
確定資料與負責人
排列時間線
用數字寫出影響
區分未知的事
整理做得好與待改進之處
連續追問 5 次為什麼
依效果與精力選對策
把對策變成任務
決定分享的對象與日期
決定下次要確認的事

討論中 0 項

對策執行中 0 項

效果確認中 0 項

已完成 0 項

← 返回範本一覽