你好,我是郭东白。从这节课开始,我们就进入到架构活动的最后一个环节:复盘。

当遍历完价值单元的交付树之后,其实也就完成了整个架构活动的交付。到这里,比较普遍的方式是业务方最终验收并庆祝上线。这是个传统的由项目经理主导的步骤,相信你肯定经历过不少,我在这里就不赘述了。

与此同时,大多数产品和研发人员已经进入了一个甚至多个项目,也开始了新一轮的紧张迭代。很多团队主管甚至也以自己团队在连轴加班而生出一种自豪之感。

但作为架构师,我们或许要像卢瑟福一样发问:“如果不停地加班,那你什么时候思考呢?” 是的,当经历了一个充满不确定性、信息不对称、高度紧张的架构项目,我们不能没有一个深度思考的过程。这个过程就是复盘。

复盘是最容易被忽略的环节,但对于架构师和整个团队的成长来说,却有着极其关键的作用。所以在这节课,我会拆解复盘整个环节,确保你跟所有参与者的成长都能最大化。甚至,还可以通过复盘挖掘到更多的架构机会,为未来同类的架构活动沉淀更好的工具。

不过在描述复盘的完整过程之前,我们先要对复盘的定义有个统一的认知。

复盘的目的

需要预先说明的是,我们这两节课要讲的复盘,特指通过还原并深度思考架构活动的完整历程,来寻找可以提升未来架构活动成功概率的过程。

在互联网时代,复盘这个词已经被滥用了,以至于很多人将复盘与总结反思画上了等号。因此我有必要再针对复盘的定义进行详细解释,帮助你更全面地认识复盘。

首先是复盘的目的。我们在复盘的定义中已经给出了,即:寻找可以提升未来架构活动成功概率的机会。大多数复盘其实都偏离了这个目标。在我参与的上百次的复盘中,我也很少见过参与者自始至终都能忠于这个目标的。

我们可以用一个公式来表示,也就是 P(E) < P(E|A) 。其中,E 指的是公司未来某个架构活动,A 指的是复盘分析。这个定义的意思就是,通过复盘分析,公司未来的架构活动的成功概率必然能得到提升。

其次是复盘的对象。复盘的对象不仅包括失败案例,还包含成功案例。我们通常对成功案例有着较为主动的学习动机,也就是我们经常提到的路径依赖。而对于失败案例,我们却常常有着自我治愈和选择性遗忘的倾向。

事实上,企业中的架构尝试大多数都是以失败告终的,所以从失败案例中学习的机会其实更为频繁,而且对我们未来避免失败也至关重要。我甚至觉得很多人的成功就是来自对失败案例的高效学习。

最后是复盘的视角。复盘可以有多个视角:一种是对他人的审视;一种是对自我的审视;还有一种是上帝的视角。

上帝视角实施起来会比较困难,有点像历史学家对某个历史事件的审视,需要穷尽信息的收集。在互联网企业,我们不太具备这种严苛的信息收集的条件和所需时间。不过,我们可以通过协调所有参与者来最大化前两种视角,在最大程度上逼近上帝视角。

要怎么理解前两个视角呢?

  • 对他人的审视,简单来说就是一句话:谁造成了我的失败?

  • 对自我的审视,简单来说也是一句话:我什么地方做得不完美?

除了不同视角的分析外,复盘还需要从不同的维度进行分析,比如决策逻辑层面、执行层面、组织和文化层面等。

一个项目的失败,尤其是灾难性的失败,基本上都是多个维度的因素叠加造成的。如果团队在某个维度上的能力做到了极致,往往可以弥补其他维度上能力的不足。

举个很简单的例子,假设一家公司的研发人员压力大、交付周期短,自动化测试覆盖率也不够高,导致项目发布经常带有故障。如果这家公司在灰度发布、指标监控和自动化回滚等方面做到了极致,那么即便有故障,但靠着发现及时、报警响应快、能做到一键回滚,也能保障项目发布的稳定性。

复盘的三大误区

明确了复盘的定义之后,会发现,你之前所做的大多数复盘其实都走进了误区。我把这些误区归类成三种。

第一个最常见的误区是止于问责。在一个重大问题出现后,很多公司的做法都是先在公司内部找到第一责任人,然后对责任人处以与失败相同量级的处罚,甚至开除。这种机制的目的是防止复盘参与者互相包庇,最后大事化小、小事化了。

