首页 > 其他分享 >郭东白的架构课34

郭东白的架构课34

时间:2022-12-29 11:46:20浏览次数:47  
标签:视角 跟进 郭东白 机会 维度 架构 34 复盘

你好,我是郭东白。上节课我们讲了复盘的目的,还讲了复盘的三个误区。同时,也讲了进入复盘前的准备工作。有了这些做基础,这节课我们就正式进入到复盘的过程中。

复盘过程一般由如下六个环节组成:

  1. 回顾架构活动;
  2. 搭建复盘环境;
  3. 梳理机会点;
  4. 挖掘根因;
  5. 寻找新的模式与机制;
  6. 产出跟进项。

回顾架构活动

回顾过程指的是以时间顺序对事实进行多维度的客观描述,包括主要决策的环境、最终的决策,以及由此推演而来的规划。

在架构活动的进行过程中,如果你一直遵循我们提到的沉淀知识的建议。那么在这个环节,就不需要做太多的准备工作,只把线上文档中记录的重要决策和相关背景提炼出来即可。

唯一需要注意的是,除了架构师视角的回顾外,你还需要从非技术职能的视角出发,对架构活动进行回顾。

这些非技术职能的视角包括项目经理、产品经理、业务、运营,甚至还包括客户。这个补充动作非常重要。因为架构活动耗时较久,在复盘时回顾内容往往会引导大家的讨论走向。如果你能提供充分的视角,并为每个视角分配合理的权重,将会大幅拓宽机会洞察的搜索半径,找到更高质量的提升点。

过程控制和整体规划

上节课我们提到复盘的一个重要原则是保持平衡的视角。想做到这一点,首先要邀请一组具备不同视角的参与者来参加复盘。不能清一色地邀请研发人员,因为研发人员往往只会从技术视角出发来做深度探讨。

邀请一组正确的人参加复盘时,作为架构师,你需要对复盘的氛围和内容持续做引导与控制,尤其要确保每个会议参与者的视角:

  1. 从公司视角出发,而不是从个人视角出发。
  2. 提供“我可以做什么”的视角,而不是“他可以做什么”的视角。
  3. 提供彼时彼岸的视角,而不是此次此岸的视角。什么意思呢?我们在复盘时不要乘着时光机乱飞,不要把未来的知识带到过去中。
  4. 提供找机会的视角,而不是追责任的视角。也就是说,最终还是要提升未来架构活动的成功概率,
  5. 提供抓大放小的视角。我们的目标是看大机会,而不是找小确幸。

在引导与控制的过程中,你要帮助其他参与者梳理思考维度,而不是梳理分支。分支中的机会肯定是越来越少,而新的维度上的机会或者跨多个维度组合的机会,很可能是突破性的。我们的目标是在高维空间上,找到可以最大化未来成功概率的机会点。

具体而言,我建议应该着重关注如下几个维度:

  1. 整体流程:从目标设定到架构环境搭建,再到最终的交付,有什么可以改进或提升的地方?
  2. 决策质量:公司在大型决策中的质量怎么样?如何进一步提升决策质量?
  3. 架构规划:我们到底有没有真正意义上的架构规划?这个架构规划有无重大缺陷?取舍是否正确?架构规划对实施起到指导作用了吗?
  4. 执行和实施:实施过程是否忠于最初的目标?最终是否能交付预期的价值?
  5. 质量控制:核心模块的最终质量是否达到了预期?
  6. 组织维度:团队是否胜任?组织是否给力?协同是否高效?
  7. 文化维度:公司文化对架构活动的成功有帮助吗?还是阻碍了架构活动过程中的探索和求真?

要知道,并不是每个参加架构活动的人都能贡献出深度思考。因此在选择会议的参加者、准备回顾内容、控制每个话题的时长、话题之间的流转上,都要体现出我们架构师的认知。

梳理机会点

在回顾过程时,你需要引导每个参与者共同思考一个问题:在可控维度上错失的最大机会点是什么?

