主题：对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.若开发中途需求有变动，需要及时通知到相关人员（前后端开发、测试、运营）