故障复盘入门 不追责的事故回顾看板|按时间顺序写下发生的事,找出机制原因与防止再发的任务

项目管理与开发

故障复盘入门 不追责的事故回顾看板|按时间顺序写下发生的事,找出机制原因与防止再发的任务

面向第一次进行故障复盘(事后检讨)的开发与运维团队的入门模板。故障或重大失误收尾后的一周内,可以不追责地按时间顺序整理发生的事,并定下机制层面的原因与防止再发的任务。白板共 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 项

← 返回模板一览