身為產(chǎn)品經(jīng)理，由于業(yè)務(wù)的繁雜性，經(jīng)常會苦惱于一個問題——背鍋，如何做到讓自己不背鍋呢？同為產(chǎn)品經(jīng)理，作者為大家總結(jié)了以下經(jīng)驗，給大家提供一些參考建議。

前言

作為產(chǎn)品經(jīng)理，背鍋算是過來人，寫在這里無非是想給自己一個總結(jié)，讓自己以后的工作能盡量少出差錯，同時給剛?cè)胄械漠a(chǎn)品一個善意的溫馨提示。

所謂甩鍋，調(diào)侃而已，并非不負(fù)責(zé)任，我一直認(rèn)為，當(dāng)大家都會甩鍋的時候，會降低錯誤的發(fā)生概率，當(dāng)然，我這里有一個大前提就是，如果的確是自己的鍋，燙手也要接著。

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

一、產(chǎn)品

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

二、測試

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

三、開發(fā)

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

四、數(shù)據(jù)分析采集師

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

五、運營

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

六、UI設(shè)計師

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

結(jié)尾：

歡迎廣大產(chǎn)品伙伴說說自己的背鍋經(jīng)歷，背一次鍋就學(xué)習(xí)了一次，大家一起進步。不喜歡的就別噴了，留點口水需求評審的時候用吧！

本文由@產(chǎn)品汪汪汪 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

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