產品經理如何正確地“甩鍋”?
身為產品經理,由于業務的繁雜性,經常會苦惱于一個問題——背鍋,如何做到讓自己不背鍋呢?同為產品經理,作者為大家總結了以下經驗,給大家提供一些參考建議。
前言
作為產品經理,背鍋算是過來人,寫在這里無非是想給自己一個總結,讓自己以后的工作能盡量少出差錯,同時給剛入行的產品一個善意的溫馨提示。
所謂甩鍋,調侃而已,并非不負責任,我一直認為,當大家都會甩鍋的時候,會降低錯誤的發生概率,當然,我這里有一個大前提就是,如果的確是自己的鍋,燙手也要接著。
以下言語之中,如果傷害到了其他崗位伙伴的情感,那只能說聲抱歉,都是為了工作,我這里只是自己的總結,但愿你能見諒。
一、產品
- 自己沒有權利決定的事,永遠不要自己決定,要和老大確定好,最好有書面確定。這個不是為了甩鍋,老大的鍋得背著,就是為了讓自己心里舒服點,同時也得讓老大知道自己在背鍋。
- 多個人負責同一個產品迭代時,要注明哪些是自己的需求,哪些是同事的需求,涉及到數據分析以及埋點,自己搞自己的不要一個人大包大欖。
- 嘴上說的需求永遠不要相信。沒有放在需求池里的需求,都不叫需求,凡是需求必有書面的記錄。
- 自己做需求時,功能上最好別創新,看看BAT,看看MTD,社會認知已經形成,抄著來不會錯,他們都沒有的需求,就看看競品,畢竟有人已經試水,創新留給體驗創新,流程創新與模式創新。
二、測試
- 最好不要看測試用例,異常情況你永遠不會考慮的有測試詳細,如果測試拿測試用例找你,無法推脫了,那就一定要仔細看,還原到各種場景,最后要問一下他寫測試用例的各種場景的復現幾率,然后,產品還要再說明自己需求的各種場景。如果測試用例真的出現了自己之前沒有考慮到的問題,及時補充到需求文檔,并同步開發。
- 改任何需求都必須與測試確認,最好有書面文檔,條件允許該需求測試,開發都在場。
- 產品驗收的問題,只驗收自己的需求的流程與邏輯,不要驗收bug,整理說明,最好有書面文檔,產品上線后概不負責。
- 最好不要跟進bug的修改,那是測試的事,把控結果和進度就好了
三、開發
- 把需求寫清,如果有更改,一定第一時間同步所有人。
- 與開發交流需求問題,最好用文字,因為很有可能開發普通話不太好或者開發表達不清自己的意思,產品會理解錯,沒法用文字的情況下,交流最后,一定要把自己理解的開發的意思,從自己嘴里再說出一遍,讓開發再去確認。
- 做埋點需求時,無論是客戶端,h5埋點還是服務器埋點都必須在需求里寫清。不要口頭告訴。
- 盡量了解開發的實現需求邏輯,但是要假裝不知道,和開發溝通需求就說場景,別探討實現邏輯,因為產品不太懂,開發會挖坑,兩三句就給你整懵逼了。除了你真的是一個技術型產品。
- 各種前端與客戶端的實現邏輯很簡單,要盡量搞清楚,但是要裝不清楚,搞清楚是出于對于排期以及實現的可能性為目的,裝糊涂是為了讓開發提高自己的創造力。
- 安卓與ios實現邏輯盡量統一,否則再次迭代遇到困難幾率會增高,展示統一不了勉強就接受吧。
- 做需求時,盡量不要發現問題就改問題,要從根源解決,產品思維是網狀的,前端開發思維是點狀的,很有可能你改了這塊,開發就真的改了,和原來邏輯沖突,你不知道,開發也不知道,上線就該有用戶反饋了。
四、數據分析采集師
- 要什么數據同樣書面通知,不要只考慮pv,uv,那個太簡單,符合你定義的條件的數值,要說場景,別跟他探討怎么取數據,他實在做不了,就自己去數據庫看看有沒有相映字段,或者找開發聊聊。
- 數據采集師每天都需要配合別人的工作,所以盡量催著自己的需求
五、運營
- 產品運營不分家,最好和運營搞好關系,但是對于運營活動,運營想法可能會很多,實現不了的要跟他說清楚,自己必要定義活動,配合運營去搞事情,他做主,你畫圖就可以了。然后哪里什么邏輯一定要口頭與書面全告訴運營。
六、UI設計師
- 最好設計文案想好,讓他直接看需求文檔,這樣他會了解設計圖出現在哪減少溝通成本。
- 自己需求里最好顏色區分一下你要表達的內容,降低點溝通成本
- 自己抄的需求,讓設計也去抄吧,不會出啥大差錯。
- 設計文案提前想好,要不然被噴死。
結尾:
歡迎廣大產品伙伴說說自己的背鍋經歷,背一次鍋就學習了一次,大家一起進步。不喜歡的就別噴了,留點口水需求評審的時候用吧!
本文由@產品汪汪汪 原創發布于人人都是產品經理。未經許可,禁止轉載
題圖來自Unsplash,基于CC0協議
評論
金玉良言
很全面
,