2019-08-04

优惠券迭代项目复盘

****回顾目标****

项目的意图是什么？

从优惠券方面：
1、刺激用户付费
2、减少运营成本

从订单改造方面:
1、将越来越多的购买渠道、购买方式、支付类型、优惠信息等进行落地
2、为财务结算提供基础

项目想要达到什么目标？

1、7月28日前将优惠券、订单改造、及一些小需求上线
2、上线后不出现影响用户使用的问题

我们制定的计划是什么？

1、各端进行架构设计、排期
2、开发10天左右、测试14天左右
3、开发提测后，大部分人立即转入小天才迭代，其他人负责配合测试改BUG
4、26号进行上线

事先预想到的阻碍有哪些？

1、开发时间紧张，订单改造未必能按期提测
2、优惠券与小天才衔接紧密，可能造成优惠券修复BUG人力不足

****评估结果****

实际发生了什么阻碍?

1、与直播组服务器资源冲突
2、订单相关需求缺少需求评审
3、订单改造涉及直播组同步配合
4、订单改造需要迁移的数据量较大，脚本缺少正式的review环节

在什么环境下发生的阻碍？

1、开发周期短
2、需求细节不明确反复确认
3、开发人员状态不好

最终结果如何？

1、项目按时提测，但质量较差，各端总BUG达到上百
2、项目按时上线，但出现了较多的数据问题、以及少部分逻辑问题
3、团队成员情绪相对失落

****分析原因****

为什么没有高质量的提测？

1、提测的目标本质是两点：“高质量、按期提测”，但本次开发过程中，研发人员更关注按期提测，而将质量至于其次，因为工期的紧张，导致
（1）缺少前期对原型细节的观察和设计
（2）缺少对某些方法及整体流程的自测
2、本次优惠券订单改造涉及方法众多，还涉及到两条业务线同时协作处理，由于在前期两条业务线之间没有协调好相关近期计划，导致无法同步完成

为什么上线后出现数据问题？

1、由于迁移新老订单表的变化很大，迁移脚本涉及到新老数据的多种场景、多种状态、多种类型、多种匹配，以为简单实为复杂，缺少多人review环节
2、缺少此处的需求评审，很多都是即时询问即时改造编写
3、除了数据迁移外，还需要对老数据进行各种状态及类型的处理，但这部分考虑太少
4、上线后，直播组和APP组之前的一些常用脚本，在没有修改的情况下继续使用，导致线上数据混乱

****总结经验****

如何避免缺少必要的环节？

将一些极容易忽略的必要的环节变成规则，规则强制执行变成红线，拿这次的迁移脚本来说，如果不经过2-3个以上的人进行过审，坚决不允许执行，即使延期上线

如何让研发人员对短时间大工作量的迭代不再抵触？

1、给研发人员讲清楚明确的迭代意义、能获得哪些收益、预期的目标是什么，给予正向反馈
2、将项目进行横纵拆分，一个人负责独立的一块，从上层业务到底层架构，促使大家有责任感和成就感
3、尽量不进行狠压缩时间，避免精神状态过度疲劳

并行迭代如何合理安排？

如果人员穿插多个迭代，一定不能在A迭代的提测日期就安排转入B迭代，一定要留有充足的时间和人力解决BUG，因为出现的问题总是比你想的多