關於如何做覆盤請移步：新晉總監生存指南四——專案執行指南，如何覆盤部分
從去年接手技術團隊後便開始推行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）持續迭代機制；