问题回复分析和优化方案
2.1 版本开始前出现的问题
问题：一审二审评估万时间后业务将预期上线时间提前了7天
原因：业余为了冲本月GVM，需要提前上线，否则来不及（原定29上线）
解决方案：压缩时间，拆分版本
优化方案：冲GMV的营销产品需求，需尽量规划在当月15-20日之前，否则有时间被压缩被要求提前上线的风险。
2.2版本内出现问题
业务类：
1，问题：新商户号有使用门槛，临时换为老的
原因：微信申请流程规则不熟悉，之前未留下交接文档
解决方案：改用老商户号，养新号
优化方案：申请微信账号前注意查询新号的使用显示，如果有新号需求尽早开始申请
产品类：
问题：数据维护没有和测试沟通。
原因：忘了通知测试。
解决方案：改好后告诉了测试。
优化方案：了有数据维护需求时，及时通知测试，并且更新在原型。
问题：需求文档存在部分图文尽量标明注释不清晰，出现了理解偏差
原因：需求文档存在部分细节不够完善
解决方案：讨论完毕后补充
优化方案：记录遗漏的内容，总结出容易遗漏的点，下次写文档时对照检查。
问题：如设计需求变更，需及时全面的更新需求文档
原因：只在设计稿标记，未在原型标记
解决方案：无
优化方案：同步更新并标注变更
项目管理/产品类：
问题：项目排期交叉手头正在开发一个项目，另一个项目组有需要营销这边配合，导致没精力去研究新的需求文档原因：需求排期过于紧凑，没有预留空间
解决方案：加班
优化方案：排期时规划好，单个人员尽量不重叠项目，如果已重叠，则需要预留出更多的时间。
原因：开发过程中评审了新需求
问题：PU听返开始未考虑，后来发现钱包是一个，增加了工作内容
原因：不是同一个开发，项目不熟悉，没有预留交接时间
解决方案：加班改
优化方案：评审阶段叫上可能是涉及到的其他项目人员，预估风险，如有耦合需对耦合的项目做处理。
通用的功能抽象出来，所有项目复用。
2.3版本后出现问题
业务类：
问题：大B渠道返现没有走线上，钱包多出399/人
原因：大B参与方式过于特殊，未走线上，线下数据被遗漏
解决方案：维护清理数据
优化方案：
参与活动的业务方必须线上有数据，以免出现对不上账的问题。
校对历史数据，全面检查一遍。
提前做看板和报警机器人
定期和业务团队同步信息（钱）
没有后端校验最后一步短信验证可跳过通过接口刷
问题：活动上线后临时修改官方活动套餐，前期需求已确认过
原因：原型没看
解决方案：维护数据
优化方案：让业务方群里公开/邮件/签字确认
问题：上线后业务对H5页面交互有异议
原因：原型没仔细看
解决方案：协商后拒绝部分需求，部分二期修改
优化方案：让业务方群里公开/邮件/签字确认
问题：配置服务号菜单，友盟参数格式不对，导致无法获取套餐ID
原因：规则不熟悉，加参数未和产品沟通
解决方案：和产品沟通后修改
优化方案：提前告知产品方
问题：奖励规则漏配了套餐（2次），开发维护数据
原因：不够仔细，没有留到发布后，回家自己配置的
解决方案：维护数据
优化方案：在公司配置
问题：运营临时改需求，临时说客户端要兼容，之前再三确认过
原因：业务没想好，信息没在业务部门内部同步
解决方案：客户端一期未支持。二期支持了主页面访问
优化方案：需求阶段和所有业务方同步确认
可以加二次确认，让第二个人检查一次后才可提交（活动配置）
Crm功能：配置的不一致的时候做提醒
开发类：
问题：写字营banner没有测试，前后端都发布了
原因：前端：和服务号同个分支，漏隐藏了
后端：未拆分支
解决方案：修改后再次发布
优化方案：git分支规范、版本分支独立，避免先开发再拆版本。
一审和业务确认好时间
问题：友盟埋点有问题，看不到事件。
原因：埋点未测试，友盟什么时候挂的无人知晓
解决方案：临时改为自己埋点
优化方案：以后to c项目都自己埋点，评审时计入工时。
问题：开发时间紧，并行开发需要频繁切分支，导致git提交记录过多
原因：人员分配资源过于紧张那边
解决方案：git提交记录过多
优化方案：避免一个版本测试一个版本开发，避免交叉
H5统一版本号
问题：临时改动过多
原因：项目时间过于紧张
解决方案：加班加点改
优化方案：记录修改的点复盘
安全类：
问题：万用验证码被泄露给运营（一个人）
原因：疏忽了
解决方案：
优化方案：换万用验证码，再次提醒项目人员
审核给固定账号，app和小程序
2.3表扬
有开发都处于过饱和的状态，没有任何delay的情况出现，顺利完成整体任务。
2、处理异常突发状况处理比较及时，第一时间修正
3、为后续的迭代预留了空间。
2.4各位畅所欲言
1，老数据维护记录在需求文档，需要测试，尤其是钱相关，需要开发测试和产品一起讨论
2，大版本的时候每个端需要做的事情列check list，避免互相不知道的情况（主要指营销线和客户端各个端）
3，开发过程中变更要全部进入文档，大小变更。
有变更最好一起通知，开发和测试都要在。（逻辑细节遗漏导致）
4，提测期间同步重大的bug，早会同步测试进度
5，早会：自己先拖好任务，会上直接和相关人员讲昨天做了什么和今天做什么，方便对接和联调。
6，两个版本的需求，如果要同时上要同步，写到文档。
7，业务需求对接时就要提提数据需求，包括楼下直销电销投放不接受上线或者测试时提数据需求。
8，一审评确认的产品需求，二审技术评审。项目开始前尽量准确评审。无论是否涉及前后端，都要叫上，需要有技术评审，相关项目需要在二审确认是否涉及到自己的项目。
9，不确定的需求评审会上直接向产品提出质疑。
10，一审前私下提前确认技术可行性，一审评审确认的需求。不在在会上确认开发可行性。
11，项目启动邮件第一时间发出。
12，重要的会议记录记录好，写到群公告/邮件。