问责机制的确可以用在复盘环节中,来帮助公司发现问题的真正根因。不过也要明白,找到或惩罚责任人并不是复盘的目标,也不应该是复盘的终点。复盘的目标是寻找可以提升未来架构活动成功概率的机会点。

从这个视角出发,问责制的一些缺陷就会暴露无遗:

  • 偏离目标:不少互联网企业会将很大比例的薪酬放在绩效激励上,而维持问责制的有效性,意味着它会与激励相挂钩。那么让其他参与者知道自己的问题,很可能会带来不小的经济损失。此外,还会导致复盘时将大量的时间耗费在问责过程中,甚至就是在讨论“谁的责任更大一些”这个问题。而未来如何改进这个更重要的问题,很容易被大家所忽视。

  • 遗留隐患:项目失败后,公司的损失已经是既成事实,靠惩罚一两个责任人并不能挽回什么损失。此外,即使问责处罚完,公司或系统的隐患依然不会消除。反倒因为把责任归属到一两个主要的责任人身上,导致其他人身上所存在的隐患被完全忽视。在崇尚问责制的公司里,你肯定能观察到这样的现象:复盘会上只有一两个人争论得不可开交,其他人都噤若寒蝉,生怕把自己牵扯进来。

  • 人才流失:高风险的项目本来就容易失败。一旦斩了先锋,可能再也没人敢为这种项目担责冒险了,望而却步会成为项目参与者的默认选项。

在我看来,失败是一个公司必须要付出的学费。不失败,反倒是公司在行事上过于保守的侧面证明,也会对参与者的冒险精神有所压制。对于一个公司来说,最重要的是从失败中获取能力的提升。

第二个常见的误区就是止于意识提升。在复盘的过程中,肯定会涉及到自我剖析,让参与者寻找各自的提升点。但是项目复盘,更重要的是整个公司的能力提升,而不是参与者个人能力的提升。

这两者的区别在于,个人能力的提升并没有固化到团队或公司中。比如某个参与者离职,对公司来说,就失去了一项能力。要知道,无论是你个人的能力,还是其他人的能力,都属于公司组织能力提升的一部分。但是除了员工能力的提升外,公司其他维度的提升也同样重要,比如系统提升、机制提升、文化提升等。

这里还要插一句。哪怕光做到意识上的提升,其实也非常难。出于对自我的保护和对自尊心的维护,难免会让你放弃反思或者反思不够彻底。所以真正的意识提升,需要参与者都能保持正确的心态。什么是正确的心态呢?我引用印度禅师 Sri Yukteswar 的一句话:“只有靠粗暴的意志才能击碎坚硬的自我 (The hardcore of human egotism is hardly to be dislodged except rudely)。”

第三个误区是止于错误补救。更准确地说,就是止于损失回捞,也就是在最大程度上挽回问题所造成的损失。这是针对已经接近完成的架构活动的补充,是个收尾动作,并不能对未来的架构活动形成任何助力。

通过这三个误区的分析,我想你对我们为什么要做复盘这件事已经有了较为清晰的认知。简单总结一下,复盘的王道就是通过对失败事件的深度剖析,从中寻找一些机会点,从而提升企业未来的架构活动的成功概率。

进入复盘前的准备工作

还是老规矩,在进入复盘环节之前,我们需要做一些准备工作:

  • 建设复盘氛围:为参与者提供一个安全且平衡的复盘环境。

  • 梳理错失的机会点:从公司层面的宏观视角看,错失的最可惜的机会点是什么?提前梳理重大机会点,可以帮助我们控制复盘节奏,避免复盘成为一个裸心会,被一个麦霸引导到他个人的心灵独白中去。

  • 设定目标:引导参会者对复盘目标有个清晰的认知。如果不能拿到一个非常有洞察的、能真正提升未来成功概率的结论和行动点,那么复盘就不能结束。

在这些准备工作中,有两个地方需要格外关注。

第一个是安全的复盘环境。在法则六中我们就拆解过这个话题。如果企业对失败或错误的容忍度极低,那么我们这两节课分享的复盘方法就很难执行到位。

建设安全的复盘环境的具体方式,可以参照我们在搭建架构环境这节课中提供的方法。 这里就不再重复了。接下来我要特别讲一下,应该如何应对国内互联网企业中常见的问责制。

我们刚才提到,问责机制是比较霸道的做法,可能会导致参与者丧失安全感,互相指责,甚至互相包庇,隐瞒事实。如果公司原本就有问责机制,那我们架构师往往也改变不了这个大环境。

