关于如何做复盘请移步：新晋总监生存指南四——项目执行指南，如何复盘部分
从去年接手技术团队后便开始推行CaseStudy（复盘的一种），旨在收集技术团队日常线上问题，组织建设问题的解决方案，后续落地了不少技术沉淀、流程机制，感觉效果不错，自2020年9月推行Case Study机制以来：
- 共完成290余例case的CS
- 形成100多项流程规范/工程基建/踩坑经验积累的改进项
- 沉淀了30多个经典案例供研发童鞋学习
- 并以此建立了不断完善的问题标签统计分析团队的薄弱项
推行顺利原因是机制本身没问题，而我又是大leader，势能高做事容易。
后面担心会演变成盯着效果就好，不参加便流于形式，便逐渐变成了选择性参加，更多的浏览CS文档，如果发现CS文档不行就要求重新做CS。
半年多时间下来，CaseStudy机制这种复盘基因算是种下了，大家也不会认为是在问责，而本身也接手了一块产品领域工作，便想将CaseStudy在整个产研推行。
因为机制已经比较成熟，便直接交给了效率leader落地，却收到了不好的反馈，大概是：产品同学不愿意CaseStudy。
Review了效率同学的工作后，发现其本身工作缺漏不少，有点懒政的意思，于是从新安排了工作：
1）产品同学的CS不同于技术同学的CS，CS模板需要适应与其团队；
2）之前的案例都是技术案例，去找关系较好的产品，协助他写第一个CS作为案例，这种demo至少需要3个；
3）写一份正规的邮件，以质效团队的身份发出去，首先说清楚CS的目的，强调绝对不是问责（其实也会问责），主要目的是改善团队；其次是将技术团队半年的CS成果发出来，并且说清楚几个技术leader都是CS的常客，而他们的绩效依旧很好；
4）在产研大群同步邮件内容；
5）第一次正式CS前，提前一天在大群发消息同步，并邀请大leader参加；
6）然后就是具体CS会议正常开，记录会议todo；
7）同步会议纪要以及todo到群里，todo需要同步更新至产研周会todo，每周跟进；
8）......
随后，CS机制开始在产品团队正式落地，第一次CS结束后反响较好，相关同学还决定将一些典型CS做成PPT给团队分享......
所有如果有一套比较好的方法论想要在新团队落地，可以使用这套路径：
1）为机制本身准备充分的说明材料，要充分的考虑人性，比如CS会被认为是批斗会，扣绩效的手段，便需要打消大家这种疑虑；
2）除了说明材料，还需要准备该机制之前取得的成绩，最好离大家近一点；
3）成绩相关案例是过去团队的实践，在当前环境下的前几次落地要亲自抓，协助落地；
4）找势能高的同学背书；
5）机制落地后要有持续好的反馈，比如对于CS这个机制，todo需要落得下去，否则机制就落于形式；
6）持续迭代机制；