这个过程是个多轮的共创过程,每个参与者都要思考如下几个问题:

  1. 在某个维度或者某个组合维度上,我们错失的最大机会点是什么?
  2. 为什么这是个错失的机会点,而不是一个无法掌控的风险因素呢?未来碰到这样的机会点,我们可以把握住吗?
  3. 这个错失的机会点有多大?可以从商业价值或者用户价值上来度量吗?

需要注意的是,要避免花太多的时间在跟进措施上,毕竟你的目标是找到那些最值得深入的话题。这个过程与模拟退火(Simulated Annealing)算法十分类似,需要经过多轮的搜索、讨论、再搜索、再讨论,从而找到全局最优解。

挖掘根因

针对最重要的三个机会点,你要彻底挖掘造成这个损失的根因在哪里。

这里我们要用故障复盘里的五个“为什么”的方法,也就是“Five Whys”,不断挖掘问题根源,突破问题的表面现象,最终找到一类问题的底层根源。

举个例子。第一层问题总是:

为啥出问题了?

答案总是:

因为没有发现问题。

很多复盘都止于故障发现。也就是大家最常用的故障防控三板斧:加监控报警、加响应及时性考核、加灰度发布能力。

结果呢?报警太多了,新一轮的问题淹没在现有的报警里面。 我曾经见过一家大公司里,上万名研发的人均电话报警个数超过400个每天,连短信费都让人咋舌。也就是说,这种在最浅层寻找到的问题和解决方案,不仅不能解决问题,反而可能会把问题搞得更糟。

那我们继续往下问,来到问题的第二层:

为什么你没有事先意识到问题?比如通过某种形式的监控而提前发现问题呢?

答案往往是:

我没有意识到这里会出现问题。

很多问题就在这里停止了,似乎就是能力问题啊!没解了,除非换人。

我们再问下去:

但是为啥你没意识到呢?

答案往往是:

我没有想过。或者是,我没顾不上想这个问题,实在太忙了。

这时候你可能意识到了,似乎这里还有机会。那你继续问下去:

你没想到,是因为没有时间,还是说给了足够的时间也想不到呢?再遇到这样的问题,你还是会想不到吗?

这个时候,答案往往会发生变化:

如果给我足够的时间,我应该能想得到。或者,未来如果给我足够的时间,我肯定能想得到。

你再继续往下问:

为什么呢?

这时候你可能会得到一个有价值的答案了:

因为这是个单点,而且是项目的强依赖。一旦它挂了,项目也就挂了。我当时太忙,没有注意到它是单点。

很多人在这里可能就会停下来。在我看来,如果这是整个复盘中大家公认的最重要的一个机会点,那就应该继续问下去。你可能先问一个分支:

为啥是单点呢?

这时候你可能会听到很多分支的答案了:

因为业务同事就只谈了一家支付公司。或者,因为研发资源不够,联调太麻烦了。再或者,因为上线时间不够,等等。

你可能会再问另一个分支:

为什么是强依赖呢?

同样,你可能会听到很多个答案:

因为这是个支付服务,产品设计就是一手交钱一手交货。或者,因为就应该是强依赖啊,之前就是这么设计的。再或者,因为没有支付成功的消息,流程就走不下去啊,等等。

你会发现,深挖根因的过程,最终都会止于一系列的假设和既定的流程。那么你就会问到一组终极问题:

我们的假设正确吗?我们的商业模式就应该是这样吗?我们流程就应该是这样吗?

很明显,不是的。

寻找新的模式与机制

我们很多时候都只是在缺乏思考中忙碌,默认当前的做法就是正确的做法,当前的模式就是正确的模式,当前的流程就是正确的流程。但是很多时候,我们都被自己过去的错误所框住了。一旦突破这些束缚,就能提升未来架构活动的成功概率了。

还是上面问答的例子。我们并非要一手交钱一手交货,分期付款、先用后付、信用付都是非常好的商业模式。支付也并非是不能降级的强依赖,降级之后也有很多风控的办法。支付既不需要单点,也不需要同步进行。所以我们有很多方法可以提升企业未来在支付这件事情上的成功概率。

