PMS需求交付管理

1，针对新功能的开发，如果功能交付出现争议性问题（示例场景：新功能实施不可能需求写的很完全，开发也考虑的不会很完全），当这种场景出现时，微信上与开发先进行沟通并解决（即不立马回退，直接沟通解决问题，遵循1小时原则，1小时内可以解决的暂不退回）
2，PMS功能回退需要有明确的退回说明，不可简单描述，需要同步给开发信息说明退回原因
3，正式环境和测试环境需保持同步，同步数据库进行测试数据库隔离，功能先在测试环境隔离进行测试。如因为某些数据链接写死的原因导致只可以在正式数据库进行测试，那么就由开发提供影响范围，实施提前做好备份，进行功能的测试更新（测试影响数据则还原备份）
4，当实施的需求提交到开发后，开发针对需求需要和实施进行需求沟通时，实施需要及时支持，明确沟通时间。开发针对沟通结果，需要明确回复是否了解和完成日期，如有延期，需要特别说明。
另针对开发进行的要求如下：
1、一小时原则，如果单方连续出现3次，则第3次直接跳过一小时原则按流程处理
2、开发交付的功能要满足【开发标准文档】
3、MES1.0同步修复历史BUG（如还有1.0的bug，可以持续提交上来，会约开发进行版本迭代更新）

PMS类型定义：
需求：
1、功能第一次提出改动
2、新增需求
需求变更：
1、同一个功能，第二次提出改动（变更或补充都算）
优化：
1、速度慢
2、导出卡
3、页面丑
4、操作繁琐
5、开发交付达不到“开发标准文档”（但不影响功能运行）
6、不影响功能，能用但是不好用
BUG：
1、报系统类型的错误（非业务报错）
2、开发提供的更新文件有问题
3、功能用不了，逻辑没实现
4、系统运行过程中突发报错
操作：
1、实施更错环境或更错文件
2、实施记录的BUG经过排查不是开发或系统的问题
3、客户操作错误引起的问题