跟着高手学复盘_初步理解

2021 年春节假期之后第一天上班，对年前的项目进行收尾，想主导一次项目复盘，但是主持的复盘效果并不好。于是，就找了极客时间的《跟着高手学复盘》 ，可以落地的方法论。

1. 复盘项目概述

2021 年春节前，接了一个有点难的项目，经历前期接近一个多月的 N 次需求评审，三版才敲定原型，设计评审，中途测试人员调整，后台开源框架引入，新协议 grpc 的全面使用，和后台大佬认知差距过大，以及前端人员不足的情况下，发布了一个内部项目。

由于是内部项目，上线之后用户暂时为 0，从运行半个月的情况来看，主体功能正常，数据暂时没有发现异常，这么来看的话，皆大欢喜，算是一次成功的发版？8 个遗留 BUG，两个功能未实现，一个技术问题，五个没有时间解决的，以及迭代过程中的一些其他的问题。觉得需要主导一次复盘，但是这个项目组的人员都是大佬级别的，复盘效果不好的话担心浪费大伙时间（2020 年主导过几次其他项目的复盘，效果差强人意，多数开成了批斗会），于是就找到了《跟着高手学复盘》。

学习笔记（思维导图），课程内容比较经典，有些就直接复制，自己慢慢消化，今天和大家聊聊看完课程的收获。

2. 复盘的常见问题

2.1 复盘变成了甩锅和背锅

截取了去年某项目复盘的一张 PPT，如下所示：涵盖了测试情况，上线情况，存在不足，还有项目组其他角色暴露出来的一些问题

 

一场复盘下来，足足开成了批斗会，以至于上一次复盘的时候，产品负责人说他知道问题在哪，在外被项目批斗，在内被领导批斗，不想在项目组内再来一次了。但是，批斗，甩锅，背锅，不是复盘的目的啊

 

专栏中是这么描述这个问题的：不以追责和惩罚为目的来做复盘，把重点放在对未来的优化上，才可能拥有 “群众基础”，这是复盘的前提。

将心比心，大部分人都不愿意承认自己的失误的，只想在别人身上找原因，真的有没甩过锅的测试？

2.2 不知道怎么得到有价值的复盘结论

我之前主导或参与的复盘，项目结束之后，相关人员聚集相互商议，类似于 “茶话会”，各自阐述在迭代中的得失，哪些做的好？哪些做的不好？

相互批斗之后，然后，商讨出一些问题以及解决方案，例如：遗留 BUG 该怎么管理？测试报告输出方式等指出一些问题，但是这些结论怎么做，落地效果如何，不怎么好。

2.3 复盘结论得不到别人支持

复盘结论得不到别人的支持，复盘结论落地困难，说多了都是泪。

3. 复盘的目的

针对于复盘中的常见问题，在专栏中找到了个人认为的答案。

3.1 对未来的优化

甩锅，背锅这个方式不可取，一次甩锅一时爽，难道还能每次都甩锅？遇到问题，解决问题，不解决的话，会因为这个问题栽更大的跟头（解决不了就抛给能解决的）。

复盘的目的更多是对未来的优化，防止下次迭代同样的问题重复出现，例如 ：分页不传参数的 BUG，上次迭代出现了三次位置，不长记性的话，下次迭代出现了四次，这种问题不解决，发现 BUG，提 BUG，接受 BUG，验证 BUG，摆明了是重复工作量嘛，取其精华，去其糟粕

3.2 对认知的修正

这次迭代收获最大的就是改变了我对几个功能点的认知。
先说认知这回事，个人理解迭代是个结果导向性的工作。需求就是那个结果，如果大家对某个需求的结果认知一致的情况下，中间的过程就各自实现就好了，反正结果是一致的，但是事实，不太如人意啊

例如：用户登录的时候用户名是否需要区分大写？

之前的经历告诉我，用户名是需要区分大小写的，这次迭代的需求也没标注这块，个人觉得用户名区分大小写应该是个常识性问题，然后测试过程中发现不区分大小写，提了 BUG 之后，研发说就不区分，就找产品确定，产品被研发说服确认用户名不区分大小写，然后经过两个小时的理论，我也被说服了，用户名不需要区分大小写。

项目迭代过程中，会存在一些隐形需求，就像上面的用户名大小写，单点登录，异常提示等常识性问题，但是就是这种，这些常识性问题，你的常识和我的常识是一样的么？

会出现同一个需求，一千个人一千个哈姆雷特，理解的结果都不一致，实现的功能肯定是不一致的，所以，复盘就是对一部分错误认知的修正 。

4. 复盘的模型

记录了一些复盘模型，太偏向于理论，暂时没什么理解，就不一一赘述了，有大佬的话，欢迎指点下。

 

 

---

具体的课程中的复盘操作，落地方案，我也大概梳理了一下，但是贴合项目组太深，包含业务信息，而且没有在项目组实践，等下周在项目组中复盘，观察一下结果之后，再抽象出来分享一下