这还不是全部。前面提到了,我们并非是一个故障复盘,我们的目标是提升企业未来架构活动的成功概率。所以作为架构师,一定要把个例中的发现转变成一种模式和企业的机制。

还是这个例子。这个复盘可能会引导产品和业务同学引入新的模式。从技术视角而言,从这个讨论的过程中,你应该抽取到一些更具普遍性的模式提升的机会。比如在未来的架构项目里,你应该对单点有个完整的梳理流程,并针对单点做一定程度的加固。

同样,在强依赖的处理上,你会发现大多数服务是可以降级的,甚至连支付这样的服务也都可以降级。当然,你不一定要在架构活动的主流程中,来完成整个降级方案的实施。

但是把这种常识性的、被认为是强依赖的服务,设计成可以降级或者异步的服务,就是你在之后的架构设计中所必须思考的一环。当看到一个同步的强依赖服务的时候,就要问问业务方和产品设计者:为什么这个服务必须是一个同步的强依赖服务?

在这整个过程中,你的目标是尽量找到一个模式和机制,而不是解决一个单点问题。只有前者,才会持续提升整个公司的成功概率。这就是我们反复强调的复盘的终极目标。

产出跟进项

如果上述动作落实到位,此时应该能产出非常多的跟进项了。架构活动一般都是较为复杂的,我们的分析不仅有多个维度,要平衡多个视角与多种因素,而且还有职能团队的参与。那么问题来了,这个时候并不是没有跟进项,而是跟进项太多。该怎么办呢?

我的建议是:最多保留三个跟进项。

最多保留三个跟进项,并不是说公司在一个大型项目失败后,接下来只需要跟进三件事。它指的是,你作为架构师,最终建议整个公司做出改变的事项,绝对不应该超过三项。公司里有很多团队,每个团队都有自己的跟进项,数量绝对不止三个。但从企业的视角来看,数量不应该超过三个。

主要有两方面的原因。一方面,对于公司来说,模式与机制的调整有着更为长期的影响。哪怕是变化非常频繁的互联网公司,在模式与机制上也必须保证一定的连续性,切忌随意生产大量新机制或新模式。

另一方面,我们在复盘过程的推演根源是单个案例。从单个案例中推导出的结论,必然有一定的局限性。也就是说,结论看起来万无一失,但推进之后,肯定还会再发现问题。因此,只有集中精力认真分析少数几个跟进项,才能有效提升这些跟进项的存活率。

完成复盘

综上所述,复盘就是从公司层面进行回顾过程、搭建环境、梳理机会点、挖掘根因、寻找新的模式与机制、产出跟进项的完整过程。在这个过程中,你应该能找到帮助自己提升的一些机会点。

另外,还要一个本来在项目上线环节应该强调的一个点,也就是资源释放。有些项目的组织者,在一个大项目结束后会找各种理由扣押资源,要求做一些项目之外的附加需求。类似这种扣人甚至是挖角的行为都是非常不道德的,会严重影响团队的文化。

在新的环境下,如果原有的组织架构不再适用,那也应该作出公开的、有理有据的决策。否则,就要督促所有项目组在架构活动结束后立即释放资源。

小结

对于任何人来说,复盘的能力都是职业成长中极其重要的一件事。更准确地说,这是一个从失败中学习的能力。跟其他活动一样,复盘也要有一个目标。有了明确的目标,才能引导参与者走向正确的思考路径和做事方法。

复盘的目标,不仅仅是为了挽回损失,更重要的是为未来铺设一个成功路径,找到提升成功概率的办法。所以我们的思考、准备和行动,都是为了寻找可以长期应用的新机制和新模式。这应该是我们复盘时最需要保持的心态。

如果把这节课给出的复盘案例,与之前在风险控制和可行性探索中给出的案例进行对比,你会发现它们之间具有非常大的相似性。

