文章目录
  1. 1. 复盘
  2. 2. 类似的方法论
  3. 3. 程序员如何复盘

联想有一种称为复盘的学习方式:做一件事情,失败或成功,重新演练一遍。大到战略,小到具体问题,原来目标是什么,当时怎么做,边界条件是什么,回过头做完了看,做的正确不正确,边界条件是否有变化,要重新演练一遍。我觉得这是提高自己非常重要的一种方式。
——柳传志 联想控股有限公司董事长

复盘

最近读完了一本书《复盘》,里面讲了很多的故事,全书显得很啰嗦,但是理论上其实就是简单几句话:事前做沙盘推演,做事情,事后做复盘总结。

复盘的过程又分成:

  • 回顾目标。将当时的目标和当前的现状做对比,找出不一致的地方,便于分析。
  • 叙述过程。复述整个事情的执行过程,收集尽量多的数据和细节,便于分析。
  • 反思原因。目标达到了或者是没有达到,为什么?自己的解释能够说服自己吗?
  • 总结规律。除了有总结外,还需要找有没有例子证明总结的规律。

类似的方法论

其实看完了《复盘》,我已经非常多次看到类似的方法论了。

比如在 Scrum 流程中,将回顾会议设置成一个 Sprint 标准的环节,其实就是强调复盘,以便总结出一些改进团队工作的结论。

比如在德鲁克的《卓有成效的管理者》一书中,就将决策要素分成五步,而第五步就是在执行过程中重视「反馈」。而这里的复盘,就是「反馈」的一种。

比如在美国管理学家戴明(Deming)的 PDCA 理论中,将质量管理分成计划(P)、执行(D)、检查(C)、改善(A)。这里的改善,其实就是指的对检查过程中发现的问题进行总结,对于成功的经验进行标准化推广。

比如我们将产品经理的工作,分为定功能,画交互,跟项目,看结果。这里的「看结果」,其实就是一种复盘思维,看看线上的数据和自己之前的假设是否一样,以便进一步改进产品稿。

你看,虽然大家的理论不同,但是其实套路都是一样的。

是的,这就是一个非常简单的成长的套路。

程序员如何复盘

对于程序员应该如何复盘呢?

  • 写完代码后,想想下一次写,有没有可能写得更好,更快。
  • 改完需求后,想想下一次可不可能在架构上更容错。
  • 修复完线上bug后,想想有没有什么质量控制方法可以尽量避免犯同样的问题。

很多人都不知道如何提高,殊不知其实任何事情,都可以用复盘的心来做做总结,不知不觉,你就成长了。

希望大家都能学会这个「成长的套路」!