處理badcase,產(chǎn)品經(jīng)理不做“傳話筒”
作者分享了自己處理badcase的過程,完整走完case處理流程,基本上就能形成一個閉環(huán),避免自己成為處理問題的“傳話筒”。
一個產(chǎn)品經(jīng)理在日常工作中不可避免的內(nèi)容就是處理業(yè)務(wù)badcase,但是往往很多時候在接到用戶問題反饋后,PM在處理的過程中無意識地把自己的角色變成了很多研發(fā)口中的“傳話筒”。
下面舉個栗子:
問題反饋人:XXX地方功能不好用/有XXX問題。
PM:(收到問題后直接將問題截圖給研發(fā)處理)
研發(fā):我試了一下沒問題啊。
PM:(找問題反饋人傳話說沒有問題,啊再試下)
問題反饋人:還是有啊(再次截圖)。
PM:(收到反饋人的二次反饋,再次直接截圖用戶反饋的問題給研發(fā)處理)
研發(fā):……
如果大家在處理badcase的過程中有“傳話筒”經(jīng)歷,那么大家一定一定要改變這種問題處理思維方式。時間長了這個傳話筒的角色很容易被pass或者優(yōu)化掉,同時也很難提高自己的業(yè)務(wù)能力水平。
今天和大家一起分享一下,我自己總結(jié)的處理流程,主要分以下六個步驟進行:
- 清晰、完整地陳述問題;
- 親自驗證問題存在的真實性;
- 了解對應(yīng)功能的整體流程;
- 排查問題可能產(chǎn)生的原因并給出對應(yīng)的解決方案;
- 找對應(yīng)的研發(fā)或相關(guān)人員去解決修復(fù)并自測;
- 告知給反饋人及相關(guān)人員處理結(jié)果。
接下來詳細(xì)說明一下每個步驟描述及注意事項:
一、清晰、完整地陳述問題
很多時候PM接到的用戶反饋僅僅是一句“XXX功能不能用”,PM在接到這句話之后要什么呢?
應(yīng)該弄清楚問題在什么條件下發(fā)生的:什么用戶,用什么設(shè)備,在什么場景,什么流程環(huán)節(jié),出現(xiàn)什么問題,導(dǎo)致的結(jié)果是什么?是否還有其他場景也同樣出現(xiàn)?
這些問題完全弄清楚之后才叫“清晰、完整地陳述問題”。
二、親自驗證問題存在的真實性
用戶反饋的問題是真是假?是否真的存在?是不是用戶手機的問題?或者是網(wǎng)絡(luò)不好?或者遇到公司后臺在修改系統(tǒng)平臺?……自己一定一定要自己驗證測試一遍,驗證問題是否真實存在。
排除個人場景下的異常情況,不然可能存在其實沒什么問題,聽信一句用戶反饋就直接報到研發(fā)那里;如果研發(fā)測試之后,沒有任何問題,這會讓你很尷尬。
三、了解對應(yīng)功能的整體流程
有時候用戶反饋問題的功能,PM自己都不清楚到底怎么用。復(fù)雜的系統(tǒng)下,每個場景流程很多時候是不同的。
當(dāng)PM自己都不知道流程怎么使用的時候,很難去排查問題原因所在。尤其是對于中間剛接手業(yè)務(wù)的PM來說,一定要多了解業(yè)務(wù),多熟悉業(yè)務(wù)流程,可以通過多看之前的產(chǎn)品需求文檔(PRD),重點看里面的業(yè)務(wù)流程圖。然后自己對著流程圖操作幾遍,或者多和業(yè)務(wù)研發(fā)聊聊業(yè)務(wù)流程,快速掌握自己負(fù)責(zé)的整體業(yè)務(wù)流程。
四、排查問題可能產(chǎn)生的原因并給出對應(yīng)的解決方案
排查問題產(chǎn)生的原因這一步有點難。判斷是建立在很熟悉業(yè)務(wù)的前提之下的,一般的badcase產(chǎn)生的原因可能是參數(shù)缺失,參數(shù)傳值錯誤或者其他流程環(huán)節(jié)問題關(guān)聯(lián)導(dǎo)致的。PM在處理badcase過程中最大的價值,是通過分析原因之后,提煉出引發(fā)問題的可能原因,并能給出對應(yīng)的解決方案。
五、找對應(yīng)的研發(fā)或相關(guān)人員去解決修復(fù)并自測
一個PM在處理badcase找研發(fā)溝通處理問題時,除了完整、清晰地陳述問題之外,如果能直接給到RD引起的可能原因,并且給出對應(yīng)的解決方案,研發(fā)對于你的表現(xiàn)一定是有驚喜之感的。
步驟四真的很多PM都做得不好,研發(fā)也會因此而吐槽產(chǎn)品是“傳話筒”一樣的存在。因為你前面的排查原因可以讓研發(fā)人員更快定位問題所在,大大節(jié)約了排查時間。
另外,在研發(fā)定位問題并且修復(fù)之后,一定要自己測試一遍,確認(rèn)問題已經(jīng)完全修復(fù)完畢。
六、告知給反饋人及相關(guān)人員處理結(jié)果
在互聯(lián)網(wǎng)職場有句話比較火“事事有回音,件件有著落”。
既然用戶已經(jīng)反饋了,一般都會在等處理結(jié)果,PM在處理的過程中要做好做事形成閉環(huán),達(dá)到最后的結(jié)果有著落。別把case跟著跟著就丟了,把最后的處理結(jié)果反饋給問題的上報人。
以上六步就是我在處理badcase時,所走的步驟流程。完整走完case處理流程,基本上就能形成一個閉環(huán),避免自己成為處理問題的“傳話筒”,在這里和大家一起分享一下。
歡迎大家一起交流,感謝閱讀~
本文由 @小胚芽 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)許可,禁止轉(zhuǎn)載
題圖來自Unsplash,基于CC0協(xié)議
功能問題我會直接讓測試同學(xué)嘗試復(fù)現(xiàn)一下,看是不是漏測之類的問題
準(zhǔn)確來說,如果每天都有這種問題,PM的精力會被分散。大廠一般都有專職產(chǎn)品運營做這種事情。
你說的很對,小公司PM一個人干的活確實很多,可能沒有太多時間去進行,但是思路是差不多,可能只是一些思維方式?jīng)]有落地
?? 但是有些問題就很急_(:з」∠)_特別是問題問題的人,一問三不知
一問三不知的情況下就要搞清楚問題在什么場景什么操作的情況下出現(xiàn)的,PM按照反饋人描述的復(fù)現(xiàn)一下,如果PM對業(yè)務(wù)足夠了解情況下基本上“什么用戶,用什么設(shè)備,在什么場景,什么流程環(huán)節(jié),出現(xiàn)什么問題,導(dǎo)致的結(jié)果是什么?是否還有其他場景也同樣出現(xiàn)?”自己心里大概是有數(shù)的
你就不能寫壞方案或者糟糕的方案嗎?是怕字不夠
??
作為一個運營狗,非常喜歡你這樣的產(chǎn)品啊,點贊
哈哈,幫助別人解決問題我覺得就是PM的價值所在
棒!在處理線上反饋的時候一直很尷尬,感覺自己在其中除了傳話拉群外毫無作用。經(jīng)過作者梳理完后思路清晰多了!
我之前也是經(jīng)常會聽到研發(fā)吐槽,然后自己慢慢的尋找PM在這個過程中的意義和價值,逐漸有了處理思路,這個流程不一定全對,但是最起碼還是可以體現(xiàn)自己的價值,以后多交流,一起進步~
mark
一起踩坑一起進步~