作者分享了自己處理badcase的過程，完整走完case處理流程，基本上就能形成一個閉環(huán)，避免自己成為處理問題的“傳話筒”。

一個產品經理在日常工作中不可避免的內容就是處理業(yè)務badcase，但是往往很多時候在接到用戶問題反饋后，PM在處理的過程中無意識地把自己的角色變成了很多研發(fā)口中的“傳話筒”。

下面舉個栗子：

問題反饋人：XXX地方功能不好用/有XXX問題。

PM：（收到問題后直接將問題截圖給研發(fā)處理）

研發(fā)：我試了一下沒問題啊。

PM：（找問題反饋人傳話說沒有問題，啊再試下）

問題反饋人：還是有?。ㄔ俅谓貓D）。

PM：（收到反饋人的二次反饋，再次直接截圖用戶反饋的問題給研發(fā)處理）

研發(fā)：……

如果大家在處理badcase的過程中有“傳話筒”經歷，那么大家一定一定要改變這種問題處理思維方式。時間長了這個傳話筒的角色很容易被pass或者優(yōu)化掉，同時也很難提高自己的業(yè)務能力水平。

今天和大家一起分享一下，我自己總結的處理流程，主要分以下六個步驟進行：

1. 清晰、完整地陳述問題；
2. 親自驗證問題存在的真實性；
3. 了解對應功能的整體流程；
4. 排查問題可能產生的原因并給出對應的解決方案；
5. 找對應的研發(fā)或相關人員去解決修復并自測；
6. 告知給反饋人及相關人員處理結果。

接下來詳細說明一下每個步驟描述及注意事項：

一、清晰、完整地陳述問題

很多時候PM接到的用戶反饋僅僅是一句“XXX功能不能用”，PM在接到這句話之后要什么呢？

應該弄清楚問題在什么條件下發(fā)生的：什么用戶，用什么設備，在什么場景，什么流程環(huán)節(jié)，出現(xiàn)什么問題，導致的結果是什么？是否還有其他場景也同樣出現(xiàn)？

這些問題完全弄清楚之后才叫“清晰、完整地陳述問題”。

二、親自驗證問題存在的真實性

用戶反饋的問題是真是假？是否真的存在？是不是用戶手機的問題？或者是網絡不好？或者遇到公司后臺在修改系統(tǒng)平臺？……自己一定一定要自己驗證測試一遍，驗證問題是否真實存在。

排除個人場景下的異常情況，不然可能存在其實沒什么問題，聽信一句用戶反饋就直接報到研發(fā)那里；如果研發(fā)測試之后，沒有任何問題，這會讓你很尷尬。

三、了解對應功能的整體流程

有時候用戶反饋問題的功能，PM自己都不清楚到底怎么用。復雜的系統(tǒng)下，每個場景流程很多時候是不同的。

當PM自己都不知道流程怎么使用的時候，很難去排查問題原因所在。尤其是對于中間剛接手業(yè)務的PM來說，一定要多了解業(yè)務，多熟悉業(yè)務流程，可以通過多看之前的產品需求文檔（PRD），重點看里面的業(yè)務流程圖。然后自己對著流程圖操作幾遍，或者多和業(yè)務研發(fā)聊聊業(yè)務流程，快速掌握自己負責的整體業(yè)務流程。

四、排查問題可能產生的原因并給出對應的解決方案

排查問題產生的原因這一步有點難。判斷是建立在很熟悉業(yè)務的前提之下的，一般的badcase產生的原因可能是參數(shù)缺失，參數(shù)傳值錯誤或者其他流程環(huán)節(jié)問題關聯(lián)導致的。PM在處理badcase過程中最大的價值，是通過分析原因之后，提煉出引發(fā)問題的可能原因，并能給出對應的解決方案。

五、找對應的研發(fā)或相關人員去解決修復并自測

一個PM在處理badcase找研發(fā)溝通處理問題時，除了完整、清晰地陳述問題之外，如果能直接給到RD引起的可能原因，并且給出對應的解決方案，研發(fā)對于你的表現(xiàn)一定是有驚喜之感的。

步驟四真的很多PM都做得不好，研發(fā)也會因此而吐槽產品是“傳話筒”一樣的存在。因為你前面的排查原因可以讓研發(fā)人員更快定位問題所在，大大節(jié)約了排查時間。

另外，在研發(fā)定位問題并且修復之后，一定要自己測試一遍，確認問題已經完全修復完畢。

六、告知給反饋人及相關人員處理結果

在互聯(lián)網職場有句話比較火“事事有回音，件件有著落”。

既然用戶已經反饋了，一般都會在等處理結果，PM在處理的過程中要做好做事形成閉環(huán)，達到最后的結果有著落。別把case跟著跟著就丟了，把最后的處理結果反饋給問題的上報人。

以上六步就是我在處理badcase時，所走的步驟流程。完整走完case處理流程，基本上就能形成一個閉環(huán)，避免自己成為處理問題的“傳話筒”，在這里和大家一起分享一下。

歡迎大家一起交流，感謝閱讀~

本文由 @小胚芽 原創(chuàng)發(fā)布于人人都是產品經理，未經許可，禁止轉載

題圖來自Unsplash，基于CC0協(xié)議