5.9阶段复盘方法论

目录介绍

01.思考为何要复盘
02.对复盘存在误区
03.复盘目的是什么
04.运用四线复盘法
05.四线复盘法操作
06.需记录工作日志
07.事后需要去反思
08.实践总结出经验
09.复盘的模版案例
10.复盘的相关原则
11.关于课后的作业

01.思考为何要复盘

1.1 复盘背景说明

为何要复盘，什么场景下需要复盘？带着这个问题，自己想着梳理一下复盘的总结。

解决问题的思路不够全面，需要对自己进行复盘，主要是为了掌握解决事情的来龙去脉。
遭遇到了需求bug，需要对自己进行复盘，主要是为了分析问题的出现场景和后期如何避免的行动方案。
OKR目标没有达到，需要对自己进行复盘，主要是思考下年度的工作产能以及自身存在的问题。
生活中遇到了某个困难，也可以对自己进行复盘，事前，事中，事后，自己都是怎么处理的，保持精进。

1.2 复盘的来历

在事后总结阶段，正常情况下我们主要是做收获总结和成果汇报即可，但是如果发生了明显的问题，就需要做问题复盘。

复盘是一个围棋术语，它指的是对局结束后回顾记录，检查招法的优劣和得失关键，并且根据分析提出更好的招法，提升以后的对局能力。

后来，这个思路被引入到了管理工作中。小杨觉得围棋中的复盘，其实可以应用于生活中的方方面面。

1.3 在于降低概率

技术人员主要参与的是线上问题复盘，比如业务或者系统出现了线上问题，在问题解决之后往往就会组织复盘。

虽然无论做什么都不可能完全杜绝问题的发生，但这并不意味着我们只能坐以待毙。我们需要尽量降低问题发生的概率，减少问题导致的损失，因为就算事故不可避免，举个例子1年发生3次和1年发生1次，影响和意义也是完全不同的。

02.对复盘存在误区

很多人对复盘有误区：认为“复盘”就等于“我做了什么”，比如：结束了一天的工作，睡前总结今天做了哪些事情？有什么收获？给自己这一天打分。终于做完了一个项目，总结会上，大家凭着回忆和直觉，讲一讲在项目中做得好的经验、做得不好的地方，然后把内容整理下来，封存起来，当成对这个项目的复盘。

这也许是很多人习惯的模式。这种模式有用吗？有。但如果只停留在这样的程度，是远远不够的，复盘目标就是以后做的更好而非流水账。

03.复盘目的是什么

你可以想一下：复盘的目的是什么。是让自己觉得“我做了很多事情”，从而感到很满足吗？或者，是让自己发现“我做得还不够好”，从而想办法去弥补吗？其实都不是。
复盘的真正目的，是把经验变成自己的养分，把它们吸收，化为己用，让自己比起过去的自己，再多迈出哪怕一步的距离。
也就是说：一天过去了，它其实就已经过去了。你再去纠结它是否充实、是否留有遗憾，其实没有多大意义。关键的是：你能从中获得什么？永远从过去获得力量，来帮助我们更好地面对未来，这才是复盘的意义。
问题复盘的意义就在于找到问题的原因然后加以改进，避免同样的问题反复出现，降低问题的发生的概率和影响。

04.运用四线复盘法

问题复盘的内容涵盖事实、分析、定责和改进4个部分，一次成功的问题复盘需要达成以下4个目标。其实看了同事的复盘，流程远比这个多，但是我这里简化了流程，分4步：
讲清楚事实：事实是复盘的基础，如果连事实都没有讲清楚就开始分析、定责和改进，无异于搭建空中楼阁，做得再漂亮也是没有意义的。
全面且深入地分析：首先需要保证没有遗漏问题，其次需要深入分析问题根因，否则以后问题还是会以其他方式反复出现。
得出让各方心服口服的定责结论：需要有明确的定责标准，避免拍脑袋定责，或者按照级别和关系来定责。
制定可以落地的改进措施：避免提出一些虚头巴脑的措施，看起来高大上，实际上却不知道怎么落地，后续也无法跟踪。
四线复盘法，就是通过时间线、问题链、责任链和改进线这4条不同的线索来展开复盘，从而实现事实、分析、定责和改进这4个部分的目标。

05.四线复盘法操作

5.1 第一条线：时间线

为了讲清楚事实，我们要明确时间线，也就是问题发生的经过，包括问题发现、问题处理过程中采取的各种关键措施、问题恢复的时间和问题影响的结果等。
其中，时间信息非常关键，因为它能够反映出问题发现速度、各项措施执行时间和团队响应效率等指标。

5.2 第二条线：问题链

为了全面且深入的分析，我们要明确问题链，也就是问题的传导路径。通常情况下，一个问题往往不是单一原因导致的，而是多个原因“碰巧”组合在一起所导致的，所以分析整个问题的传导路径，才能全面地了解产生问题的过程。

5.3 第三条线：责任链

为了得出让各方心服口服的定责结论，我们要明确责任链，也就是问题责任人之间的关系。我们需要结合时间线中问题影响的结果、公司的故障定级标准和问题链的分析，最终确定哪些团队或个人应该承担责任，分别承担多大的责任，接受什么样的处罚。
之所以叫责任链，是因为一个问题的发生往往是整个流程上多个环节相关的人处理有问题，才会导致最终问题的发生。

