1. 职涯宝首页
  2. 产品经理

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

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

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

一个产品经理在日常工作中不可避免的内容就是处理业务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处理流程,基本上就能形成一个闭环,避免自己成为处理问题的“传话筒”,在这里和大家一起分享一下。

本文由 @宝元 发布于 职涯宝 ,未经作者许可,禁止转载,欢迎您分享文章

发表评论

登录后才能评论
小程序
小程序
微信客服
微信客服
QQ客服 建站服务
分享本页
返回顶部