用户反馈流程图

分离需求和Bug

Bug-已分配版本号.html

收集用户反馈：论坛/微博/qq群/贴吧/国外论坛/内测报告

分析Bug的出现的原因

找到原始出处，回复用户关闭的原因(ideepin)

为近期的版本，一键建立对应的tower任务

不稳定重现Bug

不采纳需求

自动建立的tower要有规范

人员：ideepin

进入Bug和需求管理系统后的反馈关闭步骤

无条件测试Bug

否

处理时间长度评估，并标签

建立到需求管理系统

建立到Bug管理系统

不确定能去除的

确认采纳需求

不处理

需求-待分配list.html

需求

指派给对应的UI/UE/Coder

需求-待评审list.html

确认不需要处理的bug

待沟通询问Bug

一周后

需求确认（必须给出初步处理方法）

高优先级

需求-待二次筛选list.html

人员：ideepin完成时间：周一下午2点前核心工作内容：1.去除无效反馈/最初步筛选2.分离需求/Bug3.新建Bug到BugZillar/新建需求到需求管理系统4.关联重复问题5.分类至对应的项目6.联系方式关联和导入7.生成Bug-待二次筛选List.html和需求-待二次筛选List.html

Bug-待二次筛选list.html

不重复

对应项目的产品经理进行筛选

回复用户关闭的原因(自动邮件通知)

不处理Bug

是

第四步：用户反馈评审会议（周三下午）

第二步：用户反馈整理

重复

是否重复

中优先级

对应项目的产品经理为两个list增加版本号标签

最初步筛选去除无效

可能需要讨论的Bug

低优先级

需要填写：测试平台测试版本号重现步骤重现概率预期结果最终结果（为自动建立tower标准做铺垫）

第五步：用户反馈任务分配（周五）

稳定重现Bug

待评估

第三步：用户反馈二次筛选（周二下斑前）

第一步：收集用户反馈

任务处理完成并发布（此处省略若干规范）

是否有用户邮箱

人员：产品经理1.将Bug-待分配list.html 需求-待分配list.html 增加版本号标签（可过滤）2.按版本号的形式，自动建立对应的tower清单(产品经理决定哪些需要现在建立)3.分配任务到对应的设计师/动效师/工程师，并交流4.生成：Bug-已分配版本号.html 需求-已分配版本号.htmlps：1.tower的对应的项目中，只会有最近两个版本号需要处理的任务2.同时\"项目管理\"清单中 会 Bug-已分配版本号.html 需求-已分配版本号.html 的链接 ，方便开发人员随时查看后期版本和进度，规划时间

待讨论/评估的需求

确认不采纳需求

进度的跟踪和记录，协调，交流

处理

Bug

必须含处理时间长度/处理优先级/处理的初步方法

Bug确认

Bug-待分配list.html

联系方式的关联和导入

人员：PM/李楠/夏彬/叶凯胜准备条件：1.所有的Bug必定时QA已经测试且加标签了的2.所有的需求必定是PM初步筛选且加标签了的3.必须有两个list.html作为讨论的媒介核心工作内容：1.确定Bug出现的原因2.最终筛选并确定反馈是否修复/采纳3.确定反馈处理的大致方法（是否具体到UI/UE细节）4.确定反馈的标题---直达需求和Bug4.确定处理/修复的时间长度5.确定Bug/需求的初步优先级

关闭Bug管理系统/需求管理系统上的条目（产品经理必须写上关闭的原因）

回复用户

待评估Bug

Bug-待评审list.html

需求-已分配版本号.html

无法重现Bug

关联已有ID

优先级评定

对应项目的产品经理查看并审核

确定可以去除的

QA测试(梁瑞)

讨论Bug的处理结果

待评估需求

需要下周/后期才能讨论的Bug