每个人都要会的复盘知识

简介: 复盘本来是围棋术语。指的是在对弈之后,棋手们会重演一遍对局,从中发现自己的错误,理解对手的思路,研究更为妥善的走法。很多围棋高手都把复盘当做棋艺精进的重要法门。后来柳传志先生把复盘引入了管理领域。

什么是复盘

复盘本来是围棋术语。指的是在对弈之后,棋手们会重演一遍对局,从中发现自己的错误,理解对手的思路,研究更为妥善的走法。很多围棋高手都把复盘当做棋艺精进的重要法门。后来柳传志先生把复盘引入了管理领域。

为什么要做复盘?

复盘的目的就是通过事后总结,获得更好的反馈。

你可能听说过一万小时定律,指的是一个普通人只要经过一万小时刻意练习就能成为某一领域的高手。但事实上有很多领域并非如此。这里的关键是,你的练习是否有反馈。我最近听到一个关于反馈的思想实验,能更好地说明反馈的重要性。

如果你让一个盲人去拧魔方,中间不给任何反馈,你猜盲人需要多久能够复原?计算结果是137亿年都没办法复原。也就是说,靠纯概率,随机性的拧是没办法复原的。但只要你加一个动作,在他每拧一步都给他一个反馈,是离目标更近了,还是更远了。只需要2分半就能够还原。

复盘的具体操作步骤

以项目研发为例

第一:回顾目标。

回忆这次版本需求的目的或预期结果?一般我们会用OKR或者KPI来评估目标的完成情况。

第二:评估结果。

有没有达成目标?或者说与预期结果相差多少?这里不仅仅只是看团队的整体目标,还需要看团队里每个人的个人目标。

第三:分析原因。

回顾事情的事前,事中,事后全流程,分析达成目标的原因有哪些?未达成的原因是哪些?

常见的分析思路如下:

  1. 目标的设定是否靠谱?如果靠谱,是什么原因?如果不靠谱怎么改进?
  2. 执行的过程中是否有可改善的地方?如果有,应该怎么改善?如果没有,那做得好的地方是什么?
  3. 对于可控的原因一定要制定解决方案,对于不可控的原因要做好风险控制,比如让信息传递更通畅,做好plan B方案等。

很多时候我们不是不知道要问,而是不知道该如何追问。这里推荐查看这篇提出好问题引出一个好答案来追问为什么。

第四:总结经验,用于下一版迭代。

每一次做得好的地方,都要总结成可迁移的经验,放到下一个版本里使用。对于那些做得不好的,要针对性地制定解决方案,并预估其效果和成本,根据预期效果和成本做一个二维四象限。优先做那些实施成本小,效果好的方案。并放到下一个版本里去验证。

复盘中常见的问题

第一个问题是,把复盘会开成了甩锅大会。

越是复杂的项目,复盘出来的问题也越多。大家或多或少都有点问题,但大部分人都不愿意承认自己的问题,更倾向于在别人身上找原因。这样就容易造成大家相互甩锅。之所以出现这种情况,关键在于大家对复盘目的地理解错了。复盘虽然是对过去发生的事情做总结,但目的并不是为了追责和惩罚。复盘的目的是通过对原因的分析,对未来做更好的优化。

第二个问题是,如何复盘出有价值的结论,并运用到下一次的改进中?

复盘的结论不一定就是正确的,就算正确也不大可能一步到位。我们能做的就是把经验总结成可执行的方案。放到下一个版本里去做迭代验证。我自己的经验是通过流程、制度、清单三种方式来实施。比如这次项目中,我们发现每天一次碰头会对项目进度有好处,那么我们就可以把碰头会变成固定的每日站会,并规范会议规则保证会议效果。

这里我推荐大家多用清单。所谓清单就是执行步骤。比如,这次从测试到上线非常顺利,我们就可以总结一个上线必查清单。

第三个问题是,复盘的结论不能达成共识。

