回顾过程指的是以时间顺序对事实进行多维度的客观描述,包括主要决策的环境、最终的决策,以及由此推演而来的规划。
在架构活动的进行过程中,如果一直遵循沉淀知识的建议。那么在这个环节,就不需要做太多的准备工作,只把线上文档中记录的重要决策和相关背景提炼出来即可。
唯一需要注意的是,除了架构师视角的回顾外,你还需要从非技术职能的视角出发,对架构活动进行回顾。
这些非技术职能的视角包括项目经理、产品经理、业务、运营,甚至还包括客户。这个补充动作非常重要。因为架构活动耗时较久,在复盘时回顾内容往往会引导大家的讨论走向。如果你能提供充分的视角,并为每个视角分配合理的权重,将会大幅拓宽机会洞察的搜索半径,找到更高质量的提升点。
邀请一组正确的人参加复盘时,作为架构师,你需要对复盘的氛围和内容持续做引导与控制,尤其要确保每个会议参与者的视角:
在引导与控制的过程中,你要帮助其他参与者梳理思考维度,而不是梳理分支。分支中的机会肯定是越来越少,而新的维度上的机会或者跨多个维度组合的机会,很可能是突破性的。我们的目标是在高维空间上,找到可以最大化未来成功概率的机会点。
着重关注如下几个维度:
要知道,并不是每个参加架构活动的人都能贡献出深度思考。因此在选择会议的参加者、准备回顾内容、控制每个话题的时长、话题之间的流转上,都要体现出我们架构师的认知。
这个过程是个多轮的共创过程,每个参与者都要思考如下几个问题:
需要注意的是,要避免花太多的时间在跟进措施上,毕竟你的目标是找到那些最值得深入的话题。这个过程与模拟退火(Simulated Annealing)算法十分类似,需要经过多轮的搜索、讨论、再搜索、再讨论,从而找到全局最优解。
不断挖掘问题根源,突破问题的表面现象,最终找到一类问题的底层根源。
很多复盘都止于故障发现。也就是大家最常用的故障防控三板斧:加监控报警、加响应及时性考核、加灰度发布能力。
我们很多时候都只是在缺乏思考中忙碌,默认当前的做法就是正确的做法,当前的模式就是正确的模式,当前的流程就是正确的流程。但是很多时候,我们都被自己过去的错误所框住了。一旦突破这些束缚,就能提升未来架构活动的成功概率了。
我们并非是一个故障复盘,我们的目标是提升企业未来架构活动的成功概率。所以作为架构师,一定要把个例中的发现转变成一种模式和企业的机制。
如果上述动作落实到位,此时应该能产出非常多的跟进项了。架构活动一般都是较为复杂的,我们的分析不仅有多个维度,要平衡多个视角与多种因素,而且还有职能团队的参与。那么问题来了,这个时候并不是没有跟进项,而是跟进项太多。该怎么办呢?
如果上述动作落实到位,此时应该能产出非常多的跟进项了。架构活动一般都是较为复杂的,我们的分析不仅有多个维度,要平衡多个视角与多种因素,而且还有职能团队的参与。那么问题来了,这个时候并不是没有跟进项,而是跟进项太多。该怎么办呢?
最多保留三个跟进项,并不是说公司在一个大型项目失败后,接下来只需要跟进三件事。它指的是,作为架构师,最终建议整个公司做出改变的事项,绝对不应该超过三项。公司里有很多团队,每个团队都有自己的跟进项,数量绝对不止三个。但从企业的视角来看,数量不应该超过三个。
主要有两方面的原因。一方面,对于公司来说,模式与机制的调整有着更为长期的影响。哪怕是变化非常频繁的互联网公司,在模式与机制上也必须保证一定的连续性,切忌随意生产大量新机制或新模式。
另一方面,我们在复盘过程的推演根源是单个案例。从单个案例中推导出的结论,必然有一定的局限性。也就是说,结论看起来万无一失,但推进之后,肯定还会再发现问题。因此,只有集中精力认真分析少数几个跟进项,才能有效提升这些跟进项的存活率。
复盘就是从公司层面进行回顾过程、搭建环境、梳理机会点、挖掘根因、寻找新的模式与机制、产出跟进项的完整过程。在这个过程中,你应该能找到帮助自己提升的一些机会点。
此文章为5月Day25 学习笔记,内容来源于极客时间《郭东白的架构课》,推荐该课程。