ag输得时候一直输|处理badcase,产品经理不做“传话筒”

2020-01-03 15:48:22

ag输得时候一直输|处理badcase,产品经理不做“传话筒”

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

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

下面举个栗子:

问题反馈人:xxx地方功能不好用/有xxx问题。

pm:(收到问题后直接将问题截图给研发处理)

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

pm:(找问题反馈人传话说没有问题,啊再试下)

问题反馈人:还是有啊(再次截图)。

pm:(收到反馈人的二次反馈,再次直接截图用户反馈的问题给研发处理)

研发:……

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

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

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

很多时候pm接到的用户反馈仅仅是一句“xxx功能不能用”,pm在接到这句话之后要什么呢?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

题图来自unsplash,基于cc0协议

随机推荐

回到顶部