复盘，你做到位了吗？

“ 复盘，是研发工作中经常开展的一项活动。有复盘的意识和行为，体现着管理者和执行者对相同错误不再犯第二次的基本期望。有复盘，才有可能帮助研发团队发现和改善现存的问题；完善和及时的复盘能更大程度的帮助研发团队去提高自己的研发能力；不复盘或复盘方法不恰当，就失去了一项重要的挖掘和改善现状的抓手，更谈不上能对团队或个体能力做提升了。那在研发组织中，究竟怎么样做复盘才算是合格和到位的呢？”

01
—
什么是复盘

我们先来找下复盘的本源，有助于我们理解什么是复盘。复盘，围棋术语，也称 “复局”，指对局完毕后，复演该盘棋的记录，以检查对局中招法的优劣与得失关键。下围棋的高手都有复盘的习惯。复盘就是每次博弈结束以后，双方棋手把刚才的对局再重复一遍，这样可以有效地加深对这盘对弈的印象，也可以找出双方攻守的漏洞，是提高自己水平的好方法。**对应到研发工作中，复盘就是每次在做完一件事件之后，对做这件事的过程进行一次回溯，找到流程、工具、方法、人员能力上的漏洞或错误，以便于针对性进行加固或改正，提高研发的水平。**所做的事情可以大到一个项目的交付、小到一次故障的泄露、甚至一次代码的走查。

02
—
怎么做复盘

复盘从发生到结束，每个步骤做的是否方法得当，可以问如下四个问题来做判断：复**盘焦点描述清楚了吗？现象发生的逻辑，分析正确吗？是否找全、找到位根因了？根因的应对举措制定合理吗？**这四个问题在时间序列上，也对应于一次标准复盘应该被执行的四个步骤：

2.1 清晰表达复盘焦点
通俗来讲，就是聚焦复盘的对象或内容，包含复盘的焦点现象和焦点影响。清晰表达焦点现象和焦点影响的目的是让复盘参与者感性的认识问题的表象和破坏力，促成代入感的产生，吸引参与者的思路下一步往深层次去展开。
标准式的焦点现象和焦点影响可表达为：某A功能和某B功能同时打开的时候，发生了设备的复位，影响了业务的连续性，造成一小时的系统瘫痪，导致用户投诉。焦点现象就是复位，焦点影响就是系统瘫痪一小时。描述上做到简明扼要，不要夹杂过多的不相关信息，以免造成信息干扰。

2.2 分析现象发生的逻辑
感官的认识到现象和影响后，就需要透过现象看本质了。这个步骤的做法是一层层分析现象为何会发生的逻辑，将导致现象发生的异常点锚定。异常点可能是业务流程中的某个环节设计不当、也可能是代码实现层面的规范问题、也有可能是特殊场景的考虑欠缺导致设计或实现遗漏，无论是哪种，都推荐在正常流程下把导致现象发生的异常处理细节放大性的描述出来，让现象为何会发生的逻辑在有正常流程对比的背景下被描述清楚。
比如，功能A或功能B独立打开的时候，都分别会对代码中的同一个全局变量进行操作，系统可正常处理；但当功能A和功能B同时打开时，对同一个全局变量的操作未作互斥处理，导致写冲突产生脏数据，进而程序读到非法地址，造成复位。在功能A或B独立打开的正常逻辑描述基础之上，将发生写冲突的异常逻辑细节体现出来，这样就清晰的分析出了现象发生的背后逻辑。

