案例研究：让线上故障沉淀为团队的经验

今天分享农信数智副总裁李玉福老师通过项目案例让团队成长的经验。

俗话说吃一堑长一智，一个人如果不能从错误中吸取经验，那他则无法快速成长；一个团队如果不能从失败中总结并沉淀经验，那这个团队将无法快速前进。

针对失败和错误，最简单的方式就是惩罚，但是我们要讨论下惩罚失败的目的是什么？比如针对银行，惩罚失败是有道理的，因为它的风险成本太高。对于互联网企业这样的创新型公司而言，惩罚失败只会带来一个结果：遏制创新。因为只要是创新就一定会有失败，而是它失败的概率高于成功概率，我们更应该关注失败对于团队经验的积累和沉淀，这就是我的出发点。

如何把这些经验快速沉淀下来并能扩散到整个团队呢？我们可以使用一种叫 Case study（案例研究）的管理机制，来驱动团队愿意接受自己的问题，并乐于总结、分享经验，建立团队的知识库。

出现 Bug 后的错误的“打开方式”

我们知道程序员的工作内容，主要分为三个部分：

1. 与产品沟通需求；

2. 系统模块设计；

3. 开发实现与测试，最终发布。

即使是水平很高的技术人员，都难免因为在设计方面的缺陷和实现方面的疏忽，导致产品发布上线后出现一些 Bug。其中低级 bug 在测试阶段一般会被解决，而一些认知、集成以及环境方面的 bug，往往会因为我们缺乏经验，会跟随系统发布到线上。

针对线上发生的问题，如果我们只是简单粗暴地执行相关惩罚，比如公开批评、扣绩效等，对团队技术人员的伤害是极大的，这会导致技术人员在接下来的工作中担心犯错，做事畏首畏尾，技术上不敢创新，产品迭代速度变慢等等。另一方面，他们也会担心影响绩效，不敢大胆分析问题，甚至会把问题隐藏起来，导致经验没法沉淀，问题反复出现，影响用户体验。

针对这个问题，我们可以采用故障分析管理方法论 Case Study 来解决。

Casee Study 的背景和价值

Case Study 的雏形最早起源于医疗临床试验，后来商学院把 Case Study 应用于商业案例的分析，从而被大面积推广，尤其是 MIT，针对性地建立了财会、创业、企业领导力、运营管理、战略研究、可持续发展等系列商业案例库。

通过案例激发学生之间的辩论，来帮助学生模拟在实际管理工作情况下会做什么，不会做什么，为什么以及如何做。其目的是通过深度拆解过程，提炼出案例中导致失败的最重要的要素，来总结出失败案例中的一些错误的制度和行为，通过对案例的分享和宣传，降低一些低级错误给项目带来的损失。

同样的，这种方式也可以用到我们的产品研发领域，通过线上一些事故案例、来展开深度分析和总结，并分享给团队，从而避免同样的问题在团队其他成员身上再次发生，影响产品和项目的交付质量。

工作中如何去推广和应用 Case Study?

以 Bug 为例，以下几种都是可以通过 Case Study 来分析学习的。

• 产品线的在线服务升级，遇到意外情况，导致升级完全失败或部分失败，或对预期升级进度产生严重影响，这几种情况下，需要进行 Case Study

• 某产品线的新功能上线后，根据各方面反馈，发现由于某些 Bug 或者理解偏差与预期效果严重不符，需进行 Case Study。

• 技术总监 / 部⻔经理 / 项目经理认为需要进行 Case Study 的情况。

当在线服务出现故障或线上 bug 这样的案例后，需要相关产品线的技术经理、项目负责人或负责人组织 Case Study。

组织 Case Study 的形式及参会人

Case Study 的形式相对是比较灵活的，最好的方式就是召集相关人员开会讨论，同时针对不同具体情况可以采用经理和直接负责人当面沟通、邮件讨论等形式。对于时效性来说，一般情况下，Case Study 要求在事故或线上 bug 发生后的三个工作日内进行总结。

会议过程的关注点及注意事项

会议开始前，需要先明确此次 Case Study 的目标，提前确定要讨论的问题，把握好方向，通过设问的方式来引导大家讨论。重点关注意识层面及流程规范方面的问题，并且在会议过程中要引导大家提出具体的、可行的改进方案，最后确定解决方案并督促相关负责人严格执行。

另外，做 Case Study 一定不要一味强调什么客观原因或其他部门的 xxx 问题，不然会议就变成了追究责任和推脱责任的战场，也就失去了它原本的意义了。

最后，做 Case Study 一定要对事不对人，不然就会变成人人都想逃避的屠戮场。相反如果 Case Study 卓有成效我们还要夸赞相关的责任人，为我们提供了这么有意义的案例。这一举动能让员工意识到犯错不可怕，它可以变得非常有意义。

Case Study 产出的文档

Case Study 案例需要撰写规范的案例报告，由项目经理、技术经理或技术总监审阅修改后，分发给参加 Case Study 会议的人员。

持续推进，形成团队习惯和文化

在实践过程中，往往会由于时间问题，导致 Case Study 制度的执行力度不够。这是因为团队还没有将 Case Study 相关联的工程师六大意思（质量意识、求实意识、时间意识、进取意识、团队意识、沟通意识）做到月月讲、周周讲、日日讲。只有让 Case Study 成为大家的一种工作习惯，就不会感受到由 Case Study 带来的压力了。

我的心得

1. 做 Case Study 的本质是解决技术管理中的什么问题 ？

不要掉进同一个坑里两次。为了做到这个，不是靠个人的意识，而是用流程来规避问题。比如清单。

2. 如果团队对 Case Study 的任务比较排斥，根本的原因在于哪里？

有多个方面吧，开会的目的是复盘问题，还是追责? 一旦让人感觉是追责会或者推卸责任会，那就没人愿意开了。另一个就是执行效果，如果开了会跟没开一样，大家都是走过场，那大家也会排斥。

文章链接：Case Study：让线上故障沉淀为团队的经验​

课程链接：