实战拆解：手把手教你开好产品复盘会

本文由本公众号专栏“B端产品经理的工作笔记”的特约作者：东瓶西镜同学 撰写。他作为产品总监，从供应链金融的工作实战来分享B端产品的工作经验，来分享相关的文章。欢迎关注公众号：李宽wideplum，持续关注独家文章更新。

作者说：

复盘，是最好的老师。

上周我们的产品进入试运营阶段，由于产品是供应链金融系统，属于B端产品，场景化要求高，产品应用的行业属性决定着有一定的业务运营门槛，需要慎重推广。

因此我们决定先在既有的体系内试运营，虽说是在集团内部的兄弟企业间应用，产品就算有些瑕疵，影响也相对可控，可毕竟也是正式环境的实单运营，也有GMV作为KPI的北极星指标驱动着，我们也是万分重视。

团队的工作重心本周也重点放在了实单运营上，业务、运营、产品、技术和测试全力协同，可万万没想到最后还是出问题了，流程竟然有阻塞，虽然紧急处理后，最终修复了问题，也实际走完了流程，但是产品的不良影响却已经产生，无法挽回。

严格来说，这算是严重的产品事故了，于是，领导严厉要求各部门成员认真反思总结，并组织且亲自参与了复盘分析会，别说，通过复盘分析，我们还真的发现了众多问题，有已知的，有未知的，有事务性的，也有流程性的。

我除了觉得这次复盘十分必要，同时，我更意识到：复盘对于保障产品的持续跃升，可以说是十分有效的工具， 因此本文主要结合我们这次复盘案例，深度探讨下项目复盘的那些事儿。

01 何为“复盘”

复盘是什么意思呢？

复盘原是围棋术语，也称 为“复局”，是指对局完毕后，复演该盘棋的记录，以检查对局中招法的优劣与得失关键。在围棋中，一般用以自学，或请高手给予指导分析。

因此，复盘是指对某一个已发生的特定事件历程进行分析总结，比如，沙场秋点兵结束后，将军对于战略战术应用是否得当的总结分析，最近重读《资治通鉴》，汉高祖刘邦有一点就特别了不起，就是每次犯错之后，都会组织复盘分析，所以，他从来不犯同样的错误。

工作中，**在一个产品上线或运营后，对于已经上线历程或者运营经过，进行系统化的总结分析，总结过程成果，归纳过程中的不足，**从而吸取教训，形成经验，为以后的工作提供可借鉴的指导性的价值。

事实上，通过对工作的复盘分析，当后续工作再发生相同的场景时，便有经验可供参考，我们往往能够快速响应且快速应用，就像是有思维指令一样，通过条件反射，就能作出正确的决策。

02 复盘的价值

我们产品经理在主导产品上线或试运营后，可以适时的组织复盘分析，那么，产品复盘分析可以为产品带来哪些具体价值呢？

我就结合我们前天的复盘沟通会，总结如下，可供参考。

第一、发现未解决的产品缺陷，完善缺陷管控机制。

尽管我们在测试环境、生产环境都围绕产品质量进行了系统性的测试，但仍无法避免出现一些产品bug，这些缺陷的出现可能是测试范围未覆盖，也可能是偶发性的，不过，一般来说，在正式环境不会出现影响流程性的缺陷，多是一些体验性的或者业务理解性的缺陷。

我们这次试运营的过程中，同样也出现了一些缺陷，比如，融资利率试算时，在业务存在多单融资时，存在重复计算，这个缺陷实际上在测试环境已出现过，回归测试也已验证没有问题，可昨天实单运营时又复现了。同时，也有一些体验性的小bug。

项目复盘的价值，不仅仅在于发现未知的产品缺陷的评估，更在于对于缺陷管控机制的完善，为何正式环境仍会出现这样的低级错误？

事实上，我们通过复盘沟通，发现缺陷在回归测试时仅验证了当时的小版本，并且只是在测试环境验证了一下，后来开发合并代码时有遗漏，复盘后，我们决定，根据缺陷等级，在正式环境上线时，要针对回归验证过的高等级的缺陷逐一验证。

第二、识别可优化的产品需求，建立需求优化与产品验收体系。

