编程进阶网编程进阶网
  • 基础组成体系
  • 程序编程原理
  • 异常和IO系统
  • 六大设计原则
  • 设计模式导读
  • 创建型设计模式
  • 结构型设计模式
  • 行为型设计模式
  • 设计模式案例
  • 面向对象思想
  • 基础入门
  • 高级进阶
  • JVM虚拟机
  • 数据集合
  • Java面试题
  • C语言入门
  • C综合案例
  • C标准库
  • C语言专栏
  • C++入门
  • C++综合案例
  • C++专栏
  • HTML
  • CSS
  • JavaScript
  • 前端专栏
  • Swift
  • iOS入门
  • 基础入门
  • 开源库解读
  • 性能优化
  • Framework
  • 方案设计
  • 媒体音视频
  • 硬件开发
  • Groovy
  • 常用工具
  • 大厂面试题
  • 综合案例
  • 网络底层
  • Https
  • 网络请求
  • 故障排查
  • 专栏
  • 数组
  • 链表
  • 栈
  • 队列
  • 树
  • 递归
  • 哈希
  • 排序
  • 查找
  • 字符串
  • 其他
  • Bash脚本
  • Linux入门
  • 嵌入式开发
  • 代码规范
  • Markdown
  • 开发理论
  • 开发工具
  • Git管理
  • 百宝箱
  • 开源协议
  • 技术招聘
  • 测试经验
  • 职场提升
  • 技术模版
  • 关于我
  • 目标清单
  • 学习框架
  • 育儿经验
  • 我的专栏
  • 底层能力
  • 读书心得
  • 随笔笔记
  • 职场思考
  • 中华历史
  • 经济学故事
  • 基础组成体系
  • 程序编程原理
  • 异常和IO系统
  • 六大设计原则
  • 设计模式导读
  • 创建型设计模式
  • 结构型设计模式
  • 行为型设计模式
  • 设计模式案例
  • 面向对象思想
  • 基础入门
  • 高级进阶
  • JVM虚拟机
  • 数据集合
  • Java面试题
  • C语言入门
  • C综合案例
  • C标准库
  • C语言专栏
  • C++入门
  • C++综合案例
  • C++专栏
  • HTML
  • CSS
  • JavaScript
  • 前端专栏
  • Swift
  • iOS入门
  • 基础入门
  • 开源库解读
  • 性能优化
  • Framework
  • 方案设计
  • 媒体音视频
  • 硬件开发
  • Groovy
  • 常用工具
  • 大厂面试题
  • 综合案例
  • 网络底层
  • Https
  • 网络请求
  • 故障排查
  • 专栏
  • 数组
  • 链表
  • 栈
  • 队列
  • 树
  • 递归
  • 哈希
  • 排序
  • 查找
  • 字符串
  • 其他
  • Bash脚本
  • Linux入门
  • 嵌入式开发
  • 代码规范
  • Markdown
  • 开发理论
  • 开发工具
  • Git管理
  • 百宝箱
  • 开源协议
  • 技术招聘
  • 测试经验
  • 职场提升
  • 技术模版
  • 关于我
  • 目标清单
  • 学习框架
  • 育儿经验
  • 我的专栏
  • 底层能力
  • 读书心得
  • 随笔笔记
  • 职场思考
  • 中华历史
  • 经济学故事
  • 1.1专栏序言和介绍
  • 1.2需求层次的模型
  • 1.3一起来做个练习
  • 1.4要带上技能地图
  • 1.5经营好自我工作
  • 2.1信息过载怎么办
  • 2.2体系思维很重要
  • 2.3构建知识的体系
  • 2.4结构化思维思考
  • 2.5闭环思维的逻辑
  • 3.1宏观学习的方法
  • 3.2用海绵法找时间
  • 3.3三段分解学什么
  • 3.4学习方法论实践
  • 3.5链式和环式思考
  • 3.6玩和教保证效果
  • 4.1以结果导向计划
  • 4.2目标设立和管理
  • 4.3分解目标要明确
  • 4.4计划的落地策略
  • 4.5结果的检查改进
  • 5.1掌握些做事方法
  • 5.2三种方案设计法
  • 5.3Pdca执行方法
  • 5.4五问根因分析法
  • 5.5五步问题处理法
  • 5.6四维度总结分析
  • 5.7金字塔汇报方法
  • 5.8STAR摸底分析法
  • 5.9阶段复盘方法论
  • 5.10生命线分享游戏
  • 6.1语言底蕴的提升
  • 6.2阅读的持续提升
  • 6.3理解能力的锻炼
  • 6.4沟通能力的演进
  • 6.5演示幻灯片提升
  • 6.6学会高效的提问
  • 6.7公众演讲的提升
  • 6.8做好技术的演讲
  • 7.1职场晋升的规则
  • 7.2提高工作的效率
  • 7.3打工人如何提升