2.3 找到根因
当处理异常的逻辑分析清楚后，根因也基本要浮出水面了，因为根因就隐藏在异常逻辑的细节中。找根因的方法一般有5WHY法、鱼骨图法和头脑风暴法，在异常逻辑已分析清楚的情况下，5WHY是一种比较容易去展开思考的方法。
那上面的例子继续来说，“为什么设备会复位”，原因是“程序读到了非法地址”；“程序为什么会读到了非法地址”，原因是“两个线程对同一全局变量进行非互斥的写操作”；“为什么会有写操作冲突”，原因是“多线程下，未考虑共享数据的互斥操作”，还继续往下问吗？也就是根因到底挖到什么程度就算到位，挖到什么程度就应该停止？既然根因是一步一步问出来的，那有一个较容易的判断是否挖到位的方法，就是当所问的问题已经接近所在团队的常识时，该问题就显得意义不大了，这时就可以认为根因已经挖到位了。比如此例中，“多线程下，为什么要考虑共享数据的互斥操作？”这个问题，已经接近了团队常识，无需再挖了，那么“多线程下，未考虑共享数据的互斥操作”就可作为找到的根因了。到这里就算是找全根因了吗？其实不然，建议让思维再多打开一些。
这里找到的根因是通过现象一步步对系统进行分析而挖掘出来的属于技术根因，还有个与技术维度并列甚至影响力上更大的维度，就是管理维度的根因，管理根因不容忽略和轻视。这个例子中，从管理维度看，根因就是团队研发人员对多线程的理解和运用方法上存在技能盲区，或许是个别人，或许是更多人，但这足以引起管理者的重视和设法应对，避免下一次类似问题的发生。
与技术维度、管理维度的根因并列，还有业务维度的根因。对于业务复杂且存在坏味道的系统中，业务维度的根因也有必要提出来分析和应对。这个例子中，业务根因可以从“为什么需要对多个功能的同时打开，设计多线程的处理方案？”来分析。
总体来讲，寻找根因，需要从技术、管理、业务三个维度做思考和挖掘，以保证全面性；一直挖掘到接近研发团队的常识理解地步，以保证寻找到位。

2.4 制定应对根因的举措
根因清楚了，举措制定就能有的放矢。举措的制定，强调四点：举措是否能完全支撑根因问题的解决；举措不宜太泛化；举措制定要考虑成本；举措项符合SMART原则。

（1）举措是否能完全支撑根因问题的解决
本例中，“多线程下，未考虑共享数据的互斥操作”是技术根因，如果只考虑该问题的发生场景本身，那么就会制定“针对功能A和功能B同时打开的情况下，对全局数据做互斥操作”的举措。这个举措本身可行，但只局限于解决特定场景下的根因问题，所以不能完全支撑根因问题的解决，而应该针对系统中多线程的所有处理点做梳理和排查，而不是针对功能A和功能B同时打开的场景。有一个比较容易校验出，举措和问题不对等的方法，就是反过来验证下根因问题是否会因为有该举措的制定实施而被完全解决。
（2）举措不宜太泛化
太泛化，也即太具有通用性，反而失了针对性和特殊性。太泛化的举措，因为涵盖的范畴宽泛且边界模糊，所以也难以做实际的执行。比如制定了“针对多个功能同时打开时的所有场景，做测试用例的设计”的举措，这个举措极具通用性，但可以预估到，最先应该面对的场景的紧迫性被弱化了，且该举措的执行周期会很长，失去了及时复盘的意义。
（3）举措制定要考虑成本
从精益思想来看，软件质量在越靠前的流程中防护，成本越低，所以有了质量内建的优秀方法。举措的制定也是一样，能在流程前端去防护，就别拖到后续流程中。比如制定了“在系统测试环节，进行多功能同时打开的排列组合自动化测试”的举措，最终大概率也能发现本文列的设备复位问题，但比起在开发环节用功能测试的自动化用例去防护，成本要高很多，且反馈慢很多。
（4）举措项符合SMART原则
制定举措的目的是为了让复盘改进思路得以落地和见效，如果无deadline、执行动作描述太抽象、无明确的验收准则等，那复盘就相当于纸上谈兵。管理大师德鲁克提出的SMART原则是非常好的验证举措项是否合适的原则。本文不专门讨论SMART。

03
—
举措的效果评估

复盘的举措制定后，对于复盘这件事来讲，整个生命周期就结束了。但复盘举措，是否能解决或改善复盘焦点所描述的问题，往往是需要通过举措执行后的效果评估来做判断的。**复盘是一个基于经验、激发深度思考、再结合正确的方法来正向、探索性寻找改进举措的过程，复盘的好坏很难在复盘当时就给出实际的验证效果，更多是从正向来判断经验是否被充分利用、思考是否充分全面、方法是否使用得当，所以，复盘当时，不必着急得到所制定的举措能否有收效的结果。**但等到举措执行完毕后，复盘举措的效果评估，却会通过结果和有指向性的数据，反向地对经验、思考方式和复盘方法起着增强的良性作用。
（完）

作者：沃上清松
公众号：