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

前言

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

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

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

一、產(chǎn)品

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

二、測試

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

三、開發(fā)

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

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

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

五、運(yùn)營

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

六、UI設(shè)計(jì)師

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

結(jié)尾：

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

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

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