程序员10年成长记：第8篇：复盘，最好的成长“算法”——我的第一个项目总结

程序员10年成长记：第8篇：复盘，最好的成长“算法”——我的第一个项目总结

引言

时间进入2018年初，寒潮席卷了全国，但北京中关村的创业咖啡馆里却是一片火热。一个幽灵般的词汇——“区块链”——正取代“AI”，成为每个投资人嘴里的“万亿级赛道”。“ALL IN 区块链”的口号，甚至压过了刚刚过去的双十二。

启明科技的新零售业务，在经历了“幽灵库存”的惊魂一夜后，总算磕磕绊绊地跑了起来。那次P0级事故（最高级别故障），让CEO和CTO意识到，公司规模的扩张速度，已经超过了工程能力的成长速度。

CTO在技术委员会上态度坚决：“我们不能用‘996’和‘救火’来掩盖流程和能力的缺失。这次事故，必须做一次‘穿透式’的复盘，不追究个人，但必须定位到流程和文化的根源。”

这场复盘会，由老李（凤凰项目组）和David（新零售事业部）共同主持。消息一出，两个团队的反应截然不同。

小故事：一场“成败在此一举”的复盘会

1. 会议前的众生相

• David的“新零售”团队： David在他们部门内部先开了一个“通气会”。“CTO要复盘，大家注意口径。这次是凤凰组的MQ消息有问题，我们是被动方。小健，你把日志准备好，到时候把压力给回去。” 团队成员们如临大敌，把复盘会当成了一场“甩锅自证会”。小健一边整理着“证据”，一边还在看一篇《区块链如何赋能新零售供应链》的公关文，心想：David总监说的对，我们做的是“星辰大海”，不能被这些“技术细节”拖后腿。

• 老李的“凤凰”团队：

  • 张三在工位上撇撇嘴：“唉，又搞形式主义。复盘会有什么用？不就是写个PPT，找几个倒霉蛋背锅，然后该咋样还咋样。”

  • 老李把小葵叫到办公室：“小葵，这次复盘，对你，对团队，都是一次绝佳的成长机会。”

  • 小葵有些不解：“老李，我们不是已经找到问题（幂等性）也解决了吗？”

  • 老李摇摇头：“你找到的是‘技术根因’，但不是‘系统根因’。复盘的精髓，不是找到‘谁’犯了错，而是找到‘什么’让犯错变得容易。”

  • 他递给小葵一支笔：“你不要只站在‘凤凰组’的角度，你试着站在‘公司’的角度，去思考：为什么两个团队会做出‘错误’的技术假设？为什么在测试阶段没发现？为什么出了事第一反应是‘甩锅’？我希望你准备一个分析，明天在会上分享。”

小葵若有所思。她花了半天时间，没有去整理日志，而是去采访了测试组的同事、David组的开发（小健）以及负责MQ的运维，画出了一张复杂的图。

1. 复盘会上的“交锋”

   会议室里气氛凝重，CTO也来旁听。

   David先发制人：“CTO，我们复盘过了，我们团队996连轴转，执行力没有问题。问题出在消息源头，凤凰组发来的消息有重复，导致我们重复扣减……”

   小健刚要打开日志，老李打断了他：“David，我们今天不是来‘定责’的。CTO让我们复盘，是让我们当‘医生’，给‘启明科技’这个病人做一次会诊，而不是当‘律师’，来打一场官司。”

   老李在白板上写下了复盘会的唯一原则：“我们在此分析流程，而非指责个人。”

2. 小葵的“5-Why”与“鱼骨图”

老李转向小葵：“小葵，你来带我们梳理一下。我们用‘5-Why’分析法，来深挖一下根源。”

小葵走上台，打开了她的PPT。

• Why 1：为什么会发生“幽灵库存”？

  • 答：因为仓储服务（新零售）对同一笔订单，重复扣减了库存。

• Why 2：为什么会重复扣减？

  • 答：因为它消费了MQ里的“重试消息”。

