1. 前言
如果你是一名工程师，你很可能对这个场景不陌生：一个微不足道的线上问题，一次小小的发布延迟都会有人提议："咱们拉个会复盘一下吧。"
这几年在工作中，没事就听到有些人说："我觉得这个事情有必要复盘一下"，导致我听到"复盘"这个词，就会本能性地产生心理厌恶。似乎不开会反思复盘一下，工作就不够"有深度"。似乎搞了一次复盘，下次类似错误就会自动消失了，这种现象，我称之为"复盘疲劳症"。很多根本不必要的复盘，不仅浪费了宝贵的专注时间，还把一个本应是强大成长工具的复盘，变成了一种形式主义的表演。
2. 什么是复盘？什么是"无效复盘"？
2.1 复盘的定义
要批判一件事情，先要了解本身
"复盘"一词源于围棋，指对局结束后，重新演练棋局的进程，以分析得失关键 。其核心精髓在于从"亲身经历"中学习。这是一个至关重要的前提：复盘的对象是 自己亲身参与的事件 ；而对他人事件的研究和学习，更准确的定义是"案例研究"。
与"总结"相比，"复盘"具有本质区别。工作总结通常是个人对工作内容的梳理和陈述，往往以展示成绩为主，结构较为松散 。而复盘是一个结构化的、以学习为导向的团队活动。它不仅回顾目标与结果，更强制要求对两者之间的差异进行深入的原因分析，从而提炼出经验教训，找到未来可改进之处 。
关键词：
- 自己亲身参与的事件
- 结构化的、以学习为导向的团队活动
2.2 什么是无效复盘
这些无效复盘通常有以下特征：
- 形式主义复盘：为了复盘而复盘，把"露脸"，"作秀"当作最终目的，汇报表演的成分大于实际反思。
- 甩锅大会：会议的焦点不是"如何改进"，而是"谁的责任"，演变成部门间或个人间的责任推诿。
- 管理焦虑：部分管理者自身对业务缺乏掌控感，便通过不断要求下属复盘来制造一种"一切尽在掌握"的假象，以缓解自己的焦虑。
- 小题大做：对一些显而易见、早已达成共识的小问题，反复开会讨论，浪费所有人的时间。
3. 什么时候该复盘？什么时候不需要复盘？
3.1 复盘的种类
很多时候，我们感到心累，是因为公司用一个模糊的词"复盘"，涵盖了完全不同重量级的四种工具。搞清楚它们的区别，你就掌握了反客为主的第一步。
| 种类 | 描述 | 目标 |
|---|---|---|
| 事故复盘 | 这是最重型的武器，它只应该在发生严重故障时（比如服务宕机、数据丢失、安全漏洞）使用 。 | 挖出根本原因，防止下一次灾难 |
| sprint回顾 | 这是团队的"定期体检" 。通常在每个Sprint结束时进行（说实话，我觉得每个sprint也太频繁了），关注的是团队协作、流程和工具，目的是让下一个周期更顺畅。 | 微波炉一样，让持续改进，而不是分析某个特定事件 |
| 事后复盘 | 这是最轻便、最高效的工具，源自军队 。一次部署、一个功能上线、一次客户演示，无论成功还是失败，都可以花15分钟快速回顾一下。 | 快速学习，立即应用到下一次任务中 |
| 项目复盘 | 这是大型战役结束后的"全面战报" 。在一个大项目或重要里程碑完成后，邀请所有相关人一起，回顾从规划到交付的整个过程。 | 为未来的大型项目积累经验 |
这四件事的目标和场景完全不同。如果把一次小部署问题升级成"事故复盘"，就是典型的"杀鸡用牛刀"。
3.2 什么时候要复盘？
当事件符合以下一个或多个标准时，一次正式的、结构化的复盘是必要且值得的：
| 标准 | 场景举例 | 为什么 |
|---|---|---|
| 影响重大 | ● 线上重大故障，导致用户无法使用或公司资产受损。 ● 项目延期严重，影响了产品发布和市场节奏。 ● 一次成功的产品发布或者运营活动，带来了远超预期的用户增长。 | 结果对业务产生了巨大影响（无论是正面还是负面），必须深挖其根本原因，以防止灾难重演或复制辉煌。 |
| 原因不明 | ● 一个偶发的性能问题，排查过程一波三折，原因不清不楚。 ● 用户反馈某个功能体验不好，但内部多个团队看法不一。 ● 新功能上线后，用户的使用路径和我们预想的完全不同。 | 问题的根源不清晰，涉及多个可能的变量和环节。需要集体智慧来还原完整的事实链条，找到真正的症结。 |
| 多次复现 | ● 版本发布流程中，总是某个特定环节容易出错。 ● 跨团队沟通时，信息反复出现遗漏或误解。 ● 类似的线上告警在不同模块中反复出现。 | 如果不从机制和流程上解决，同样的问题会一而再、再而三地发生。复盘的目标是打破这个循环。 |
| 涉及方多（跨团队/多角色） | ● 一个涉及前后端、算法、测试、产品的复杂项目。 ● 需要与法务、市场、运营等多个部门协作才能完成的需求。 | 问题可能出在团队间的协作流程、沟通机制或责任边界上。单方面反思无法解决问题，必须拉通所有相关方共同对齐。 |
3.3 什么时候"下次注意"就够了？
当问题符合以下特征时，过度复盘就是一种资源浪费，一句"下次注意"或一个简短的周知即可：
| 标准 | 场景举例 | 为什么 |
|---|---|---|
| 影响轻微 | ● 一个页面的文案有个错别字，被迅速修正。 ● 测试环境的一个配置错误，在几分钟内被修复。 | 问题的影响范围和损失几乎可以忽略不计，投入大量时间讨论的性价比极低。 |
| 原因清晰 | ● 某人提交代码时，手误删掉了一行关键配置。 ● 因为忘记执行某个脚本，导致xxxx。 | 根本原因一目了然，没有深入挖掘的必要。当事人已经清楚问题所在，重复强调反而会打击其积极性。 |
| 已有预案 | ● 发生了某个已知问题，团队按照标准处理流程快速解决了。 | 团队已经对这类问题有成熟的解决方案和处理机制，需要做的是遵循和优化流程 |
| 孤立事件 | ● 由于某个第三方服务极其罕见的抖动，导致了短暂的异常。 | 事件的触发条件非常特殊，几乎不可能再次发生，从中提炼出的经验也缺乏普适性。 |
简单来说：当一个问题是"简单的疏忽"或"已知的个例"时，"下次注意"就是最经济高效的选择。
4. 如何向上管理，应对不必要的复盘？
面对一些无聊的"复盘"的指令，直接拒绝显然不明智。你可以尝试用更专业、更高效的方式来"向上管理"：
- 用总结代替会议 ：
- 在问题发生后，不等领导安排，第一时间主动在工作群或邮件中发出一个简短的总结，内容包括：问题现象、根本原因、处理过程、责任人、改进措施。
- 话术建议："老大，关于刚才那个问题，我们已经定位并修复了。根本原因是xxx，是一个简单的疏忽。我们已经做了xxx改进，确保下次不会再犯。具体情况我发了个简短的纪要，大家有空看下就行，就不用专门拉会占用大家时间了。"
- 用数据和逻辑来沟通 ：
- 可以尝试用投入产出比（ROI）的思路来沟通。
- 话术建议："这个问题的根本原因我们已经很清楚了。如果要开一个正式的复盘会，可能需要X位同事投入Y小时准备材料和开会。我们评估下来，这次复盘能产生的新增价值有限。我们更倾向于把这些时间投入到当前正在攻坚的XX项目中，您觉得呢？"
- 引导会议方向，化被动为主动：
- 如果复盘无法避免，那就努力成为会议议程的引导者。
- 会前 ：主动草拟一个会议议程，将重点聚焦在未来的改进项 而非过去的时间线。
- 会中：当讨论开始偏向追责或跑题时，主动将话题拉回来。"感谢大家帮我们还原了时间线，那么我们接下来重点讨论一下，为了避免这个问题，我们下一步的具体行动计划是什么？谁来负责？截止日期是？"
最终，我们的目标不是为了逃避责任，而是为了推动团队和项目更高效地运转。
5. 如果要复盘，我们应该怎么做？
这是一个庞大的话题，我仅从我印象深刻的两点来简单展开我的个人认识，抛砖引玉。
5.1 不表演
- 还原事实： 会前，构建一份详细、客观的事件时间线（包括部署、告警、代码提交、关键决策等）。这将使讨论锚定在事实而非主观指责上 。
- 行动项要可落实： 行动项模糊不清（如"要更细心"、"加强文档"）、没有负责人，或从未被跟进。这证明会议本身就是目的，而非结果 。
- 归咎于外因： 在责任模棱两可的时候，不要先跳出来倾向于指责其他团队、利益相关者（"他们自己都不知道想要什么"）或前任员工（"都是历史技术债"），不然很容易带偏复盘的进程。
5.2 不做非必要的指责
- 复盘结果最好不要影响绩效： 如果复盘中的任何内容被用来对个人进行负面评价，那么这个流程将不再是诚实反思的工具，而会变成一场在会者的甩锅大会，大家都会出现自我保护的表演 。
- 对事不对人： 对话要围绕"为什么团队会允许这个错误发生？"而不是"谁犯了错？" 。