主题：对XH系统 V0612版本的复盘

使用到的模型：AAR（After Action Review）

                         项目管理模型——PDCA(Plan Do Check Act)

                         目标制定模型——SMART（Specific Measurable Achieveable Related Timed）

时间：2019年6月24日

地点：地球会议室

参会人员：PM+开发+测试

一、目标回顾

目标：完成Aandroid、Ios、PC端本期需求的上线计划（6月26日）

里程碑：6月12日需求评审、6月13日SubTask拆分、6月20日开发提测、6月26日  UAT测试 

二、目标达成情况

截至 6月24日80%需求已经测试通过，10%需求当日提测，10%需求要延期至下期。

现状：        

1.提测时间延期，原计划20日全部提测，截至当前仍有部分未提测

2.出现部分需求发布延期的情况

三、原因分析

1.需求阶段

 （1）未指定到对应开发

    引申出的思考问题：需求评审阶段，需要由PM拆分出前端工作与后端工作么？还是应该在拆分SubTask阶段，由开发自行拆解与指定

（2）因沟通问题，导致PM与开发对同一问题的理解有歧义，在开发后期才发现，提出时间较晚，虽然当天给出了结论，但因需要业务同意等问题导致开发延期

    解决方案：为避免后期出现类似问题，对于有与外部系统配合的需求，需要由PM前期沟通方案可行性，确定后，再拉会议（PM、开发）详细确认对接事宜     

（3）出现未考虑到的某种细节情况（签名问题），在测试阶段发现，  以bug提出。

    解决方案：a.PM尽可能细致的做需求说明和举例   b.除需求评审外，增加开发评审与测试用例评审，若三个评审中均未发现的问题，在开发测试过程中出现，则当作优化需求（视严重程度及影响范围）。

2.设计阶段

    交互、视觉同学并未参加。视觉交付时间较晚，对项目进度有一定的影响

3.开发阶段评估

【工期评估】

    时间不够，对需求的理解程度不深，主要偏重于浅层的实现层面，对业务场景相关思考较少，导致有些需求在开发过程中才发现工作量评估不够。

【需求指派】

    现在的需求认领，基本由固定负责某模块的开发同学来做，出现不均匀的情况。

    引申思考：如何做到“雨露均沾”，开发内部“轮岗模式？”

【前后端配合】

    建议：subtask由前后端开发同学+PM+测试共同参加

【突发状况】

（1）人员变动（请假）导致接口提供较晚，该需求无法正常上线

    引申思考：在团队合作中，是否该避免成员间的“不可替代”性

（2）因前期评估不足，导致过程中发现需求实现方式太重

4.测试阶段

（1）在QS上并未有开发自测的记录

（2）某些影响下面测试进度的bug不能及时修复及时提测，影响测试进度

5.上线前期准备阶段

 运营、PI未参与此次复盘        

四、复盘总结

1.项目流程调整（先进行完整的需求评审，再出交互与视觉稿）

2.本次复盘，人员上不齐，缺少UED、运营和PI，时间过长（2个小时）

3.问题不够聚焦，比较发散，容易陷入到某个需求点中，不应该追求大而全（可以先从项目进度和项目结果（实现层面）入手。再详细分阶段复盘（需求阶段——开发测试评估阶段（拆subtask阶段）——开发阶段——测试阶段））

4.复盘的核心应该是“有则改之，无则加勉”，本次过多的探讨“不好的地方，如何改正”，做的好的地方提出来，让团队成员继续保持，应该是同等重要

5.同2，完整的复盘应该叫上运营和PI同学（最好也叫上交互和视觉），复盘下上线前的准备工作是否按计划执行（或上线后有什么推广或运营规划——PS:这应该是在在项目周期内制定好的，不该在复盘阶段才提出）

---

PM自查：

1.需求不明确（能给到原型图的尽量给到）

2.若出现与外部系统对接的时候，需要单独再拉会议做详细沟通（不同阶段下双方如何交互）

3.若开发中途需求有变动，需要及时通知到相关人员（前后端开发、测试、运营）