在运营过程中，我们还收到客户反馈了一些需求建议，这些可优化的需求，有些是已经识别并列入需求池里的，有些是未发现的新需求，还有一些更重要，是已经评审通过的需求，但是开发并未实际执行。

根据我们复盘总结，通过这些可以优化的需求，我们意识到，产品经理不仅要有需求优化的管理体系，也得有产品验收的体系。

需求优化管理和产品验收实际有交集，新需求识别后的优化设计，需要在优化体系进行识别，调研分析，立项设计，排定优先级，需求详细设计与开发评审等多个环节。

产品验收体系包括优化需求的验收管理，事实上，我们之前对于优化需求并没有很好的验收管理，只是靠测试把控，那么这次复盘后，我们决定，属于业务干线的产品需求，哪怕是优化的、完善的需求，也需要产品验收。

所以，通过本次复盘会，我们对于产品需求的优化体系与产品验收体系，提出了新的要求，完善了相关内容，有利于后续产品质量的把控。

第三、提高沟通效率，驱动协作机制的有效形成。

提高沟通效率可能是每个复盘会最大的价值期望了，事实上，有效的复盘会的确可以发现很多沟通协作的问题。

沟通效率的低下常见有四个因素，一是沟通半径较长，二是沟通形式低效，三是沟通专业能力不足，四是情商驱使。

事实上，沟通专业能力和情商首先在岗位专业能力的基础上，更多的是依赖性格能力，短期内并没有特别有效的方法，但是针对于沟通半径和沟通形式对于协作效率的影响确实可以改进。

之前我们产品组织需求评审时，技术总监怕耽误开发时间，有很多小需求不让开发参与评审，他参加后，再转述并安排给开发同学执行。

事实上，沟通传递本身就存在漏斗效应，开发人员也存在理解的偏差，这样反而降低了沟通效率，根源就是沟通半径的增长，我们这次复盘会，就深度交流了这个问题，最终一致决定：开发人员需要直接参与需求评审。

沟通形式上，之前开发过多的依赖需求文档和沟通群的消息传递，产品与技术的沟通显得过于正式和不够灵活，最重要的是，增加了沟通的时间成本，这次我们也形成了共识：敏捷开发，以站立会沟通形式为主。

第四、提高产品准备的管理水平，建立应急响应机制。

复盘沟通会可以有效提高产品准备的水平，并且可以建立更为完善的应急响应机制，这是我们本次复盘分析最重要的成果之一。

我们在试运营前一天领导便明确要求，但是我们部门总监们重视均不足，并没有进行实单的预演，只是根据生产环境的结果，想着不会有什么问题，事实上，如果我们当天加班完整演练一遍，绝对可以解决掉这些问题。

再者，我们的应急响应明显拉胯，这一点是本次我认为最重要的教训，我们的优先级意识和响应效率太低，我之前曾经说过，所有的选择本质上都是优先级思维的体现。

就拿我们这次来说，流程出现阻断后，技术总监就应该第一时间马上协调资源安排排查，可我们技术总监当时还在面试人员，客观来讲，面试也属于本质工作内容，并没有错，但是这个优先级明显要低很多，这一点我们也集体强化了下优先级意识，并且明确建立了应急响应体系，在出现重事务上，必须全力集中在解决当下紧急的问题上。

第五、找到问题根源，推动流程性问题的快速解决。

这次复盘分析会上，测试同学公开重申一个问题非常关键，那就是我们现在在正式环境并未测试，从生产环境测试后，直接就交付了，这个之前我们也沟通过，技术这边因为时间紧，担心正式环境存在安全问题，并且，正式环境的账号不好处理，就一直没有部署正式环境的测试。

事实上，这一次，公开讨论了这个问题，我也提出来，这是个流程性问题，不是事务性问题，这个流程不解决掉，后续仍旧会存在上线事故的风险，做开发的，有时候真的涉及玄学，从生产环境更新到正式环境，就是有可能出现问题。

除此之外，我们还针对用户安全的问题进行了流程梳理，比如，我们刚开始，以为是集团内的企业，草率的登录了他们账号，替他们操作，这些错误，低级的简直是有点过分。