每个人都有自己的认知,所以在复盘的时候,大家得出的结论不一定完全一样。我们需要求同存异,根据公司具体情况让最有经验的人或者对事情负责的人来拍板。就算是错的,我们依然可以在下一次复盘里做出改正。

对于复盘的结论,我有两个经验,一个是尊重常识,能用简单解释的就不要想得太复杂。另一个是对于那些非常规的结论,需要更多证据来证明。像用户行为数据、用户调研都是我们获得更多证据支撑的工具。

常用的复盘模型

这里推荐两个常用的复盘模型:

PDCA

一个是PDCA模型,包括4个环节,计划(Plan)、执行(Do)、检查(Check)和处理(Act),它的优化主要体现在对于具体做事标准修订,比如管理制度,项目验收标准等,对于那些易于犯错的点可以整理成CheckList清单,把解决方案固化到流程里。PDCA每循环一次,做事的标准就验证或优化了一次。但是PDCA也有其局限性,如果目标是错的,它并不会告诉你哪里错了。

PDF

另一个是PDF模型,包括3个环节,沙盘推演(Preview)、执行(Do)、复盘(FuPan)。PDCA是把一件事情分成4个环节来做,而PDF是把一件事情重复做3次,第一次的沙盘推演和第三次的复盘都是虚拟的做,第二次的执行是实际的做。它的优化主要体现在加深对事物本质的认知,但是其局限性在于严重依赖复盘者的个人能力、可复制性不强。

总之,每个人都应该做好复盘。没有谁出身就优秀,团队也是如此。每一个优秀的团队都是通过一次次迭代升级出来的。复盘得越及时,大家的感受就越深,效果也越好。在项目里,每个人都需要参与到项目复盘中,这也代表着除了组织层面上需要改进之外,个人也要专门定制自己的改进计划。

目录
相关文章
|
5月前
|
安全 测试技术
测试团队的一次复盘实践
测试团队的一次复盘实践
217 0
|
5月前
|
运维 监控 安全
如何写复盘报告
该内容是关于IT公司中复盘报告的撰写指南,主要包括五个步骤:1) 还原故障基本信息,如定级参考;2) 描述处理过程,按时间顺序列出关键点;3) 评估影响范围,可能涉及业务基线;4) 确定故障原因,从直接原因到根本原因层层分析;5) 分析责任归属和事件级别。复盘还包括故障回顾,提出优化措施以减少重演。内容还提到了一些参考资料,用于深入学习稳定性保障。
180 0
|
5月前
|
监控 架构师 算法
|
5月前
|
测试技术
现网问题复盘
现网问题复盘
|
前端开发 C++
浅谈复盘的道法术器
人的经历太有限了,如果凡事都要自己经历过才能有所领悟,这样的效率太低。丹麦一位哲学家克尔凯郭尔曾说过:人生需要回望才能理解。对于一个组织、一家企业也是如此。复盘是我们突破经历限制,从过往挖掘提升的一个有效方式。因工作契机,前段时间对复盘进行了系统性的研究和升级。期间查阅了大量资料、书籍,也和一些专家做了交流,总结道法术器4个层面的关键点,希望对你有所帮助。1、你是不是也遇到过这类问题?实际复盘的效
319 0
浅谈复盘的道法术器
|
缓存 JavaScript 程序员
786.【复盘】每周复盘-第十四周
786.【复盘】每周复盘-第十四周
|
程序员 Python
800.【复盘】每周复盘-第十六周
800.【复盘】每周复盘-第十六周
|
程序员
795.【复盘】每周复盘-第十五周
795.【复盘】每周复盘-第十五周
|
程序员
811.【复盘】每周复盘-第十七周
811.【复盘】每周复盘-第十七周
|
缓存 程序员
780.【复盘】每周复盘-第十三周
780.【复盘】每周复盘-第十三周

相关实验场景

更多