技术领导力实战笔记2022_26_24_Case_Study让线上故障沉淀为团队的经验
你好，我是农信数字副总裁，数字供应链总经理李玉福。
同时呢我也是一个拥有十五年研发和管理经验的互联网老兵。
目前呢主要负责公司的研发、管理、项目管理、产品运营等工作。
俗话说啊，吃一堑长一智。
一个人如果不能够从错误中吸取经验，那么他无法快速成长。
同样啊一个团队如果不能够从失败中总结，并且沉淀出经验，那么这个团队呢将无法快速的前进。
如何把这些经验快速的沉淀下来并扩散到整个团队呢？我们可以使用一种叫做case study,也就是案例研究的管理机制来驱动团队啊，愿意接受自己遇到的问题，并且呢乐于总结分享经验，建立团队的知识库。
Case study呢实施起来啊，其实并不难，难就难在如何把事情做到位。
这需要我们为团队建立起一种团队交流和分享的氛围。
其中最重要的一点啊就是对待bug的态度和解决办法。
我们都知道程序员的工作内容啊主要分为三部分，第一呢与产品沟通需求，第二系统模块设计，第三开发实现与测试最终发布。
而这个过程中啊，即使是水平很高的技术人员呢，都难免因为在设计方面的缺陷和实现方面的疏忽啊，这对产品技术上线后啊出现一些bug,其中低级的功能bug缺陷啊，往往导致测试阶段段就会被发现并解决掉。
而一些认知啊、集成啊以及环境方面的bug g往往会因为我们缺乏乏验啊出系系统发布线上上针对产上发生的问题啊，如果我们只是简单粗暴的去执行相关的惩罚机制，比如说公开的批评啊、扣绩效啊等动作。
那么对团队技术员员呢伤害性极极大的这会导致技术人员在接下来的工作中呢，因为担心犯错误，做事情啊畏首畏尾，技术上呢也敢创新产品迭代速度变慢，影响整个产研的进展。
另一方面，他们呢也会因为担心影响绩效，不敢大胆的去分析问题，甚至啊会把问题隐藏起来，导致经验没办法沉淀问题，反复出现，影响用户的体验。
作为管理层，如何打造一套团队，乐于剖析问题、分享经验的文化机制呢？这里面就可以用我们前面提到的故障分析管理方法论叫casase study. Case study呢它的雏形啊最早起源于医疗临床试验。
后来呢商学院就把case study啊应用于商业案例的分析，从而呢被大面积的推广啊，尤其是MIT.针对性的建立了财会、创业企业领导力、运营管理、战略研究、可持续发展等系列的商业案例库。
通过案例呢激发学生之间的辩论，来帮助学生模拟在实际管理工作情况下呀会做什么，不会做什么，为什么以及如何做。
其目的呢是通过深度拆解过程提炼出案例中导致失败的最重要的因素，来总结出失败案例中一些错误的制度和行为。
通过对案例的分析和宣传呢，降低一些低级错误给项目带来的损失。
同样的呢，我们可以把case study完美的复制到软件产品领域，通过线上的一些事故案例啊来展开深度的分析和总结并分享给团队，从而呢让团队成员对于事故有认知，避免。
同样的问题啊，在团队其他成员身上再次发生影响产品和项目的交付质量。
另外呢还要注意一点，在实际的产品研发过程中啊，工程师项目经理不能够只关注结果，还要关注过程是否完美。
小项目当中呢暴露出来的问题不及时的弥补，到了大项目啊往往会酿成重大的恶果。
Case study呢要求尽可能全面、深入的去剖析问题，发现问题的本质，及时改进并沉淀经验，最终啊保证工作质量，了解了case study的背景和价值。
那么接下来呢，我们来说一说其在应用过程中的一些具体环节，以及如何在工作当中去推广。
既然是case study,那一定是先有case什么情况可以被当做，是case来讨论呢？就拿线上bug这个场景来说吧，我列举了几种需要case study的典型案例。
第一呢，某产品线的在线服务升级，遇到意外情况导致升级完全失败或者说部分失败，那或者说对预期的升级进度啊产生了严重的影响。
这几种情况下呢需要进行case study.第二呢，某产品线的新功能上线后啊，根据各方面的反馈发现，由于某些bug或者说理解偏差与预期的效果严重不符。
那么这种情况下呢，也是需要进行case study.第三点，技术总监部门经理项目经理认为，需要进行case study的情况，当在线服务出现故障，或者说发现线上bug.这样的case发生后啊，为了探讨意识、流程、技术等方面的不足，总结由此带来的经验教训，探讨可能的具体改进措施，需要相关的产品线的技术经理啊、项目经理啊或者说负责人来组织case study case study.它的形式呢相对来讲啊是比较灵活的。
最好的方式呢就是召集相关的人员开会讨论。
同时呢针对不同的具体情况，也可以采用经理与直接负责人当面沟通、邮件讨论等形式。
对于时效性来说啊，一般情况下，case study呢要求在事故或线上bug发生后的三个工作日内进行趁热打铁嘛。
及时总结，针对每一次项目的case啊，与会人员呢应当是阿d项目组所有成员testing项门的相关人员，PM部门的相关人员以及项目经理和技术经理。
技术总监认为，其他应该参与的有关人员。
会议开始前呢，需要先明确此次的case study的目标，提前确定要讨论的问题，把握好方向，通过设问的方式呢来引导大家讨论重点、关注意识层面以及流程规范方面的问题。
并且在会议过程中呢，要引导大家提出具体的可行的改进的方案，最后啊确定解决方案，并督促相关负责人严格执行。
另外呢还要注意case study,他的最终目标呢是修炼内功，精益求精。
所以一定不要一味的强调一些客观原因啊，或者说其他部门配合方面的问题。
不然啊会议呢就会变成追究责任和推脱责任的一个战场，也就失去了它原本的意义了。
最后强调一点啊，case study呢一定要对事儿不对人。
不然呢就会变成了人人都想逃避的屠戮场。
相反，如果case study卓有成效，我们还要夸赞相关的责任人，为我们提供了这么有意义的案例。
这一举动呢能够让员工意识到犯错并不可怕。
它可以变得非常有意义，正式的召集会议形式的case. Study呢应该由直接的负责人或者说负责人呢啊去撰写规范样式的case study报告，并且由项目经理啊、技术经理或者说技术总监呃，审阅修改后呢，分发给参加case study的啊参会人员以及ID项目组成员抄送给APP部门，负责APM更新汇总的负责人，并且由该负责人啊提交到APM中的APP知识库对应的栏目中。
如果说是其他部式的case, study呢啊需要由当事人或者说负责人啊，随后撰写总结文档，以邮件的形式呢发送给所在项目组成员。
Case study呢它的改进计划应该由呃，相关产品线的项目经理或者说负责人监督执行。
根据各个部门的相关规定啊，需要将执行情况汇总到项目经理工作周报当中。
这里有一个产出文档示例，你可以在文稿的附录当中执行。
实践过程中呢，往往会由于时间问题，导致case study制度的执行力度不够。
这是因为啊团队还没有将与case study相关联的工程师的六大意识做到月月讲、周周讲、日日讲。
只有让case study成为大家日常工作当中的一种习惯，就不会感到由case study带来的压力了。
这里总结一下，在我们公司啊kiss stardy给团队带来的不仅仅是对于问题和故障的重视，更多的呢是给团队带来了一种开放共享的学习成长氛围。
很多公司呢都推崇技术文化，我对技术文化宏观层面的感知呢就是开放向上、有激情，它是一种引导团队，积极向上的隐形的力量。
通过日常的一些行为动作去贯彻和落地，最终呢体现在每个人的行为规范上。
对于细节的处理啊就是文化的体现。
技术管理者想要打造积极向上的工程师文化，就需要打造这样的一种环境，找到一些关键的、有意义的案例，让大家在这个环境当中呢自由开放的交流。
我觉得case study就是这样一种非常有趣的活动，你不妨尝试一下。
最后呢给你留两道思考题，你来思考一下，做case study的本质是解决技术管理中的什么问题呢？如果团队对case study的任务比较排斥，根本的原因在哪里呢？欢迎你在评论区留下自己的思考，也欢迎你把这节课分享给有需要的朋友。