5.4 第四条线：改进线

为了制定可以落地的改进措施，我们要明确改进线，也就是问题的改进计划，包括具体措施、改进责任人和时间节点等。
改进计划的思路来源于两个方面：时间线和问题链，通过时间线找到问题处理过程中不合理和可以优化的地方；通过问题链找到具体需要解决的问题。
具体措施可以是流程上的调整（增加或删除流程步骤），技术上的手段（增加功能、优化系统）和团队方面的措施（学习、培训、奖惩机制）等。
可以落地是非常重要的，不要说的很虚，我举个例子。后期要更加认真，后期写代码更细心，这种说法说了跟没说，你听听，感觉有道理，但觉得很空，对不对。比如后期写代码，小杨会和之前代码对比，罗列case，自测，并且同事代码review，这种比说写代码更细心是不是更具体还可落地。

06.需记录工作日志

很多人不理解记录的重要性，把记录简单理解为做“工作日志”和“每日总结”，这其实是没有意义的。而是要记录“一切对未来可能有用的信息”，这些信息，可能是你面临的问题，可能是你采取的解决方式，可能是你产生的想法，可能是你作出判断和思考的逻辑等等。
第一时间把这些信息记录下来，先不用管格式，等有空的时候，再去加工和处理。后期在不断完善。

07.事后需要去反思

可以按照以下这 4 个维度来思考，对应“监测循环”中的 4 个部分：

7.1 目标重合度

关注这件事情本身，去思考：这件事情的意义和价值有多大？它跟我的短期目标和长期目标重合度有多高？我是否要调整对它投入的时间和精力？这可以帮你始终紧扣“我要做”，而不是迷失在“要我做”之中。
这也是很多人常犯的毛病。难以拒绝，难以舍弃，反复奔走在那些不重要的琐事和事务里面，却遗漏了对自己来说真正有价值和意义的事情。

7.2 优化的空间

着眼于自己记录下来的行动，然后去思考：在这些行动中，哪些环节还可以再提高效率？哪些行为我做得不够好，存在优化的可能性？
举个例子，比如我维护GitHub开源项目，先实现功能，然后思考代码是否可以精简，然后怎么优化性能，然后如何监控埋点，这些是持续不断优化的结果。
哪些步骤可以整合、省略、调整，能更好地满足我的需求？这其实是一个“迭代”的过程，迭代真的很重要。先做，再去完善。没有什么事情是一蹴而就的。先做到“好”，再努力去做到“更好”，最终让它无限接近于自己心中的“最好”。

7.3 问题和想法

主要是针对工作中产生的碎片想法，把它们收集起来，再汇总到一起。我们在生活、工作中，总是不断地遇到问题、解决问题，但如果不及时把这些收获记录下来，它们就会快速消失。
那么下一次，当我们又遇到类似的问题时，我们就难以立刻调用自己的经验，这岂不是非常可惜？
记录、汇总、复习，实际上就是一个不断强化自己经验的过程。也就是说，把那些“可能会用到”的信息储存在我们的“第二大脑”里面，等到需要时再去调用。

7.4 方法论迁移

这部分实质上是整合以上三个部分，去思考：在这个任务中，有没有哪些东西，是我可以提炼出来、总结成方法论，迁移到别的地方的？
其实关于方法论，我觉得还有点抽象，怎么具体呢。比如你能否把技术总结，反馈复盘，大家写的是否有相似之处，能否去建立模版，一开始不要想的太完整，不断完善，能否复用和迁移，这样就比较具体可实践呢。

08.实践总结出经验

8.0 复盘要用起来

当你通过记录和反思，对自己的工作和项目进行复盘之后，一定要记得把这些成果“用起来”。
也就是说：当你面临新的挑战和难题时，尽可能摆脱路径依赖，不要完全照搬以前的做法，而是想一想：我能否尝试一些“不同”的做法？只有这样，你才能够真正把从过去总结提炼的东西，变成自己成长的养料。

8.1 汇总碎片想法

一个记录“每日生活”的笔记本，我用有道云，主要记录每一天做了什么，以及在做这些事情的过程中产生的一切想法。
那么，问题来了：这些碎片想法，会散落在每一天的记录中，不方便查找和纵览，怎么样才能汇总起来呢？这就需要用思维导图或者流程图，来对它们进行归纳。

8.2 实验行动卡片

在工作中，经常会产生这样的想法：这个做法不够好，是否可以尝试另一种做法？这个想法会被我记录下来，但我不会这样就算了，而是安排一段时间，来尝试这个做法，看它是否能起到更好的效果。
这时，我会在笔记软件里另起一页，做一张“行动卡片”，来记录我尝试这个做法的行为和反馈。“行动卡片”的本质，就是通过复盘，把一个想法转化为项目，并继续重复“记录、反思、实践”，让这个想法真正落地生根，帮助自己优化行为模式，让自己不断地“做到更好”。

8.3 设计流程模板

