处理badcase,产品经理不做“传话筒”
作者分享了自己处理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协议
功能问题我会直接让测试同学尝试复现一下,看是不是漏测之类的问题
准确来说,如果每天都有这种问题,PM的精力会被分散。大厂一般都有专职产品运营做这种事情。
你说的很对,小公司PM一个人干的活确实很多,可能没有太多时间去进行,但是思路是差不多,可能只是一些思维方式没有落地
😉 但是有些问题就很急_(:з」∠)_特别是问题问题的人,一问三不知
一问三不知的情况下就要搞清楚问题在什么场景什么操作的情况下出现的,PM按照反馈人描述的复现一下,如果PM对业务足够了解情况下基本上“什么用户,用什么设备,在什么场景,什么流程环节,出现什么问题,导致的结果是什么?是否还有其他场景也同样出现?”自己心里大概是有数的
你就不能写坏方案或者糟糕的方案吗?是怕字不够
😀
作为一个运营狗,非常喜欢你这样的产品啊,点赞
哈哈,帮助别人解决问题我觉得就是PM的价值所在
棒!在处理线上反馈的时候一直很尴尬,感觉自己在其中除了传话拉群外毫无作用。经过作者梳理完后思路清晰多了!
我之前也是经常会听到研发吐槽,然后自己慢慢的寻找PM在这个过程中的意义和价值,逐渐有了处理思路,这个流程不一定全对,但是最起码还是可以体现自己的价值,以后多交流,一起进步~
mark
一起踩坑一起进步~