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. 复盘的模型
记录了一些复盘模型，太偏向于理论，暂时没什么理解，就不一一赘述了，有大佬的话，欢迎指点下。
各个模型
具体的课程中的复盘操作，落地方案，我也大概梳理了一下，但是贴合项目组太深，包含业务信息，而且没有在项目组实践，等下周在项目组中复盘，观察一下结果之后，再抽象出来分享一下
网友评论