• Why 3：为什么会消费“重试消息”？

  • 答：因为仓储服务在处理第一条消息时，因DB抖动而超时，导致MQ认为“消费失败”，从而“自动重发”。

• Why 4：为什么“重发”会导致“重复扣减”？

  • 答：因为仓储服务（消费者）没有做“幂等性”处理。

• Why 5：为什么“没有做幂等性处理”？

  • （会议室里安静了。小健低声说：“D-God排期太紧，没时间……”）

  • 小葵给出了她的答案：“这不是一个团队的问题。根源在于：两个团队在技术契约上，存在‘假设鸿沟’。”

  • “凤凰组（生产者）假设：MQ是可靠的，发一次就行。”

  • “新零售组（消费者）假设：收到的消息都是唯一的。”

  • “而MQ的“At-Least-Once”（至少一次）投递策略，恰好打破了这两种假设。”

全场哗然。David的脸红一阵白一阵。

小葵接着展示了她画的“鱼骨图”（Ishikawa Diagram），系统地呈现了导致事故的所有原因：

张三在台下看得目瞪口呆，他原以为复盘就是“批斗会”，没想到还能这么“技术流”。

1. 产出“Action Items”

老李总结道：“小葵的分析很到位。我们不是要‘消除’问题，而是要‘建立’一个能‘自动’防止问题发生的‘系统’。下面，我们来定义‘Action Items’（行动项）。”

1. AI-1 (技术): 立即实施小葵上次提出的“统一幂等SDK”方案，所有核心服务强制接入。(Owner: 小葵, Deadline: 3周)

2. AI-2 (流程): 建立“跨团队技术评审委员会”，所有涉及跨服务调用的需求，必须有“技术契约文档”（ADR）并通过评审，方可排期。(Owner: 老李, Deadline: 2周)

3. AI-3 (人员): 组织一次“分布式系统设计”的强制培训，覆盖MQ、RPC、幂等性、熔断等主题。(Owner: 小葵, Deadline: 4周)

会议结束时，CTO站起来说：“今天的复盘会，是我在启明科技参加过的质量最高的一次。小葵的分析，就是我们需要的‘工程师文化’——从经验中学习，用系统去改进。小葵，你来牵头这个培训吧。”

小健走出会议室，第一次对David的“大厂黑话”产生了动摇，他发现小葵那种“把事做对”的执着，似乎比“把饼画大”更有力量。

核心要点：从经验中学习，把事做对，更要“做对的事”

“复盘”不是“秋后算账”，它是团队成长的核心“算法”。

• 复盘 ≠ 总结： 总结，是对“结果”的陈述；复盘，是对“过程”的剖析。

• 对事不对人： 这是复盘的“灵魂”。如果复盘会变成了“甩锅会”，那它就彻底失败了，团队将丧失“说真话”的能力。

• 从“偶然”到“必然”：

  • 低级团队： 依靠“救火英雄”（如小葵）的偶然爆发来解决问题。

  • 高级团队： 通过“复盘”，把“英雄”的经验，转化为“流程”和“工具”，让“成功”变得“必然”。

• 做对的事 (Do the right things) vs 把事做对 (Do things right):

  • 小健的996，是想“把事（David交代的）做对”。

  • 小葵的复盘，是在思考什么是“做对的事”（建立幂等规范，这才是“对的事”）。

关键技能：复盘的“工具箱”

1. 戴明环 (PDCA Cycle):

2. 这是所有质量管理和持续改进的“元理论”。复盘，就是PDCA中的“C”和“A”。

1. 5-Why 分析法 (5-Whys):

   1. 理论： 由丰田公司提出，通过连续追问“为什么”，穿透表面现象，直达“根本原因”（Root Cause）。

   2. 实战：

      • 问题： 网站服务器宕机了。

      • Why 1 (宕机)? 因为CPU 100%。

      • Why 2 (CPU 100%)? 因为一个Java进程占满了CPU。

      • Why 3 (进程占满)? 因为它在处理一个API请求时，陷入了“无限循环”。

      • Why 4 (无限循环)? 因为代码中处理一个“树状结构”时，出现了“循环引用”的脏数据。

      • Why 5 (脏数据)? 因为数据入库时，校验逻辑不严谨，没有检查“父ID”是否是自己的“子ID”。

   3. 根因： 不是“宕机”，而是“入库校验逻辑缺失”。

   4. AI： 修复脏数据（治标），增加数据库约束和入库校验（治本）。

