为什么需要复盘#

很多时候，复盘被动地与“事故”和“失败”绑定，但这其实狭隘化了复盘的价值。一个高质量的复盘，能带来很大的收益：

1. 知其然，并知其所以然 复盘其实是很好的学习过程。我们不仅要知道“上线延期了”（知其然），更要通过复盘挖出“是因为需求频繁变更、技术选型评估不足，还是因为关键路径上的沟通渠道不畅？”（知其所以然）。只有触及根本，才能真正吸收教训。

2. 避免在同一个地方摔倒两次，降低组织的试错成本。 生产环境对业务连续性要求很高。一个配置失误导致线上故障，第一次发生是“事故”，如果短期内再次发生，那就是管理问题。复盘的核心目的之一就是优化流程、工具或规范。找出为什么没有正确配置的原因，发现配置太多维护太耗时，继续追问，为什么会存在很多配置？发布流程是否有问题？不断寻找问题本质，最终从根本解决问题，将“偶然”的失误，变成不要再发生的错误。

3. 传承“打胜仗”的经验，放大成功实践的价值。 这是最容易被忽略的一点。很多复盘会开成了追究责任大会，只字不提做得好的地方。 我们有个项目团队成员采用apifox自动化API测试脚本，提升了回归测试的效率，让版本发布提前。这个亮点如果不通过复盘进行提炼和分享，它就只是一次“偶然成功”，无法赋能给整个技术部门。通过复盘识别出为可以成为组织级的“最佳实践”，可以推广和应用。

4. 总结规律，固化流程，沉淀为组织资产。 复盘的产出不应仅仅是一份会议纪要，而应该是可执行、可沉淀的组织资产。 通过对一次紧急上线过程的复盘，发现每次都会在数据库变更环节手忙脚乱。那么复盘的产出之一就有更新版的《版本发布上线Checklist》，其中明确增加了“DBA交叉Review SQL脚本”和“SQL回滚预案”两个步骤。这样，知识就被固化为了流程。

避开这些坑#

在我经历的复盘中，效果不佳的会议往往都掉进了以下几个坑：

1. 走形式化复盘：“为了复盘而复盘” 这是最普遍的问题。项目结束，大家被拉进会议室，主持人照本宣科，每个人说几句“学到了很多”、“继续努力”之类的客套话，会议纪要一发，便再无人问津。究其原因，往往是团队成员并未真正认识到复盘的价值，或者上级只是将其作为一项管理任务来“应付”。

2. 追究责任为目的 这在生产事故复盘中尤为常见。虽然明确责任是事故处理的一部分，但如果复盘的重心完全跑偏到“谁来背锅”，那会议将充满辩解、指责和沉默，最终无人愿意暴露真正的问题。可以对比以下的提问方式：

   • “这个功能是谁开发的？为什么测试没发现？”（是不是很熟悉的声音，这将导致防卫与推诿）

   • “发现这个Bug的操作环节和步骤是什么？我们如何改进，让这类Bug在编码或测试阶段就能被发现？当时是什么环境和因素让测试同学难以发现这个问题？”（导向：聚焦问题和流程改进）

     第一种提问叫指责式提问，第二种提问是建设性提问。一个成功的复盘，必须建立在“对事不对人”的心理安全感之上。

3. 强调客观问题，回避主观反思 这通常是“追究责任”文化的副产品。当团队感到不安全时，大家会倾向于归咎于“客观原因”——“需求太急了”、“第三方接口不稳定”、“机器性能不行”。而有效的复盘，会引导大家思考：“面对紧急的需求，我们当时的主观决策是什么？我们有没有更好的应对策略？下次遇到类似情况，我们能做些什么？”

4. 浅尝辄止，不探究问题本质 匆忙的复盘，往往在找到第一个“原因”后就停止了。 引入经典的“5 Whys”分析法就很有必要。

   • 问题：一大清早发现用户无法登录
   • 1 Why：为什么？因为数据库连接池满了。
   • 2 Why：为什么？因为一个慢查询占用了大量连接没有释放。
   • 3 Why：为什么？因为这个查询没有走到索引。
   • 4.Why：为什么？因为新上线的代码中，查询字段的数据类型与索引字段不匹配，导致索引失效。
   • 5.Why：为什么？因为我们的Code Review规范里没有包含对SQL的性能审查。 看到了吧，如果不深挖，结论可能就停留在“修复慢查询”，而根本原因“Code Review规范缺失”则会被忽略，未来还会有类似的问题。

