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