浅谈 | 如何做好技术复盘

前言

个人觉得技术类的博客是不好写的，因为涉及的方面太多，且专业性很强，想要把这个事情简化地描述出来，你自己得先整明白，但往往我们看了一篇文章，可能也只是了解其中的一部分。

复盘主要包括如下6个环节

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

• 回顾架构活动
• 搭建复盘环境
• 梳理机会点
• 挖掘根因
• 寻找新的模式与机制
• 产出跟进项

学会从「生命周期」的角度去思考问题

回顾架构活动

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

什么时间点、发生了什么事情，然后做出了什么样的决策，在这个过程中需要做好知识的沉淀。

保持平衡的视角

不同视角的人员来参与复盘，拓宽机会洞察的搜索半径，找到更高质量的提升点，做到复盘的平衡。

遵循的原则

1. 从更大的角度去思考问题，比如从团队发出、从公司角度出发

2. 如果我们是做平台的，多想想“我们能够做什么”，“能提供什么样的能力”

3. 复盘往往是后置的行为，所以不能从现有的角度去看过去，比如：“你当时为什么不考虑这个方案呢？”

4. 复盘不是为了追责，而是提供「找机会」的一个讨论

5. 抓大放小，不能因为一个牛角尖带偏整个复盘的方向

复盘的维度思考

整体流程：从目标设定到架构环境搭建，再到最终的交付，有什么可以改进或提升的地方？

决策质量：公司在大型决策中的质量怎么样？如何进一步提升决策质量？

架构规划：我们到底有没有真正意义上的架构规划？这个架构规划有无重大缺陷？取舍是否正确？架构规划对实施起到指导作用了吗？

执行和实施：实施过程是否忠于最初的目标？最终是否能交付预期的价值？

质量控制：核心模块的最终质量是否达到了预期？

组织维度：团队是否胜任？组织是否给力？协同是否高效？

文化维度：公司文化对架构活动的成功有帮助吗？还是阻碍了架构活动过程中的探索和求真？

实际上，我们在做项目时，也是这么一个逻辑：

1. 核心项目需要立项评审，确定其质量

2. 技术方案中的架构是否合理

3. 短时间内预期的目标是啥？能够带来什么样的价值？

4. 项目会有哪些技术产出

5. 项目需要哪些组织上的协同

上面的几个点，真的非常适合多揣摩

梳理机会点

我们做好复盘，都是对于过去的一种总结和思考，但最终目标还是希望能够找到一些最值得深入的话题，然后制定一些跟进措施。

挖掘根因

深挖根因的过程，最终都会止于一系列的假设和既定的流程。

那么你就会问到一组终极问题：我们的假设正确吗？我们的商业模式就应该是这样吗？我们的流程就应该是这样吗？很明显，不是的。

我们的人生其实非常缺乏复盘的，谁给你复盘，你只有在夜深人静的时候，思考下我该怎么办？多么孤独的灵魂。或者找身边的朋友，帮你分析分析，但一个“层级”的复盘，基本也就决定了复盘的效果。

在忙碌中缺乏思考

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

复盘只是一个单点的思考，如何突破到面上，才是难点，针对单点做一个完整的梳理流程，并且针对单点做一定程度的加固。

产出跟进项

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

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