但有个折中的办法,就是把你这个架构师主持的架构活动复盘,与官方正式的架构活动问题复盘隔离。架构活动复盘可以放在问题复盘之后,而且最好在公司外的非正式场所中举行,效果会更好。

如果公司的问责机制比较严苛,那么你主持的这个复盘,无论是定位还是时间,都要跟官方问责机制下的问题复盘完全隔离开。一个行之有效的建议是,把你主持的复盘定位成非官方的共创会,安排在问责会结束一两周之后,邀请参与者对架构活动做出思考,对未来提出有建设性的建议。

另一个是平衡的复盘环境,包含四层含义。第一层是视角的平衡,也就是平衡对他人的审视和对自我的审视。对他人审视和对自我审视其实是一对矛盾,当我们在一个视角上的思考做到极致后,难免忽略另一个视角。很简单的例子,如果我们从他人身上找到了能解释自己失败的充分原因,那我们很难正视自己的失败。反之亦然。

第二层是平衡公司内部不同的决策层。这是对“刑不上大夫”的问责制度的挑战,也就是问责问到屋子里层级最高的人的时候,就戛然而止。同样,这么做也是为了把决策层面和执行层面的问题分开来看,寻找各自的机会。

第三层是平衡不同的维度。技术人员做复盘的时候,话题往往是如何改变设计、如何完善监控发现工具、如何提升工程效率,以及如何提升数字化决策的质量。从公司层面看,通过其他手段也可以达到同样的目标,技术手段只是其中一种。因而在复盘中,需要引导参与者注意平衡思考的维度。

第四层是平衡思考深度和行动时间。很多人做复盘,还没完成全面分析呢,就已经列出了一大串行动点,准备整治了。要知道,复盘不是故障响应,不需要立即止血。复盘的重点在于追寻问题本质,而不是整治现象。

那么下节课,我们就来讲讲在复盘这个节点上该如何行王道,以深度探索来提升公司未来架构活动的成功概率。

小结

架构活动的复盘,是你跟其他参与者深度学习的好时机。这是一个集体思考的过程,不是我们日常的习惯性行为。所以必须通过一系列的方式方法,来确保这个思考过程能够最大化未来架构活动的成功概率。

我认为这种方法的成功关键,就是让所有复盘参与者都能清楚地知道复盘的目标,也就是如何更好地迎接未来。 “所有过往,皆是序章(What’s past is prologue)。”这句话放在互联网这个高速迭代的行业里,是再恰当不过了。

因此我们这节课花了很大的篇幅在强调复盘的误区:止于问责、止于意识提升和止于错误补救。如何避免这三个误区呢?答案就是提供安全和平衡的复盘环境。下节课,我会继续介绍怎么利用好这个复盘环境,来深度探索架构活动中可能的机会点。

思考题

这节课有三个思考题,建议选择比较有感触的一道来回答。

  • 你参与过的对公司产生最大价值的复盘是什么?这个价值是怎么被发现的?你认为这种发现方式可以被复用吗?为什么?

  • 你参与过的最好的复盘氛围是什么样的?为什么觉得这个氛围好呢?这个氛围是如何搭建的呢?

  • 在复盘的过程中,参与者或多或少会有些难以逾越的心理障碍。你有没有什么好的应对办法呢?

