【背景】 做了 15 年技术 PM，去年我把过去 12 个月的线上事故复盘文档（P3 及以上，共 12 篇）拉出来做了一次「action 落地率」统计，结果有点扎心：
- 12 篇复盘，共列出 47 条 action（含监控补点、配置调整、代码改造、文档补齐）；
- 30 天内真正合入 / 上线的：只有 4 条，落地率 8.5%；
- 其中 2 条是「补告警」类的（最容易做），剩下 2 条是配置参数调整；
- 22 条 action 标注了 owner，但 19 条在 60 天后状态仍是「进行中」；
- 真正改动了架构 / 链路的（比如把某个同步调用改成异步、把单库拆读副本）：0 条。
我的直觉：复盘文档本身没有价值，价值在「action 落地 + 验证 + 回看」。但多数团队把复盘做成了「事故归档 + 甩锅澄清 + 写满 action 表示重视」——写完就归档，没人再打开。
【常见的三种做法】
-
重流程派：P3+ 必须复盘，72h 内出文档，action 必须有 owner + deadline，月度 review 时逐条 check。代表是不少大厂标准 SOP。
- 优点：流程闭环，责任清晰。
- 我观察到的问题：action 数量多、颗粒度粗（「优化链路」算一条），review 时 owner 说「排期没到」就顺延，3 个月后整篇 action 表基本全黄。
-
轻动作派：不复盘，只出「3 条 action 卡片」（每条 ≤ 1 人天工作量），直接进 sprint backlog，按正常需求排期。
- 优点：颗粒度小、落地率高。
- 我观察到的问题：容易漏掉「需要跨团队 / 跨季度」的大改进项，比如容量规划、架构冗余；另外「不复盘」意味着没有集体记忆，半年后新人接手不知道当初为什么这么改。
-
双轨派：小事故（P4/P5）走轻动作卡片，大事故（P2 及以上）走正式复盘 + 跨团队 review + 季度回看。
- 优点：按事故级别分配成本。
- 我观察到的问题：「P 级怎么定」本身就是争议点，很多团队 P3 和 P4 的边界是拍脑袋，导致「该走正式复盘的走了卡片、该走卡片的走了正式」。
【我的倾向与理由】 我倾向第 3 种，但会加两条硬约束：
约束 1：action 必须有「可验证的完成标准」。不是「优化链路」，而是「把 /order/query 接口的 P99 从 42ms 降到 35ms，且 P999 不劣化超过 10%，验收数据附在 PR 描述里」。没有可验证标准的 action 不允许写入复盘文档。这条能砍掉 60% 的「进行中」action——因为写不出来的人，多半是没想清楚。
约束 2：季度回看，不是月度。月度 review 太频繁，owner 容易用「排期」挡；季度回看 + 把「未落地 action」显式列在季度 OKR 里，压力更真实。我去年 Q3 用这个方式，把 47 条 action 里 11 条真正重要的挑出来进 OKR，Q4 落地了 9 条，落地率从 8.5% 拉到 81%（注意分母变了，是「挑出来的 11 条」而不是「原始的 47 条」）。
核心观点：复盘文档的价值不在「写完」，在「少写但写准 + 季度回看 + 进 OKR」。47 条 action 里只有 11 条值得做，把另外 36 条砍掉不是偷懒，是资源聚焦。
【想听大家在什么场景下怎么选】
- 你们团队 P3+ 事故的复盘 SOP 是哪种？重流程 / 轻卡片 / 双轨？
- 有没有做过类似「action 落地率」的统计？数据和我差多少？
- 「action 可验证标准」这条约束，你们落地时最大的阻力是什么？（我遇到的是：开发同学觉得「写验收标准比写代码还累」）
- 季度回看 vs 月度 review，你们怎么选？什么规模 / 什么业务节奏下月度 review 才值得？
- 一个更尖锐的问题：如果复盘文档的「读者」只有事故当事人 + owner，那这篇文档的 ROI 是不是其实很低？你们怎么让复盘文档变成「组织记忆」而不是「事故归档」？