4. 需求不明确，前后不一致
问题描述：需求不明确，特别在一些边界，各端统一上
问题分析：
A. 交互文档经历6任交互，最后一任交互只参与两个模块的定义，现任交互对于以往交互了解不够深入
B. 产品提测时，交互验证不足
解决方式：
由于项目已提测，因此在整个周期里，对于交互需求方面的疑问直接找相关人员去确认。
在后期的小版本中，我们把这类问题尽量控制在提测之前（详见小版本里的改进与问题）
5. 测试和开发信息不对称
问题描述：测试获取到的消息，与产品实现的方式不一致，如：有的功能定义了，但产品并未实现或实现方式与定义不一致
问题分析：
A. 在开发阶段，测试并未参与讨论需求，还在其他项目里
B. 需求重新确认后，没有及时通知测试
解决方式：
强调消息需要通知到测试，现在阶段，如果因这种类型而引起的问题，将建ticket，指派给相关人员
小版本里的改进与问题
现存在问题：
1. 现对Release版本会做RC checklist, 进行最后版本的质量控制，
但会存在一些问题，在小版本提测时，就已经存在，而冒烟测试是测不到的，在最后做checklist时，才发现
改进点：
1. 需求疑问在提测之前尽量提出，并且通知到开发，在开发阶段便把该问题解决
测试在开发阶段跟踪产品进度
在写测试用例时，就把问题抛出。
2. 提测流程：
对功能方面的ticket，交互在提测之前便在开发机器上验证，通过后再提测
把不符合交互预期的问题，在提测之前更改，节约了时间，避免问题在提测后才提出