2. 鱼骨图 (Ishikawa / Fishbone Diagram):

   1. 理论： 适用于分析“复杂”问题，当“根因”不止一个时。它将原因归纳为几个大类（如人、机、料、法、环），帮助系统性思考。

   2. 实战： 见小故事中“幽灵库存”的分析。它能把“技术问题”（幂等性）和“管理问题”（996文化）并列在一起，展现出一个“系统”的全貌。

实战要点：如何组织一次有效的复盘会

1. 会前准备：

   1. 任命“中立”的主持人 (Facilitator): 最好是像老李这样，受人尊敬、不直接涉事的人。绝对不能是David那样的“利害关系方”。

   2. 设定“基调” (Ground Rules): 在邀请邮件里就明确：“对事不对人”、“我们假设每个人都已尽力”。

   3. 收集“数据” (Data): 匿名收集大家对“什么做得好”、“什么做得不好”的看法。

2. 会议进行 (4个W):

   1. 1. What - 发生了什么 (客观事实):

      • 只说事实，不带观点。

      • （错误）: “张三写的代码有Bug。”

      • （正确）: “在10月26日，A接口返回了500错误。”

   2. 2. Why - 为什么会发生 (原因分析):

      • 这是核心。使用“5-Why”或“鱼骨图”来深挖。

      • 鼓励所有人发言，把所有可能的原因都列在白板上。

   3. 3. What if - 我们能学到什么 (经验总结):

      • “我们学到了什么？”

      • “哪些是我们可以复用的‘好经验’？” (Keep)

      • “哪些是我们要停止的‘坏做法’？” (Stop)

   4. 4. What next - 下一步怎么做 (行动计划):

      • 这是复盘的“出口”。

      • 所有AI，必须有“Owner” (负责人) 和 “DDL” (截止日期)。

      • 没有AI的复盘，就是“形式主义”，就是在浪费时间（张三的错误认知）。

3. 会后跟进 (最重要的):

   1. 主持人（老李）需要持续跟进AI-1, 2, 3的完成情况。

   2. 如果AI没有被执行，复盘的“闭环”就断了，团队会立刻丧失对复盘的“信任”。

推荐书籍

《复盘+：把经验转化为能力》 - 陈中/邱昭良

• 核心内容与思想：

  • 复盘的“双环”学习：

    1. 单环学习 (Single-Loop Learning): 像张三一样，只停留在“What”层面。知道了“幂等性”错了，下次“修复”它。这只是“纠错”。

    2. 双环学习 (Double-Loop Learning): 像小葵一样，深入到“Why”层面。不仅修复Bug，还要反思“为什么我们会犯这种错？”、“我们的流程是不是有问题？”。这才是“改进”。

  • 复盘的四大步骤 (本书核心):

    1. 1. 回顾目标 (Review): 我们的初衷是什么？（如：按时上线）

    2. 2. 评估结果 (Result): 实际发生了什么？（如：出P0了）

    3. 3. 分析原因 (Reason): 为什么会这样？（使用5-Why、鱼骨图）

    4. 4. 总结规律 (Rule): 我们学到了什么？如何应用到未来？（产出AIs）

  • 工具化： 本书最大的价值在于提供了“如何开复盘会”的SOP（标准作业程序），从会前准备到会后跟进，手把手教学，非常适合工程师和管理者阅读。

这场复盘会，是小葵职业生涯的一次“质变”。她不再是一个被动的“代码执行者”，而是开始主动地去“优化系统”。她通过一次成功的复盘，不仅为自己赢得了新的机会（牵头技术培训），也开始真正理解老李所说的——一个工程师的价值，最终体现在他能多大程度上，改善他所在的“系统”。