產品經理如何正確地“甩鍋”？

摘要： 身為產品經理，由於業務的繁雜性，經常會苦惱於一個問題——背鍋，如何做到讓自己不背鍋呢？同為產品經理，作者為大家總結了以下經驗，給大家提供一些參考建議。 前言 作為產品經理，背鍋算是過來人，寫在這裡無非是想給自己一個總結，讓自己以後的工作能儘量少出差錯，同時給剛入行的產品一個善...

身為產品經理，由於業務的繁雜性，經常會苦惱於一個問題——背鍋，如何做到讓自己不背鍋呢？同為產品經理，作者為大家總結了以下經驗，給大家提供一些參考建議。

前言

作為產品經理，背鍋算是過來人，寫在這裡無非是想給自己一個總結，讓自己以後的工作能儘量少出差錯，同時給剛入行的產品一個善意的溫馨提示。

所謂甩鍋，調侃而已，並非不負責任，我一直認為，當大家都會甩鍋的時候，會降低錯誤的發生概率，當然，我這裡有一個大前提就是，如果的確是自己的鍋，燙手也要接著。

以下言語之中，如果傷害到了其他崗位夥伴的情感，那隻能說聲抱歉，都是為了工作，我這裡只是自己的總結，但願你能見諒。

一、產品

• 自己沒有權利決定的事，永遠不要自己決定，要和老大確定好，最好有書面確定。這個不是為了甩鍋，老大的鍋得揹著，就是為了讓自己心裡舒服點，同時也得讓老大知道自己在背鍋。
• 多個人負責同一個產品迭代時，要註明哪些是自己的需求，哪些是同事的需求，涉及到資料分析以及埋點，自己搞自己的不要一個人大包大欖。
• 嘴上說的需求永遠不要相信。沒有放在需求池裡的需求，都不叫需求，凡是需求必有書面的記錄。
• 自己做需求時，功能上最好別創新，看看BAT，看看MTD，社會認知已經形成，抄著來不會錯，他們都沒有的需求，就看看競品，畢竟有人已經試水，創新留給體驗創新，流程創新與模式創新。

二、測試

• 最好不要看測試用例，異常情況你永遠不會考慮的有測試詳細，如果測試拿測試用例找你，無法推脫了，那就一定要仔細看，還原到各種場景，最後要問一下他寫測試用例的各種場景的復現機率，然後，產品還要再說明自己需求的各種場景。如果測試用例真的出現了自己之前沒有考慮到的問題，及時補充到需求文件，並同步開發。
• 改任何需求都必須與測試確認，最好有書面文件，條件允許該需求測試，開發都在場。
• 產品驗收的問題，只驗收自己的需求的流程與邏輯，不要遇見bug，整理說明，最好有書面文件，產品上線後概不負責。
• 最好不要跟進bug的修改，那是測試的事，把控結果和進度就好了

三、開發

• 把需求寫清，如果有更改，一定第一時間同步所有人。
• 與開發交流需求問題，最好用文字，因為很有可能開發普通話不太好或者開發表達不清自己的意思，產品會理解錯，沒法用文字的情況下，交流最後，一定要把自己理解的開發的意思，從自己嘴裡再說出一遍，讓開發再去確認。
• 做埋點需求時，無論是客戶端，h5埋點還是伺服器埋點都必須在需求裡寫清。不要口頭告訴。
• 儘量瞭解開發的實現需求邏輯，但是要假裝不知道，和開發溝通需求就說場景，別探討實現邏輯，因為產品不太懂，開發會挖坑，兩三句就給你整懵逼了。除了你真的是一個技術型產品。
• 各種前端與客戶端的實現邏輯很簡單，要儘量搞清楚，但是要裝不清楚，搞清楚是出於對於排期以及實現的可能性為目的，裝糊塗是為了讓開發提高自己的創造力。
• 安卓與ios實現邏輯儘量統一，否則再次迭代遇到困難機率會增高，展示統一不了勉強就接受吧。
• 做需求時，儘量不要發現問題就改問題，要從根源解決，產品思維是網狀的，前端開發思維是點狀的，很有可能你改了這塊，開發就真的改了，和原來邏輯衝突，你不知道，開發也不知道，上線就該有使用者反饋了。

四、資料分析採集師

• 要什麼資料同樣書面通知，不要只考慮pv，uv，那個太簡單，符合你定義的條件的數值，要說場景，別跟他探討怎麼取資料，他實在做不了，就自己去資料庫看看有沒有相映欄位，或者找開發聊聊。
• 資料採集師每天都需要配合別人的工作，所以儘量催著自己的需求

五、運營

• 產品運營不分家，最好和運營搞好關係，但是對於運營活動，運營想法可能會很多，實現不了的要跟他說清楚，自己必要定義活動，配合運營去搞事情，他做主，你畫圖就可以了。然後哪裡什麼邏輯一定要口頭與書面全告訴運營。

六、UI設計師

• 最好設計文案想好，讓他直接看需求文件，這樣他會了解設計圖出現在哪減少溝通成本。
• 自己需求裡最好顏色區分一下你要表達的內容，降低點溝通成本
• 自己抄的需求，讓設計也去抄吧，不會出啥大差錯。
• 設計文案提前想好，要不然被噴死。

結尾：

歡迎廣大產品夥伴說說自己的背鍋經歷，背一次鍋就學習了一次，大家一起進步。不喜歡的就別噴了，留點口水需求評審的時候用吧！

本文由@產品汪汪汪 原創釋出於人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基於CC0協議