处理badcase，产品经理不做“传话筒”

作者分享了自己处理badcase的过程，完整走完case处理流程，基本上就能形成一个闭环，避免自己成为处理问题的“传话筒”。

一个产品经理在日常工作中不可避免的内容就是处理业务badcase，但是往往很多时候在接到用户问题反馈后，PM在处理的过程中无意识地把自己的角色变成了很多研发口中的“传话筒”。

下面举个栗子：

问题反馈人：XXX地方功能不好用/有XXX问题。

PM：（收到问题后直接将问题截图给研发处理）

研发：我试了一下没问题啊。

PM：（找问题反馈人传话说没有问题，啊再试下）

问题反馈人：还是有啊（再次截图）。

PM：（收到反馈人的二次反馈，再次直接截图用户反馈的问题给研发处理）

研发：……

如果大家在处理badcase的过程中有“传话筒”经历，那么大家一定一定要改变这种问题处理思维方式。时间长了这个传话筒的角色很容易被pass或者优化掉，同时也很难提高自己的业务能力水平。

今天和大家一起分享一下，我自己总结的处理流程，主要分以下六个步骤进行：

1. 清晰、完整地陈述问题；
2. 亲自验证问题存在的真实性；
3. 了解对应功能的整体流程；
4. 排查问题可能产生的原因并给出对应的解决方案；
5. 找对应的研发或相关人员去解决修复并自测；
6. 告知给反馈人及相关人员处理结果。

接下来详细说明一下每个步骤描述及注意事项：

一、清晰、完整地陈述问题

很多时候PM接到的用户反馈仅仅是一句“XXX功能不能用”，PM在接到这句话之后要什么呢？

应该弄清楚问题在什么条件下发生的：什么用户，用什么设备，在什么场景，什么流程环节，出现什么问题，导致的结果是什么？是否还有其他场景也同样出现？

这些问题完全弄清楚之后才叫“清晰、完整地陈述问题”。

二、亲自验证问题存在的真实性

用户反馈的问题是真是假？是否真的存在？是不是用户手机的问题？或者是网络不好？或者遇到公司后台在修改系统平台？……自己一定一定要自己验证测试一遍，验证问题是否真实存在。

排除个人场景下的异常情况，不然可能存在其实没什么问题，听信一句用户反馈就直接报到研发那里；如果研发测试之后，没有任何问题，这会让你很尴尬。

三、了解对应功能的整体流程

有时候用户反馈问题的功能，PM自己都不清楚到底怎么用。复杂的系统下，每个场景流程很多时候是不同的。

当PM自己都不知道流程怎么使用的时候，很难去排查问题原因所在。尤其是对于中间刚接手业务的PM来说，一定要多了解业务，多熟悉业务流程，可以通过多看之前的产品需求文档（PRD），重点看里面的业务流程图。然后自己对着流程图操作几遍，或者多和业务研发聊聊业务流程，快速掌握自己负责的整体业务流程。

四、排查问题可能产生的原因并给出对应的解决方案

排查问题产生的原因这一步有点难。判断是建立在很熟悉业务的前提之下的，一般的badcase产生的原因可能是参数缺失，参数传值错误或者其他流程环节问题关联导致的。PM在处理badcase过程中最大的价值，是通过分析原因之后，提炼出引发问题的可能原因，并能给出对应的解决方案。

五、找对应的研发或相关人员去解决修复并自测

一个PM在处理badcase找研发沟通处理问题时，除了完整、清晰地陈述问题之外，如果能直接给到RD引起的可能原因，并且给出对应的解决方案，研发对于你的表现一定是有惊喜之感的。

步骤四真的很多PM都做得不好，研发也会因此而吐槽产品是“传话筒”一样的存在。因为你前面的排查原因可以让研发人员更快定位问题所在，大大节约了排查时间。

另外，在研发定位问题并且修复之后，一定要自己测试一遍，确认问题已经完全修复完毕。

六、告知给反馈人及相关人员处理结果

在互联网职场有句话比较火“事事有回音，件件有着落”。

既然用户已经反馈了，一般都会在等处理结果，PM在处理的过程中要做好做事形成闭环，达到最后的结果有着落。别把case跟着跟着就丢了，把最后的处理结果反馈给问题的上报人。

以上六步就是我在处理badcase时，所走的步骤流程。完整走完case处理流程，基本上就能形成一个闭环，避免自己成为处理问题的“传话筒”，在这里和大家一起分享一下。

欢迎大家一起交流，感谢阅读~

本文由 @小胚芽 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自Unsplash，基于CC0协议

作者暂无likerid, 赞赏暂由本网站代持，当作者有likerid后会全部转账给作者（我们会尽力而为）。


Support author:
Author's Filecoin address:
Or you can use Likecoin to support author: