1

Problem：xxxx

Action:

\1. Problem：信息同步不全面，有时会有遗漏的人或者环节。

Action: 为了保证信息同步给所有相关人员，避免遗漏和同步不到位，大家将通过邮件进行重要信息的同步，TT和微信将作为辅助手段。请大家关注邮件。

\2. Problem：问题/bug的反馈和管理目前存在问题，感觉如果所有问题和bug都反馈到big mogu里会比较乱且打扰大家的工作。

Action：为了保证质量问题能有效的跟踪解决，将引导大家使用jira来报bug：问题（凡是客户端／后端有问题需要修复的）反馈到JIRA，新需求（哪怕不确定要不要做，只要是对业务有帮助）和产品经理沟通&提WIKI，紧急故障提BIG MOGU大群。具体执行将由七心的质控团队出个问题和bug反馈制度，来具体定义下什么类的问题反馈到哪里以及反馈的流程，逐步引导大家按照规则来反馈问题。质控团队将负责对运营同学进行jira和wiki的使用进行讲解和培训，以及jira问题的整理。

\3. Problem：2.4版本的内测感觉参与度不高，比如周末两天没有任何问题反馈，上线后又有很多问题被报出来。

Action：本次的内测是针对2.4大改版的，并不是常态的流程。所以app的质量还是首先要通过常规的测试和自测流程来保证达到合格的产品质量。针对本次内测大家感觉到除参与度不太高的问题，下次将尝试通过改换组织形式加强对参与内测同学的组织来提高参与度，比如蘑菇街之前分批集中起来内测来收集问题。

\4. Suggestion：建议产品开发和UI能够坐的近一些，能降低很多沟通成本和减少信息不同步问题。

\5. Problem：测试环境不稳定的问题，导致测试效率低。有些基本的测试数据是否能自动从线上copy到测试环境，降低测试准备数据的充分劳动时间。

Action：后端开发同学对测试环境调整时，将会提前通知测试同学，避免进行无效测试。如果本期测试需要拉取线上数据至测试环境，测试可以在需求排期时提出要求，开发将进行相应工作的评估和准备。

\6. Problem：后台上线修复问题比较频繁，因为上线一次会占用一定的时间和资源，希望能控制上线频率。

Action： 依据质控发布的故障修复规则执行（规则质控团队将在近期明确和公示），对于需要走紧急修复上线流程的线上故障应该按照质量要求及时修复上线。

\7. Suggestion：Prd如有不清晰或者有问题的地方，请开发和UI同学尽量能够在前期指出，产品同学将进行快速的明确和完善。

\8. Problem: 产品文档沉淀不足，有些公共逻辑（比如语言切换逻辑）文档和规则缺失导致有些问题反复沟通确认。

Action： 产品将在wiki里逐步完善Q&A，公共逻辑的QA，需求池，prd产品文档，都陆续整理到wiki上 。

\9. Problem：由于测试同学大部分是新人，后台产品的隐藏逻辑较多比较复杂，会导致一些逻辑由于不熟悉可能遗漏掉。

Action：产品同学可以对测试同学进行培训，让新测试同学尽快熟悉所有细节逻辑。