如何有效的复盘

一次结构化的、高效的复盘，可以遵循以下框架：

指导原则：建立安全的会议“场域”

在复盘开始前，主持人需要明确并重申几个基本原则，这是确保坦诚沟通的基石：

• 对事不对人：我们讨论的是“什么”问题，而不是“谁”的问题。

• 假设人人尽力：相信在当时的情况下，每个人都基于已有的信息、技能和资源，做出了自己认为最好的决策。

• 鼓励坦诚：说出真实的想法，哪怕它不那么“动听”。

• 聚焦未来：复盘的目的是为了未来做得更好，而不是沉湎于过去的错误。

  （以上沟通氛围还需要团队文化来做支撑， 如果团队存在推卸文化比较难建立起来信任）

复盘四步法：#

1. 回顾目标 清晰地陈述我们当初的目标是什么。 例如：“我们本次迭代的核心目标是：在双十一零点峰值期间，订单系统的处理能力达到5000TPS，且接口响应时间在200ms以内。”

2. 评估结果 用事实和数据说话，对比目标和结果的差距。 例如：“实际结果是：峰值TPS达到了7500，超预期完成。但核心下单接口的P99响应时间为350ms，未达成目标。同时，我们也发现一个意外的亮点：退款接口的稳定性比预期高很多。”

3. 分析原因 这是复盘的核心。可以采用多种方法引导团队进行讨论，例如：

   • 时间轴分析：按时间顺序梳理关键事件，适用于事故复盘。
   • Start/Stop/Continue：让大家分别思考“我们应该开始做什么”、“停止做什么”、“继续保持什么”。
   • 做得好的/待改进的：最简单直接的分类。 例如：针对响应时间未达标，团队分析出几个原因：1）缓存命中率低于预期；2）一个下游服务的延迟拖慢了整体速度；3）压测的模型不够贴近真实流量。针对退款接口的亮点，则发现是“提前进行了全链路梳理并重构了异步化流程”这一决策起到了关键作用。

4. 总结规律并形成行动项 这是确保复盘会议不“白开”的关键。所有讨论必须落地为具体的、可执行的行动计划，好的行动项还要符合SMART原则。 例如：

   • 模糊的结论：“我们以后要加强沟通。”（无法执行，无法衡量）
   • SMART的行动项：“[谁负责] 负责人张三；[做什么] 在下个迭代前，完成对缓存命中率低问题的根因定位，并输出优化方案；[如何衡量] 优化方案需经过技术评审；[何时完成] 两周内完成。”

落地复盘#

对事：

• 小事及时复盘：比如，一个功能的代码合并冲突花了团队半天时间解决，可以在站会后花15分钟快速讨论下分支管理策略。
• 大事阶段性复盘：比如，项目的重要里程碑完成后，复盘一下第一阶段的跨部门协作流程是否顺畅。
• 事后全面复盘：比如，大促活动结束后，对整个备战、执行、收尾过程进行系统性复盘。

对人：

• 管理者以身作则：管理者要带头示范，而不是只要求下属。在复盘中，管理者需要第一个坦诚自己的失误，例如：“我当时对项目复杂度的评估过于乐观，导致排期紧张，这是我的责任。”这种示范作用远比一百句“大家要畅所欲言”更有效。
• 团队成员养成习惯：将复盘的思维融入日常工作，完成一个任务、解决一个难题后，都可以在脑中快速过一遍：“目标是什么？结果如何？哪里做得好？哪里可以改进？”（可能感觉很难，养成习惯本身都挺难的，一旦形成习惯收益很大，让你日常保持高效状态）

总结#

复盘不是可有可无的流程，它是一种精益求精的工作方式，是一种强大的学习引擎。没有复盘就没有经验积累，一件事天天做，做5年不思考并不是有5年工作经验。你也可以自己进行复盘提升，不限于工作的事情。