笔者分享了自己处理badcase的过程，完全完成办案流程后基本形成闭环，避免成为处理问题的“麦克风”。
一个产品经理在日常工作中不可避免的内容就是处理业务badcase，但往往在收到用户反馈后，PM会不自觉地把自己的角色变成很多R&D口中的“麦克风”。
这里举个例子:
反馈人:XXX本地功能不好用/有XXX问题。
PM:(收到问题后，直接把问题截图发给R&D处理)
R&D:我试过了。没问题。
PM:(问反馈人说没问题啊，再试试)
反馈人:还有一些(再次截图)。
PM:(收到反馈人的第二次反馈后，直接再次截图用户的反馈进行R&D处理)
R&D: …
如果你在处理badcase的过程中有“麦克风”的经验，那么你必须改变这种问题处理的思维模式。时间长了，这个麦克风的作用很容易被pass或者优化，也很难提高你的业务能力。
今天给大家分享一下我自己总结的处理流程，主要分为以下六个步骤:
接下来，详细解释每个步骤的描述和注意事项:
很多时候PM收到的用户反馈只是一句“XXX功能不能用了”。PM收到这句话后想干什么？
我们要搞清楚问题是在什么条件下发生的:什么用户，用了什么设备，什么场景，什么流程，发生了什么问题，造成了什么结果？还有其他场景出现吗？
只有充分理解了这些问题，才能说“清楚完整地陈述问题”。
二、亲自验证问题存在的真实性用户反馈的问题是真是假？真的存在吗？是用户的手机吗？还是网络不好？还是在修改系统平台时遇到公司背景？......我必须自己验证，自己测试，验证问题是否真的存在。
排除个人场景中的异常情况，否则可能没有问题。听取用户反馈并直接向R&D汇报；如果R&D测试后没有问题，那会让你很尴尬。
三、了解对应功能的整体流程有时候用户反馈问题的功能，PM也不知道具体怎么用。在复杂的系统下，每个场景的流程往往是不一样的。
当PM不知道如何使用流程时，很难找出问题的原因。尤其是对于中间刚接手业务的PM来说，更需要了解业务，熟悉业务流程。你可以关注之前产品需求文档(PRD)中的业务流程图。然后，自己操作几遍流程图，或者多和业务R&D聊聊业务流程，快速掌握自己负责的整体业务流程。
四、排查问题可能产生的原因并给出对应的解决方案找出问题的原因有点困难。判断是以熟悉业务为前提的，常见的不良案例可能是参数缺失、参数传递不正确或其他流程环节问题。PM在处理badcase的过程中，最大的价值就是提炼出问题可能的原因，并在分析原因后给出相应的解决方案。
五、找对应的研发或相关人员去解决修复并自测当一个PM在处理badcase寻求R&D沟通的问题时，除了完整清晰地陈述问题之外，如果能直接给出RD造成的可能原因，并给出相应的解决方案，R&D一定会给你的表现一个惊喜。
第四步:很多PM确实做得不好，R&D也会吐槽产品像“麦克风”。因为调查的原因在你面前，R&D人员可以更快地定位问题，大大节省了调查时间。
另外，在研究并修复问题后，一定要自己测试，确保问题已经完全修复。
六、告知给反馈人及相关人员处理结果互联网职场流行一句话“凡事有回音，凡事有位置”。
由于用户已经给出了反馈，他们通常在等待处理结果。PM要做好处理的过程，形成闭环，才能达到最终的结果。不要跟丢了案子，把最后的处理结果反馈给问题的举报人。
以上六个步骤是我在处理badcase时采取的步骤。完全完成案件处理流程后，基本可以形成闭环，避免成为处理问题的“麦克风”。在这里和大家分享一下。
欢迎大家一起交流，感谢阅读~
本文由@小胚芽原创发布。每个人都是产品经理。未经许可，禁止转载。
图片来自Unsplash，基于CC0协议。
