这篇解决什么问题
项目出事后开复盘会，两小时开下来，最后留下的是一堆情绪和一句“下次注意”。下一次同样的事照旧发生，因为会上没人把“下次怎么改”写成可执行的动作。
这篇交付一套四问结构的复盘：原计划是什么、实际发生了什么、差异为什么产生、下次改什么。四问走完，产出物是一张改法清单，每条改法都有责任人和生效时间。
这篇不解决什么：不做责任认定与处罚建议，那是管理决策，不属于复盘范围；不提供任何“用了某方法事故率下降 X%”的数据，这类数字我没有可靠来源，也不会编；不解决团队信任问题，那需要先修复关系再谈流程。
| 四个问题 | 这一问要拿到的东西 | 最容易跑偏的地方 |
|---|---|---|
| 原计划是什么 | 可核对的目标与时间点 | 计划没留下书面记录，靠回忆 |
| 实际发生了什么 | 一条不带评价的时间线 | 写成责任人的心路历程 |
| 差异为什么产生 | 机制层面的原因 | 停在“沟通不到位” |
| 下次改什么 | 带责任人和生效时间的改法 | 写成“加强重视” |
先立三条通用原则
- 先还原时间线，再谈原因。用“几点几分、谁、做了什么、依据什么”四列把事实摆出来，不加形容词。没有时间线的复盘，一定会退化成各说各话——因为每个人记住的时间点不一样。
- 原因写到机制层就停。判据是：这一条能不能改成一个规则或动作？“某人疏忽”“沟通不到位”都不能，属于描述现象；“某个环节没有双人确认”能，属于机制。写不到机制层，就继续往下问一层“为什么”。
- 每条改法必须带三样：责任人、生效时间、验证方式。缺一样就进不了清单。验证方式要写清“什么时候、看什么、算改好了”，否则改法永远停在纸面上。
四个场景逐个给做法
场景一：项目延期——先算清延在哪一段
适用：整体延期或某个里程碑没赶上。第一反应常是“人手不够”，但多数延期是估算方式的问题。做法是先把计划工期和实际工期按阶段拆开对比，找出偏差最大的那一段，再问那一段为什么估错。
一、原计划
- 目标 [X]，关键节点：[节点 + 承诺日期]，依据 [谁定的]
二、实际时间线
- [日期]：[事件]（事实，不带评价）
- [日期]：[事件]
三、差异与原因
- 总延期 [X] 天，其中 [阶段] 占 [X] 天
- 该阶段估错的原因：[机制层原因，如依赖项未列入计划]
四、改法
- [改法]｜责任人：[人名]｜生效：[日期]｜验证：[什么时候看什么算改好]验收：延期天数能按阶段加总对上总数；原因写到了机制层（能变成一个规则），不是“人手不足”“需求变了”这种停在现象的说法。
场景二：需求变更频繁——统计来源，再定规则
适用：做到一半反复改需求。争论“该不该改”没有意义，先把变更按来源分类计数：谁提的、在哪个阶段提的、造成了多少返工。数据摆出来，规则自然有依据。
一、原计划范围
- 初版需求清单 [X] 项，约定变更流程 [有无约定]
二、变更记录
- 共 [X] 次变更：来源分布 [产品/业务/客户/其他 各几次]
- 发生在 [阶段] 的有 [X] 次，平均每次返工 [X]
三、原因
- 集中在 [阶段] 的机制原因：[如评审前未确认口径]
四、改法
- 规则：[什么阶段之后变更需走什么流程，由谁批]
- 工具：[用哪张表记录，谁维护]｜责任人：[人名]｜生效：[日期]
- 验证：下次项目结束时统计变更次数，对比本次验收：变更按来源统计到了具体次数；改法里至少有一条是流程规则（明确了谁批），不是“加强需求评审”这种无主语的说法。
场景三：线上事故——时间线按分钟记
适用：故障、资损、数据错误。事故复盘最忌讳先定责。先把发现时间、止损时间、恢复时间三个点标出来，算出每个环节的耗时，找出最慢的那一段——通常问题在发现，不在修复。
一、预期状态
- 应然：[系统/指标] 正常表现为 [X]
二、时间线（精确到分钟）
- [时分] 异常发生（依据：[监控/日志]）
- [时分] 被发现（渠道：[告警/用户反馈]）
- [时分] 止损；[时分] 恢复
三、差异原因
- 发现耗时 [X]，原因是 [机制层：如该指标无告警]
- 止损耗时 [X]，原因是 [机制层]
四、改法
- [补告警/加预案/加回滚步骤]｜责任人：[人名]｜生效：[日期]
- 验证：[演练时间] 做一次演练，记录耗时对比本次验收：时间线精确到分钟且每项有依据来源；发现、止损、恢复三段耗时都算出来了；改法里至少一条能靠演练验证。事故是否对外披露、怎么披露，以你公司规定为准。
场景四：跨部门协作失败——写清接口，不写态度
适用：依赖别的部门没拿到结果。这类复盘最容易变成互相指责。解法是把协作拆成“接口”：谁在什么时间前给谁什么东西、以什么形式给、没给怎么办。协作失败通常是接口没定义，不是对方不配合。
一、原约定
- 我方需 [东西]，对方承诺 [时间]，约定形式 [口头/书面]
二、实际
- [日期] 我方发出请求；[日期] 未收到；[日期] 升级到 [谁]
三、原因
- 机制层：[如约定仅口头，无确认节点；对方排期不透明]
四、改法
- 接口定义：谁在 [时间] 前以 [形式] 交付 [东西]，接收方 [谁]
- 兜底：逾期 [X] 天则 [升级路径]
- 责任人：[双方各一人]｜生效：[日期]｜验证：下次协作按期交付率验收：通篇没有出现评价对方态度或意愿的词；改法里写出了具体的接口定义（时间、形式、交付物）和逾期兜底路径。
共性质检清单
复制下面这一整段，逐条打勾，全勾完再发。
□ 四个问题都答了，没有跳过第二问直接谈原因 □ 时间线只写事实，没有形容词和评价 □ 时间线的每一条都能说出依据（日志、记录、聊天记录） □ 差异按阶段或环节拆开算过，不是只给总数 □ 原因写到了机制层，能转换成一条规则或动作 □ 没有出现“疏忽”“不重视”“沟通不到位”这类停在现象的词 □ 没有出现对个人的责任判断，只写环节和规则 □ 每条改法都有：责任人、生效时间、验证方式 □ 改法数量控制在三条以内，多了做不到 □ 验证方式写清了什么时候看什么、算改好了 □ 涉及外部部门的改法，已提前和对方确认过可行性 □ 清单已同步进跟踪表，并设置了复查日期
常见错误
| 错误 | 为什么会出问题 | 改法 |
|---|---|---|
| 会上先定责 | 参与者开始自保，事实被藏 | 先锁时间线，责任人字段只出现在改法里 |
| 原因停在“沟通不到位” | 无法转成动作，下次照旧 | 往下再问一层为什么，直到能写成规则 |
| 改法写“加强重视” | 没有责任人和时间，等于没写 | 补三样：谁、什么时候生效、怎么验证 |
| 一次列十几条改法 | 一条都落不了地 | 砍到三条，先做最容易验证的那条 |
| 复盘完不复查 | 清单变成形式 | 在跟踪表里设复查日期，到点回看耗时数据 |
下一步
找一个刚结束的项目，不管成败，按四问写一遍，全程控制在四十分钟内。写不出来的那一问，通常就是你们团队真正缺的东西：写不出原计划，说明目标没落到书面；写不出时间线，说明过程没有留痕。
第一份复盘只求写完四问，不追求完美。把它存成模板，下一次会前先发给大家填，会上的时间全部用来讨论第三问，效率会明显不一样。
来源说明：四问结构参考了公开的项目复盘类教程中常见的提问框架（第三方实践，非本人验证，核实日期 2026-10-07），本文在其基础上按职场落地需要做了改写；文中涉及的系统、监控与告警功能均为示意，以你本地版本为准，未逐项核实。整理日期：2026-10-07。