踩过无数坑才摸透：真正能用的技术复盘方法
别拿开会记笔记当技术复盘
我刚工作那几年也觉得，复盘不就是走个流程吗？上线崩了，领导要交代，那就开个会，找个背锅的，写几条改进意见，交差完事。
直到三年前，我们团队同一个底层缓存的穿透问题，一年炸了三次，我才醒过来。
我们之前做的哪叫复盘？那叫给老板交作业。
说实话，现在百分之八十的技术团队，复盘都是这个德行。开头吵半小时甩锅，中间说一堆正确的废话，最后结尾全是空口号。文档写了好几页，存到git上，这辈子再也没人打开过。
无效技术复盘会议场景实拍
有这时间开俩小时会，不如让开发回去多写两个单元测试，对吧？
真正能解决问题的三步技术复盘法
后来我跟着谷歌过来的架构师改了复盘的玩法，这两年我们团队相同问题重复犯的概率，降了九成多。核心就是三步。
第一步，先剥掉主观判断，纯还原事实。任何复盘开始的前十五分钟，只准说“我做了什么”“出现了什么现象”“有什么日志/文档为证”，不准说“我觉得”“肯定是”“谁谁谁没做好”。
去年我们推荐系统迭代翻车，准确率掉了7个点，一开始算法工程师一口咬定是数据团队给的特征错了，数据团队说我们这边输出一切正常，吵了二十分钟，后来翻开timeline一看，原来是前一天运维改定时任务的时间，全量特征同步任务根本没跑。哦，原来双方都没锅，一开始方向全错了。你看，要是上来不先还原事实，这复盘从第一步就歪了。
第二步，挖根因挖到不能再挖，别停留在“粗心”上。我见过太多复盘，根因写“开发人员粗心大意”“测试人员漏测”。这叫什么根因？人都会犯错，你把根因归到个人身上，那下次换个人还是会错。真的根因，一定是系统或者流程的问题，对吧？
这里我常用5Why追问法，举个例子：线上出了bug→为什么出？因为漏测→为什么漏测？因为这个分支是边界场景，测试没覆盖到→为什么没覆盖到？因为我们测试用例只覆盖了主流程→为什么只覆盖主流程？因为我们没有要求所有代码分支必须写单元测试→为什么没有要求？因为团队没有这个规范。哦，这才是根因。解决了规范的问题，这个问题才不会再犯。
技术复盘5Why根因分析法示例图
第三步，输出到人到时间到可验证的改进行动。很多人的行动项写的是“加强测试质量”“提高开发水平”，这跟没写一样。合格的行动项必须说清楚：谁来做，做完是什么标准，什么时候上线，谁来验证。
比如说刚才那个规范问题，行动项就应该是“技术主管老李，本周五之前输出《团队单元测试规范》，明确所有新增代码覆盖率必须不低于60%，下周一全团队评审通过后，下个版本开始执行，QA在提测阶段检查覆盖率”。就这么具体，做完就能落地，不会不了了之。
两个绝大多数人都忽略的细节
两个绝大多数人都忽略的细节
第一个，成功项目比失败项目更值得复盘。很多团队只有出事儿了才复盘，成功的项目就直接庆功，没人回头看。
我之前碰见过一个项目，本来预计三个月上线，结果两个半月就做完了，客户还特别满意，所有人都说就是运气好。我逼着大家坐下来复了一次盘，最后发现，核心原因是这次我们把需求拆成了周度可交付的小模块，每次客户改需求，只影响当前模块，不会牵一发动全身。这个方法我们后来推广到所有ToB项目，项目交付准时率从50%涨到了85%。你说值不值？
第二个，别让领导主导复盘过程。太多复盘，领导一坐下来，第一句话就是“这次问题主要就是xxx”，得了，全场没人敢说话了，本来能挖到的根因，全被憋回去了，最后复盘变成了领导的一言堂，训话会。
我现在带团队复盘有个规则：前四十分钟，管理层不许发言，先让一线开发、测试、产品说自己实际碰到的问题，讲完了领导再说话。
不过话说回来，也不是说领导完全不能参与，只是别上来就定调，把天聊死。
技术复盘本质上就是把个人踩坑攒出来的经验，变成整个团队的公共资产。你不复盘，不沉淀，经验就跟着人走，人一走，后来的人再从头踩一遍坑，攒一遍经验，这浪费的时间和成本，够做好几个项目了。
真的，别再把复盘当交差了。改改方法，你会发现，团队进步的速度能快一倍都不止。