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

前言

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

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

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

一、産品

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

二、測試

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

三、開發

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

四、數據分析采集師

• 要什麼數據同樣書面通知，不要隻考慮pv，uv，那個太簡單，符合你定義的條件的數值，要說場景，别跟他探讨怎麼取數據，他實在做不了，就自己去數據庫看看有沒有相映字段，或者找開發聊聊。
• 數據采集師每天都需要配合别人的工作，所以盡量催着自己的需求

五、運營

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

六、UI設計師

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

結尾：

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

本文由@産品汪汪汪 原創發布于人人都是産品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議