的确是这样的。我在整个模块中分享的知识,都来自我这些年在大项目中不断总结和抽象出的提升大型项目成功概率的方法。通过这节课,我希望你不仅能学到复盘的正确方法,同时还要学会把复盘这种理念应用到日常生活中去,在生活中找到提升自己的办法。

复盘吧,朋友们!

思考题

三个思考题,任选一个:

  1. 在你经历过的复盘中,有获得什么深刻洞察吗?这个洞察为公司带来了什么样的变化?
  2. 在你经历的复盘中,阻碍参会者达到深刻洞察的最大障碍是什么?你发现了什么克服的方法吗?不管是成功还是失败的经验,都可以分享一下。
  3. 在你经历过的复盘中,完成最好的一个跟进项是什么?为什么?

如果这节课对你有帮助,欢迎把课程转发给你的同事或朋友。顺便打个小广告,我刚开了个人抖音号,会定期发表一些比较新、但不一定那么成熟的观点。欢迎在抖音上搜索“郭东白”并关注,也欢迎你的批评指正。我们下节课再见!

标签:视角,跟进,郭东白,机会,维度,架构,34,复盘
From: https://www.cnblogs.com/gongxianjin/p/17012080.html

相关文章

  • 郭东白的架构课35
    你好,我是辰洋,《郭东白的架构课》的项目负责人。文章更新得很快,马上就会迎来我们第二个模块的尾声。按照惯例,在每个模块结束之际,我都会带着几张图文来做个加餐。这一次尤为......
  • 郭东白的架构课37
    你好,我是郭东白。我们今天就正式进入模块三的学习了。我们在开篇词里面介绍了,模块三的目的是向你介绍架构师的能力维度,以及获取这些能力的方法。既然是总结架构师成长的课......
  • 郭东白的架构课38
    你好, 我是郭东白。上节课我们定义了架构师这个角色,也了解了架构师的五个成长阶段,分别是程序员、兼职架构师、跨域架构师、总架构师和CTO。以及与这五个阶段分别对应的核......
  • 【前端vue开发架构】vue开发单页项目架构总结
    活动设计的前端架构主要的技术栈为Vuejs,Webpack,请自行阅读如下技术或者框架的文档:一、基础说明:node (https://nodejs.org/en/)npm(​​https://www.npmjs.com​​)webpac......
  • MySQL-存储引擎架构
    MySQL是一种分层体系结构的关系数据库。一共有三层:客户(连接)层,Server层,存储引擎层。简单理解就是这三层架构。官网的解释在这里。(这个部分建议看8.0的文档,8.0文档补充了架......
  • 代码随想录算法训练营第一天LeetCode704,35,34,27
    代码随想录算法训练营第一天|LeetCode704,35,34,27LeetCode704二分查找题目链接:https://leetcode.cn/problems/binary-search///第一次做还不知道二分中的左闭右开和左闭......
  • 【《硬件架构的艺术》读书笔记】09 电磁兼容性能设计指南(3)
    9.6.3微控制器级技术解决噪声问题的最佳途径在源头。9.6.3.1多时钟和接地去耦电容:1、容量应足够大以在转换时间内提供所需的电流。2、应足够小以使时钟频率小于电容......
  • LNMP架构环境之PHP环境部署
    1)使用第三方扩展源安装php7.1#1)配置PHP安装源yum -yinstallepel-releasewget​​https://mirror.webtatic.com/yum/el7/webtatic-release.rpm​​--no-check-cert......
  • Istio整体架构组件解析
    Istio在微服务之间建立连接,接管通信功能,对业务微服务屏蔽通信细节,同时通过流量控制、策略控制、遥测统计、Istio安全机制等对微服务进行监控和管理,使得微服务架构更加健壮、......
  • 迅为LS2K0500开发板龙芯全国产处理器LoongArch架构核心主板
     全国产开发板:迅为iTOP-LS2K0500开发采用龙芯LS2K0500处理器,基于龙芯自主指令系统(LoongArch)架构,片内集成64位LA264处理器核、32位DDR3控制器、2DGPU、DVO显示接口、两路P......