所有的这些流程性的问题，正是复盘沟通会的核心价值所在，正是我们犯了错，公开指出来，放在台面上去讨论，大家批评与自我批评，才保证了复盘会的高效和有价值，这一点我很佩服我们的团队成员。

我相信，在认真改正的心态驱使下，复盘会的错误，一定是下一次的经验，对于后续工作的开展和衔接，一定有关键的过度效果。

03 复盘的方法

我作为本次产品复盘会的亲历者，重新站在观察者的角度来审视整个历程，有一些方法，对于团队尤其是产品经理，组织并开好复盘会至关重要。

第一、聚焦在工作内容，不要针对某个人或部门。

任何事情，指导思想都是第一位的，这一点在开展复盘分析时尤为关键，因为复盘分析多是对不足的总结，以期望后续工作可以规避不足。

因此，在产品事故的前提下，我们本能会感到压力，也就很容易过度重视责任划分，强化错误归属，形成部门对立，将战火引向他人的不足，进而偏离复盘的本来方向，所以，不要被思维误区带来的路径依赖所干扰。

这一点，我们产品部内部认识很清晰，我们头天晚上提前组织了复盘沟通，统一了思想认识，应该来说，这为第二天的复盘顺利进行作出了好的引导和表率。

第二、多反思下自身的不足，勇于表达出来。

人非圣贤，孰能无过，有过改之，仍为君子也。

这其实有两个要求，一是能够通过反思找到自身的不足，二是敢于勇敢的表达出来，这其实更是复盘的灵魂所在。

如果在复盘沟通会上，我们都从自身展开自我批评，不仅有利于整体氛围的正向引导，对自身的提升，对团队的建设都是至关重要的。

所以，我们在以后的复盘沟通会时，可以坚持这个原则，把自身的提升作为复盘的出发点和落脚点，并且勇于担责，敢于表达，往往有责任感的人，给人更加踏实的感觉。

优秀的个人一定是敢于正视自身不足的人，优秀的团队，也一定是敢于表达的集合体，这一点，我其实也很欣慰。

第三、相较于事务性问题，应更加关注流程性的问题。

流程性问题往往意味着高度可复制性，也就是说，本次出现的问题，后续仍可能会复现，如果要解决，就应该从源头，从流程上去解决。

就像上面提到的应急机制的欠缺、需求优化体系的不完善、正式环境与生产环境的不平衡，这些都属于流程性问题，这些不解决掉，后续一定还会出现类似的事务性问题，不是说事务性问题不重要，而是两者相较而言，我们应该在有限的时间里，更加关注影响可复制的流程性问题上。

所以，针对流程性、制度性的问题，一定要多一些注意力，更应该引起我们的重视，优先去讨论和解决。

第四、思考问题内容，提前考虑应对之策。

在复盘沟通之前，我们就应该从自身工作角度出发，针对你理解的问题点，去思考应对之策。

不打无准备之仗，提前做一些功课，既可以形成沟通清单，在会上讨论和探讨，同时也可以听取其他人看法，有意识的做一些对比，更加有利于自己对问题的认知。

我开始也总结了几个问题，后来发现自己的理解是偏差的，我并没有找到真正的问题点，因此，在听到别人分析后，对我也有很大的启发，更加深了对问题的认知，甚至也学习了思考解决问题的方法。

第五、注意沟通方式，问题定位是前提，同理心是沟通之主线。

良好的沟通是复盘会的前提和根本，贯穿始终，我们若想开好一个复盘会，依赖的一定是团队的有效沟通。

那么，首先就需要将问题定位清晰，找准问题的根本点，而非停留在表象层，或者只是针对问题本身做检讨，这些都不利于问题的根本性解决，只有定位精准，把准脉，才能开好药方。

其次，一定是同理心为沟通的情绪主线，多学习换位思考，多站在他人的角度上去思考问题，不仅有利于团队建设，避免不必要的冲突，同时，也会在良性氛围的驱动下，更加有利于问题的圆满解决。

相信大家在日常工作中，一定主导或参与过复盘会，复盘的根本点是为了积累经验，为以后的工作提供经验指导， 这一点，我们产品经理一定要牢记！

我也相信我们一定也会在同理心的驱使下，精细准备，精准定位，精确表达， 从而更好的复盘每一次历程。