一个简单粗暴的习惯：一件事情，如果我要做第二遍、第三遍，那我就会去思考：我能否把它做成一个模板，当后面需要时直接套用？
好的工作，一定是这样的，通过“记录”把一整套流程、步骤明确下来，再通过“反思”把它固化成流程、模板，最后在“实践”时，直接套用模板，再根据实际情况微调或补充即可。然后，在应用模板的时候，再不断去优化它、完善它、迭代它。不断把需要动脑思考的事情，转化为“自动化加工”，腾出脑力和时间去思考更重要的事情，这才是一个可持续的模式。

8.4 KPT复盘法

KPT 复盘法，与其说是一个方法，不如说是一个原则。它的用法就是，在复盘的时候，问自己三个问题：Keep/ 保持：哪些行为是可以保持的？Problem/ 问题：在过程中遇到了哪些问题？Try/ 尝试：我可以尝试去做些什么？
你会发现，单纯把这些东西记下来，其实意义不大，你要真的落到实处才有用。比如：Try 的部分，就可以跟“行动卡片”结合起来，用行动卡片把“尝试”落实、具体化；Problem 的部分，就可以通过主题汇总和模板，整理成一张核对清单。
下一次行动时，对着打钩，可以帮助自己减少思考成本；Keep 的部分，可以考虑归纳出方法论，无论是指导自己的实践还是传授给别人，都非常有用。

09.复盘的模版案例

这一年在滴滴，对自己技术前进，还有思维上的提升，是很大的。尤其是复盘的意识，多次对自己进行复盘，然后改进，这种思维潜移默化了改变了一些做事的方式和风格，讲究逻辑。

9.1 为什么需要复盘

⼀件事情做完后⽆论成功与否，坐下来把当时预先的想法、中间出现的问题、为什么没达成⽬标等因素整理⼀遍，在下次做同样的事时，⾃然就能吸取上次的经验教训。这就是复盘。
复盘不是⽤于追责，⽽是为了发现和解决问题、积累经验、优化流程，避免再次出现同样问题。

9.2 事故清晰的描述

对事故的具体表现表述清楚，⽐如正常情况下逻辑是什么，出现问题后表现是什么，可以⽤截图⽅式说明。

9.3 事故的影响数据

1.数据⼝径要准确，要说明影响数据的计算公式。
2.定级是根据受影响功能使用量、受影响⽤户数、资损三个维度来定级，若事故对这三个维度都有影响，那需要把相关数据都统计，以影响最⼤的纬度定级。

9.4 事故回放的记录

1.事故时间线不要漏了关键节点，处理⼈、采取对应的⾏动和原因。
2.时间线需要完整，包含事前、事中、事后的动作。
初期到末期的过程是怎么样的？过程之中大致可以分为几个阶段，每一个阶段都发生了什么？我们是如何应对的？

9.5 事故的原因分析

1.直接原因，是直接导致事故发⽣的原因，常⻅的是代码逻辑问题、分⽀合并、并发等。
2.深层原因，是挖掘为什么会出现这个事情深层次原因，也要从事前、事中、事后⻆度分析。
挖掘的⽅法可以在原有问题上在问为什么，⽐如为什么事故持续时间这么⻓？为什么代码逻辑有问题？为什么这个问题没有被发现。
深层原因才是我们要复盘解决的问题，能够避免相同问题再出现。

9.6 事故的解决方案

止损方案：详细描述止损方案
解决方案：详细描述解决方案，决定什么时候解决。要有一个把控进度的能力。

9.7 复盘的后续改善

改善措施⼀定要写切实可落地的，和原因分析得出的结论要相对应，并且要有完成时间和跟进⼈。
复盘，最重要的目的和输出结果都是：规律总结。
这种规律包括两个方面，一个是认知方面，通过复盘，我们对于思考问题以及解决问题的方法有哪些心得？对于某些事物的认知有哪些心得？如果能够总结出普遍使用的规律性的东西，是对我们认知的一个提升。
另一个方面是实践方面，如果历史重演，假如再次遇到类似的项目，我们应该如何做？如果总结出规律，未来在类似的事情上我们一定可以做得好，这就是我们说的吃一堑长一智甚至吃一堑长三智。

10.复盘的相关原则

事事总结：敬畏错误，原则上，所有线上问题（含pre发现的严重问题），都有必要复盘，形成wiki
强调意识：违规线上操作或者严重的主观意识问题，升格处理；难以规避的技术问题，特别是由于业务快速发展⽽不得不承担的线上⻛险，酌情降级
流程和技术设计：流程+技术设计类问题，重点关注：遇到基础库导致的线上bug、设计或沟通不到位、代码合并、常犯模块（>2次）、其他明显质量意识或机制，导致的线上问题/测试暴露被投诉的案例
举⼀反三：凡是犯某个具体错误的，都需要承担⼼梳理上下游类似问题/某个技术点更完整学习，进⾏组⾥分享的责任；把问题，当成学习机会

11.关于课后的作业

你生活中是如何进行复盘的。针对复盘的提升，你有什么好的点子。如果有，分享给我小杨。

参考博客

https://time.geekbang.org/column/article/284832