复盘：创业经历中的一些教训，如何化为生产力？

由于近日与以前有创业经历的同事进行了探讨，不经意想起了当年的一些生产事故。当年发生的事故，事后也没有认真做复盘，现在仔细一想，感觉这是管理上的一大失职，实在是不应该。

复盘，能让我们把经验教训，快速化为生产力，而且是经得起实践检验的。下面我将以当年经历的一起生产事故，做一次复盘，做自我总结的同时，希望也能给大家一点启发。

背景：当产品发生事故后，我们应该做什么？

当年开发的广告系统，由于客户的操作不当，引发了有些广告发送出现异常。但是客户并不知道做了什么错误操作，认为操作没有问题，进而打电话过来质问运营人员，要求彻查并说明原因。

我们的做法是：

1、跟客户一起查找错误，并及时修正错误；

2、进行日志排查，将客户的操作记录进行分析，并形成了日志事件报告；

3、去客户现场，一起与客户解释本次事故的问题所在。

通过三个步骤的处理，问题已经得到处理，并将错误进行了修正，用户也没有再要求什么。表面上，本次事故已经解决，大家都松了一口气。再后来（约半年左右），该客户彻底不用我们提供的产品，转而使用了其他公司的产品。

从结果上看，我们和客户都没有从本次事故中获益，得到的结果是双方都不想看到的，即产品没有为避免再次发类似次事故而做出改进，客户虽然存在过错但是心里总觉得产品存在问题，拒绝再次续费使用。

事后：我们应该得到什么？

现在再看这次事故，我们缺少了一件非常重要的事情没有做，那就是复盘。

从当时对事故的处理过程来看，客观上是比较严谨的，同时也是很快就对事故进行了处理。由于客户客观存在问题，所以客户也没有提出什么要求，大家都认为此事得到了完美解决。但是，事实上，如果我们当时能及时总结的话，就会发现本次事故，其实可以得到很多有益的建议，而且很有可能会留住这位客户。

复盘一般分为四步：回顾目标、结果分析、原因分析、总结经验。按照这个思路，我对本次事故进行了分析：

1、回顾目标。

我们公司的产品，用户定位就是：可靠、简单、易用、高效。也就是说，我们的产品可以通过很少的培训，甚至不需要培训就能上手。由于广告的影响面比较大，所以还需要可靠这个保证。

整体来说，就是在可靠的前提下，需要让用户的体验是最佳的。

2、结果分析。

从事故的处理过程来看，日志分析、问题汇总、事故报告等这些都是问题分析的材料。

从结果来看，用户操作的失误，可能存在系统操作漏洞、用户操作习惯与系统存在较多差异、用户对功能的理解与产品设计不一致、系统未及时拦截危险异常操作等等。

3、原因分析。

从本次事故的结果来看，如果用户存在错误操作，很可能在简单和易用方面出现了产品的设计问题。从日志的排查情况来看，确实存在用户操作没有按照产品预设的顺序操作的情况。

这意味着产品设计存在缺陷。这种情况下，需要与用户进行深入的沟通，了解其操作习惯，也许这些都是提升点。同时，在用户体验角度，还需要加强设计，尽可能减少用户出错的可能性。

从日志分析的结果来看，存在系统记录了用户的操作记录，但是没有对应的异常告警产生，需要加强告警系统辅助系统的设计。

4、总结经验。

整体来说，本次事故的出现，意味着系统需要全方位进行排查，防止再次出现类似事故。如何做到防止类似事故再次出现呢？从本次事故的分析来看，可以从如下几个方面着手：

（1）优化用户操作指引，同时优化产品UED，减少用户操作失误。

（2）优化系统异常操作监控，并及时调整告警策略，让客户感知。

（3）加强产品设计，同时将产品理念（即“可靠、简单、易用、高效”），做到人人均知而且深刻理解。

上述这些还是比较泛的总结，还需要怎么落实呢？下面是我认为比较合适方法：

（1）今后所有迭代中，在产品的设计完成后，需要召开一次设计评审会议，要求产品经理、运营人员，甚至可以是客户一起参与评审。评审通过后才能交给研发。

（2）在测试用例中，加上用户体验相关的用例，并要求运营人员进行用例评审。通过评审的用例，需要复制给其他项目组参考。

（3）增加一个子项目，即产品告警子模块，并将本次事故的异常加入到监控规则中，而且需要确保未来可以不断增加可能出现的异常。

（4）组织一次项目组大会，从OKR的角度，让每个人对产品理念均熟悉，并有对应的KRs。有必要的话，可以列入考核范围。

总结：复盘的真正威力，就是能将教训化为生产力

犯错并不可怕，可怕的是错误犯两次。复盘，正是避免将错误犯第二次的良好方法。

对于个人来说，失败乃成功之母，遇到问题并不可怕，解决问题也是能力成长的重要手段。

对于企业来说，吸取教训，积累成功经验也是企业成长的必经之路。更重要的是，这些教训，经过复盘，能很好的化为生产力，这是复盘的巨大威力所在。