5.9阶段复盘方法论

目录介绍

  • 01.思考为何要复盘
    • 1.1 复盘背景说明
    • 1.2 复盘的来历
    • 1.3 在于降低概率
  • 02.复盘误区和目的
    • 2.1 对复盘的误区
    • 2.2 复盘目的是什么
    • 2.3 复盘相关原则
  • 03.常用复盘法实践
    • 3.1 运用四线复盘法
    • 3.2 四线复盘法操作
    • 3.3 KPT复盘法介绍
  • 04.复盘的模版案例
    • 4.1 事故清晰的描述
    • 4.2 事故影响和回放
    • 4.3 事故的原因分析
    • 4.4 事故的解决方案
    • 4.5 复盘的后续改善
    • 4.6 关于课后的作业

01.思考为何要复盘

1.1 复盘背景说明

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

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

1.2 复盘的来历

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

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

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

1.3 在于降低概率

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

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

02.复盘误区和目的

2.1 对复盘的误区

很多人对复盘有误区:认为“复盘”就等于“我做了什么”,比如:结束了一天的工作,睡前总结今天做了哪些事情?有什么收获?给自己这一天打分。

还有的人认为,终于做完了一个项目,总结会上,大家凭着回忆和直觉,讲一讲在项目中做得好的经验、做得不好的地方,然后把内容整理下来,封存起来,当成对这个项目的复盘。

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

2.2 复盘目的是什么

你可以想一下:复盘的目的是什么。是让自己觉得“我做了很多事情”,从而感到很满足吗?或者,是让自己发现“我做得还不够好”,从而想办法去弥补吗?其实都不是。

复盘的真正目的,是把经验变成自己的养分,把它们吸收,化为己用,让自己比起过去的自己,再多迈出哪怕一步的距离。

也就是说:一天过去了,它其实就已经过去了。你再去纠结它是否充实、是否留有遗憾,其实没有多大意义。

关键的是:你能从中获得什么?永远从过去获得力量,来帮助我们更好地面对未来,这才是复盘的意义。

问题复盘的意义就在于找到问题的原因然后加以改进,避免同样的问题反复出现,降低问题的发生的概率和影响。

2.3 复盘相关原则

事事总结:敬畏错误,原则上,所有线上问题(含pre发现的严重问题),都有必要复盘,形成文档

强调意识:违规操作或者严重的主观意识问题,升格处理;难以规避的技术问题,特别是由于业务快速发展⽽不得不承担的线上⻛险,酌情降级

举⼀反三:凡是犯某个具体错误的,都需要承担⼼梳理上下游类似问题/某个技术点更完整学习,把问题,当成学习机会

03.常用复盘法实践

3.1 运用四线复盘法

问题复盘的内容涵盖事实、分析、定责和改进4个部分,一次成功的问题复盘需要达成以下4个目标。其实看了同事的复盘,流程远比这个多,但是我这里简化了流程,分4步:

  1. 讲清楚事实:讲清楚事情来龙去脉,事实是复盘的基础,如果连事实都没有讲清楚就开始分析、定责和改进,无异于搭建空中楼阁,做得再漂亮也是没有意义的。
  2. 全面且深入地分析:首先需要保证没有遗漏问题,其次需要深入分析问题根因,否则以后问题还是会以其他方式反复出现。
  3. 得出让各方心服口服的定责结论:需要有明确的定责标准,避免拍脑袋定责,或者按照级别和关系来定责。
  4. 制定可以落地的改进措施:避免提出一些虚头巴脑的措施,看起来高大上,实际上却不知道怎么落地,后续也无法跟踪。

四线复盘法,就是通过时间线、问题链、责任链和改进线这4条不同的线索来展开复盘,从而实现事实、分析、定责和改进这4个部分的目标。

3.2 四线复盘法操作

第一条线:时间线

为了讲清楚事实,我们要明确时间线,也就是问题发生的经过,包括问题发现、问题处理过程中采取的各种关键措施、问题恢复的时间和问题影响的结果等。

