同样，先回顾下昨天的文章：
众思v2.如何建立Bug反馈机制？
直接说下我的看法，我认为，想让整个Bug反馈合理进行，首先一个大前提是，
产品经理需要主导和把控Bug的提交情况和流程
。具体做法如下：
1、
扩大沟通渠道覆盖面
。也就是说，产品经理需要主导
建设、拓宽、宣传用户反馈Bug的渠道
。举个例子，可以由产品经理主导建立用户反馈群，这个群里的成员，可以由技术、客服、产品经理、测试人员，制定规则，只要有用户反馈，首先丢到这个群里，由产品经理判断，是Bug还是需求还是用户操作失误。如果确认是Bug，@相关开发、测试人员解决。
2、
明确人员权责
。这一点是要解决“反馈过多导致信息混乱”的问题，如果谁都能在群里丢反馈，一方面存在重复反馈，一方面处理效率较低。比较好一点的做法是，每个业务对接部门，指派特定的用户反馈处理人员，这个人就负责某条业务线所有用户反馈的收集，包括内部的和外部的，然后统一处理，统一反馈。
3、
同步Bug处理结果
。很多时候Bug并不能立即解决，需要排期开发，但客服人员并不清楚哪些问题什么时候会解决，哪些是暂时解决不了的，只能反复询问。因此需要产品经理建立有效的Bug同步机制，比如利用石墨文档，利用teambition，利用wiki对所有反馈进行实时更新，并开放给群内成员随时查看，让大家对反馈进度有所感知。
4、
规定反馈模板，提高反馈效率
。这个属于小技巧，我之前的一篇文章也提到过（
【产品日思录】vol31.怎么向产品经理提Bug？
），就是给所有反馈人员一个
固定模板
，包括反馈时间，所在环境，所用设备，bug出现步骤，当前登录账号等等，尽可能多地帮产品、技术定位问题，提高处理效率。
OK，以上4点，就是我对“建立合理Bug反馈机制”的解决方案，那么，大家又是怎么看的呢？
==
=====我是分割线=====
==
下面再分享一些大家的精彩观点：
@蓝莲花
之前团队规模小，反馈bug确实是直接找到开发，执行效率确实高，一般改完后开发人员也会及时反馈，但确实出现很多了问题，文章中也提出来了。后来团队规模变大，成立了测试部门，目前在bug处理上，一般是先采集用户反馈信息，畅通用户反馈机制，然后根据用户反馈对bug做一个分类分级，并且通过内部工具记录bug及关于该bug的相关信息，如机型、操作系统、版本号、详细问题描述，然后指向测试人员，测试人员通过提交信息进行问题复现，根据bug类型，指向相关人员，如产品设计人员或开发人员，然后由相关人员进行处理并对bug进行问题分析记录，处理完成后指回测试，进入回归测试后，再反馈bug提出人员，确认已解决，该bug关闭，同时给予用户反馈。另外，过程中也会对bug优先级进行评估，严重影响用户体验的会第一时间处理。目前开展还算顺利。
@Andy山谷
首先，对bug类型进行标记，按照系统软件、卡顿性能等等进行分来收集；对bug的来源也进行标记，看看反馈来自于普通用户还是专家用户；对bug的重要程度进行标记。 其次，我觉得应该建立反馈筛选机制，去除那些无意义的提交。 最后根据重要程度进行排序，挑出Top5进行评估，讨论哪些是因为技术疏忽并且可以修复，哪些是因为产品设计思路，需要改进或者重新设计。
@💦 💦 💦 Jor
我们团队小，18个人。统一通过禅道提交，再由产品，测试指派到个人。
@戴彦清
说到这个都是泪啊，因为公司太小，测出来bug后几乎是测出来几个，直接和程序员说了，程序员就给改了，改完后，就继续测，虽然效率很高，但总觉得做得不规范
再次感谢大家的回复~我也学到了很多，希望也对你有所启发哦~