【郭东白架构课 模块二:创造价值】32|节点七:什么是有价值的复盘?相关推荐

  1. 【郭东白架构课 模块二:创造价值】17|通用技能(下):架构师如何保障交付与沉淀知识?

    你好,我是郭东白.架构师在架构活动中主要有四个作用,分别是建设共识.控制风险.保障交付和沉淀知识.上节课我们讲了前两个,这节课就来讲保障交付和沉淀知识这两个. 保障交付 保障交付意味着架构师能够降低大 ...

  2. 【郭东白架构课 模块一:生存法则】05|法则二:研发人员的人性需求是如何影响架构活动成败的?

    你好,我是郭东白.上节课我们学习了马斯洛关于人性的理论,那么这节课我们就利用这个理论来看看我们在架构活动中应该注意些什么. 架构设计必须符合人性,而在架构活动中,与"人"相关的主要 ...

  3. 【郭东白架构课 模块一:生存法则】02|法则一:为什么有些架构活动会没有正确的目标?

    你好,我是郭东白.今天这节课,我们就正式开始架构师生存法则的学习. 你肯定看到过这样的观点:架构设计就是一个迭代的过程,我们要不断发现并且补偿现阶段软件设计的不完美,然后通过各种手段打补丁升级.因此, ...

  4. 【郭东白架构课 模块一:生存法则】10|法则四:架构设计中怎么判断和利用技术趋势?

    你好,我是郭东白. 上节课我们讲了为什么要顺应技术的生命周期.但是"往者不可谏,来者犹可追",我们就不能抓住一个技术萌芽和发展的机会吗?今天我们就来探讨一下这个问题. 技术未来的趋 ...

  5. 【郭东白架构课 开篇词】开篇词|没有战略意图,就成不了一个顶尖的架构师

    你好,我是郭东白,是一个做了 15 年架构师和 6 年 CTO 的人. 我先简单介绍一下自己.我从布朗大学(Brown University)获得博士学位后,在美国甲骨文.微软和亚马逊陆续工作了 15 ...

  6. 简七32堂极简理财课——模块二:理财规划,让你不再走弯路

    文章目录 六.理财第一步 1.理财规划 2.规划理财"五步走" 3.制定规划 根据生命周期制定目标 根据SMART原则设定目标 七.认真点清财富 1.培养财富亲密度,增强对钱的掌控 ...

  7. 郭东白:《从中台技术谈架构师的独立思考能力》

    文章摘自与数据同行     作者:郭东白 个人读后总结了其中提到的主要观点,供大家参考: 1.中台是个完全正确的方向: 2.中台的挑战:(1)创新的遏制:有说法说,一个业务靠拖中台的拉拽就能编排出来了 ...

  8. b2c项目基础架构分析(二)前端框架 以及补漏的第一篇名词解释

    b2c项目基础架构分析(二)前端框架 以及补漏的第一篇名词解释 继续上篇,上篇里忘记了也很重要的前端部分,今天的网站基本上是以一个启示页,然后少量的整页切换,大量的浏览器后台调用web服务局部.动态更 ...

  9. 【Unity学习笔记】b站Unity架构课Unity3D 商业化的网络游戏架构(高级/主程级别)

    [Unity学习笔记]b站Unity架构课Unity3D 商业化的网络游戏架构(高级/主程级别) 自己跟着学完了,写了不少代码,会放在CSDN代码库,因为老师并没有提供源码,录屏也不是完全连续,所以难 ...

最新文章

  1. cisco交换机Telnet配置
  2. ios中常用数据类型相互转换
  3. python基础单词-学Python必背的初级单词,快来看看学吧
  4. dNet项目数据访问层代码总结
  5. 项目编译后,classses文件中没有对应的xml文件,一般是编译后mapper类对应的xml文件没有生成
  6. 【BZOJ】4001: [TJOI2015]概率论
  7. python 分离整数与小数_Python编程:离不开算术运算符的顺序结构
  8. 非线性回归模型(part2)--支持向量机
  9. L1-040 最佳情侣身高差 (10 分)—团体程序设计天梯赛
  10. 启明星系统使用在线视频教程
  11. 20210311 plecs to file 功能
  12. 如何制定软件项目进度表
  13. android 国际电话区号,中国国际区号_电话区号_中国区号是多少-中国区号查询
  14. 上海高中开设计算机课,如何提升高中计算机课的趣味性
  15. 猫咪藏在哪个房间python作业_猫咪生气躲进房间,众人找到后,猫咪一脸疑问:听说你们在找我...
  16. java打包把依赖也打进去_maven打包时把依赖的jar包打进去
  17. 力士乐触摸屏维修VCP20.2DUN-003-PB-NN-PW
  18. centos7安装mysql(mysql-5.7.23-1.el7.x86_64.rpm-bundle.tar)
  19. 展讯7715 Android 平台编译
  20. 什么品牌的护眼台灯比较好?护眼效果最好的台灯推荐

热门文章

  1. 数字图像处理系列(一)---绪论
  2. CPU mask机制变化
  3. 数字化城市道路建设系统构架
  4. 企业邮箱要收费吗?企业邮箱为什么要收费?
  5. springboot+微信小程序老年人健康保障管理系统毕业设计源码302303
  6. 张云皓计算机,2014年华北五、自治区和港澳台大学生计算机应用大.PDF
  7. 三翼鸟“场景定制”是海尔智家的未来吗?
  8. ubuntu16更改grub系统进入Memtest86解决方法
  9. 【SIG月报】10月openKylin社区SIG组最新进展分享!
  10. 验证过的ULN2003驱动继电器电路