其中,时间信息非常关键,因为它能够反映出问题发现速度、各项措施执行时间和团队响应效率等指标。

第二条线:问题链

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

第三条线:责任链

为了得出让各方心服口服的定责结论,我们要明确责任链,也就是问题责任人之间的关系。

我们需要结合时间线中问题影响的结果、公司的故障定级标准和问题链的分析,最终确定哪些团队或个人应该承担责任,分别承担多大的责任,接受什么样的处罚。

之所以叫责任链,是因为一个问题的发生往往是整个流程上多个环节相关的人处理有问题,才会导致最终问题的发生。

第四条线:改进线

为了制定可以落地的改进措施,我们要明确改进线,也就是问题的改进计划,包括具体措施、改进责任人和时间节点等。

改进计划的思路来源于两个方面:时间线和问题链,通过时间线找到问题处理过程中不合理和可以优化的地方;通过问题链找到具体需要解决的问题。

具体措施可以是流程上的调整(增加或删除流程步骤),技术上的手段(增加功能、优化系统)和团队方面的措施(学习、培训、奖惩机制)等。

可以落地是非常重要的,不要说的很虚,我举个例子。后期要更加认真,后期写代码更细心,这种说法说了跟没说,你听听,感觉有道理,但觉得很空,对不对。比如后期写代码,小杨会和之前代码对比,罗列case,自测,并且同事代码review,这种比说写代码更细心是不是更具体还可落地。

3.3 KPT复盘法介绍

KPT 复盘法,与其说是一个方法,不如说是一个原则。它的用法就是,在复盘的时候,问自己三个问题。

Keep/ 保持:哪些行为是可以保持的?Problem/ 问题:在过程中遇到了哪些问题?Try/ 尝试:我可以尝试去做些什么?

你会发现,单纯把这些东西记下来,其实意义不大,你要真的落到实处才有用。比如:Try 的部分,就可以跟“行动卡片”结合起来,用行动卡片把“尝试”落实、具体化;Problem 的部分,就可以通过主题汇总和模板,整理成一张核对清单。

下一次行动时,对着打钩,可以帮助自己减少思考成本;Keep 的部分,可以考虑归纳出方法论,无论是指导自己的实践还是传授给别人,都非常有用。

04.复盘的模版案例

4.1 事故清晰的描述

⼀件事情做完后⽆论成功与否,坐下来把当时预先的想法、中间出现的问题、为什么没达成⽬标等因素整理⼀遍,在下次做同样的事时,⾃然就能吸取上次的经验教训。这就是复盘。

复盘不是⽤于追责,⽽是为了发现和解决问题、积累经验、优化流程,避免再次出现同样问题。

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

4.2 事故影响和回放

事故的影响数据

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

事故回放的记录

  1. 事故时间线不要漏了关键节点,处理⼈、采取对应的⾏动和原因。
  2. 时间线需要完整,包含事前、事中、事后的动作。

初期到末期的过程是怎么样的?过程之中大致可以分为几个阶段,每一个阶段都发生了什么?我们是如何应对的?

4.3 事故的原因分析

  1. 直接原因,是直接导致事故发⽣的原因,常⻅的是代码逻辑问题、分⽀合并、并发等。
  2. 深层原因,是挖掘为什么会出现这个事情深层次原因,也要从事前、事中、事后⻆度分析。

挖掘的⽅法可以在原有问题上在问为什么,⽐如为什么事故持续时间这么⻓?为什么代码逻辑有问题?为什么这个问题没有被发现。

深层原因才是我们要复盘解决的问题,能够避免相同问题再出现。

4.4 事故的解决方案

止损方案:详细描述止损方案

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

4.5 复盘的后续改善

改善措施⼀定要写切实可落地的,和原因分析得出的结论要相对应,并且要有完成时间和跟进⼈。

复盘,最重要的目的和输出结果都是:规律总结。

这种规律包括两个方面,一个是认知方面,通过复盘,我们对于思考问题以及解决问题的方法有哪些心得?对于某些事物的认知有哪些心得?如果能够总结出普遍使用的规律性的东西,是对我们认知的一个提升。

另一个方面是实践方面,如果历史重演,假如再次遇到类似的项目,我们应该如何做?如果总结出规律,未来在类似的事情上我们一定可以做得好,这就是我们说的吃一堑长一智甚至吃一堑长三智。

4.6 关于课后的作业

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

贡献者: yangchong211
上一篇
5.8STAR摸底分析法
下一篇
5.10生命线分享游戏