1樓：Bamboo是竹子
事前明確任務分工及DDL
掌握規則，分清權責。當接到老闆的工作任務後，要做到工作透明化，和小組成員進行分工，要明確以下四方面：工作內容，工作量，工作職責及截止時間。
利用郵件等工具留作備份，並抄送自己和對方的上級+其他團隊成員平時在工作中要養成不用口頭方式交流的習慣，在工作的過程中，要及時把每個進度向領導匯報或者發一封郵件，郵件內容要有你做了什麼你沒做什麼，全都要有詳細的記錄，要讓領導給你做乙個見證的同時也讓領導及時了解專案進度，方便領導把控專案，這樣一旦遇到同事甩鍋的情況，就可以有證據證明你的清白，否則空口無憑，難以令人信服。
如果真遇到甩鍋，請優雅拿出上面的資料
當真遇到了甩鍋給你的同事，如果你已做好前面兩點，就請不要擔心，保持好自己的優雅，拿出相關證據證明。在老闆面前也無需爭辯，誰對誰錯自見分曉。
2樓：大漠孤煙
1、產品經理是公司所有專案的驅動程式--平常要了解管理層們在忙什麼--他們關心的就是你要關心和事先準備的--說不定哪天這件事就成為你的工作內容--
2、產品經理要琢磨公司的生門和死門--公司要生存。但這種問題不能自己悶想--要在適當的時候跟領導交流--如果你能在緩解公司痛苦的地方做些事情--那麼你就不得了--
3、要十分清楚公司的目標和上司的期望--這些都是產品經理工作的最低限--應努力做出超過上級期望的事情--
4、產品經理要對自己的產品負責--要對自己的下線資源負責--要具有成品意識--在一定程度上要追求完美。產品經理提交出來的需求如果是次品--遭殃的最後是自己--千萬不能偷懶--
5、要及時通報事件的進展情況--有兩個好處--一是讓相關人員掌握資訊--這是他們的權利--二是發動集體智慧型及時發現潛在的問題--做好了可是你的功勞--
6、產品經理要講事實--主觀強勢比軟弱更值得一試--尤其面對不同領導的不同的意見時--不管聽誰最後吃虧的都是自己。產品經理能做的就是按事物的本來面目進行操作--然後從這一角度解釋給領導聽--
7、要學會站在公司利益角度去理解工作--那麼你的高度就不一樣--理解就不一樣--工作的狀態也就不一樣了--
8、注意報告檔案的格式--第一頁是精華--要字斟句酌--後面可以有100頁的支撐檔案--但第一頁只寫大家都關心的問題--
9、一條顛撲不破的真理--領導都是聰明人--誰幹得多誰幹得少--誰願意幹誰勉強幹--誰好用誰不好用--他明白得很。有句笑話叫"別跟豬摔跤"--在辦公室不要跟任何人較勁--就事論事--把本職工作做好。
10、產品經理還是老闆的幕僚--有些事你是要懂得及時提醒上司--疏忽這一職責帶來的後果可能是致命的。
3樓：向來痴
一般來說，產品經理沒有資格甩鍋，產品經理要對產品負全責，就像乙個公司好不好最大責任在於大老闆。
如何從根本上避免產品經理甩鍋？
上策，幫助TA樹立產品負責人的意識;
中策，明確雙方合作的規則，用文件化(郵件或者公司內部團隊協作工具)的方式進行需求確認;
下策，換乙個團隊或者公司。
4樓：張旭
甩回去就好，反正天天掐架，還怕甩鍋？沒有甩鍋的人生是不完整的，你有那麼多兄弟姐妹，還怕乙個產品經理？對事不對人就好。我就從來不甩鍋給開發，我一般只從內部瓦解
5樓：大大鋼
需求評審時的嚴謹性這裡就需要拿出來了
明確下具體問題是什麼，程式上的bug問題其實不算是產品的鍋，除非是邏輯bug
還有題主明確下這個鍋是啥吧，對症下藥哇
6樓：
只要不是特別明顯，只要不是完全置身事外，產品經理應該具備隨時替開發和測試同學背鍋的基本素質，要有隨時迎上去接好所有鍋的態度。
否則，還只能算是低階產品經理。
7樓：Mika
是PM向什麼職責甩鍋? 細想想，我沒有被甩過鍋，可能大家都是向同乙個方向努力的吧。只能是誰的責任，誰得多承擔些。
我也會站在PM的角度給他們建議，他們也樂意聽我們的意見呢。
8樓：孟佳
產品經理是沒鍋可甩的。甩鍋只會讓周圍的人覺得你可憐，替你心酸，然後利用你的軟弱。
就跟你是乙個醜的不行的孩子，不知道父親是誰。母親指著周圍的人群撒潑打滾兒
這個孩子這麼醜，這麼醜，都賴你們，都賴你們。
9樓：haha
從第3方的角度看問題，看看到底是誰的鍋：
如果是產品經理的鍋，請截圖還給他，並讓他知道：
鍋沒有那麼好甩！
如果是自己的鍋：
請閉上嘴，幹就是了~
如果是不可抗力的因素：
一切以解決問題為原則。
希望產品狗和程式猿能和平相處，都是打工的，不要相互為難，都不容易！加油
10樓：艾姐愛專案管理
這個話題有點大，是否判定為「甩鍋」這個有主觀的成分，不同人的角度與想法未必一樣。
艾姐在過去的十幾年工作中一直是職業專案經理人，與產品經理也有過相愛相殺的經歷。建議呢，最好不要在被「甩鍋」之後，再去考慮怎麼背鍋的問題，如有工作需要與產品經理協作，那請盡早的理解一些產品經理的工作內容與方式，知己知彼，採取合作共贏才是王道；當然如果甩鍋到有人身安危的情況，也請盡早遠離。
一篇小文推薦，
艾姐愛專案管理：為什麼優秀的專案經理有時會做出錯誤的決策，請接納產品知識，改變固有認知！艾姐
11樓：Miguel-三先生
居然有人說產品經理會甩鍋，這麼多年我一直都是扛事兒的，產品經理不好甩鍋~
維度1：需求方
需求方的鍋是甩不了的，因為每次需求評審之後我們都會走郵件再三確認，當需求出現調整或者更改的時候，會根據修改程度進行重新評審，給與確認的工期和人員回覆，這種情況下留下憑證很重要，再次提出無理需求或者變更的時候就不存在甩鍋了，因為我們有【呈堂證供】
維度2：技術方
技術眼裡看產品要麼就是大神，要麼就是大傻···所以任何乙個需求一定要前期溝通溝通在溝通，溝通之後要進行複述，就是用雙方都能聽得懂的話表達出來再次確認，確認之後調整文件，這時候的文件就相當於乙個法律條文，大家按著做就行了，出現邏輯問題或者紕漏那麼大多是產品的事兒，該認慫認慫，及時補救錯誤，避免重複開發就行
維度3：尊敬的上帝（使用者）
這就不說了，完全不存在甩鍋的問題
其實產品經理甩鍋的場景我只在那些經驗不是很豐富或者閱歷不是很豐富的人身上能看到，一般產品都是扛事兒的，畢竟產品本身來說責任心和承擔能力還是很重要的，這點基礎能力都沒有就別再產品圈裡混了
12樓：智庫燈塔
「當然你們有好人！」
事情的本質決定行動：確定問題出在哪，如果真的是產品經理的問題，而且對方瘋狂甩鍋，這樣沒有責任心的PM，不適合當同事，題主可以隨意發揮。
13樓：牛牛
哈哈哈你是個開發吧
乙個專案的開發，集產品+UI+前端+開發，有些細枝末節的工作，有時候要想丁是丁、卯是卯的說該誰誰做，確實有點難，這個時候各自的角色人員站在自己的角度上，就會覺得其他是甩鍋
我反思了一下我自己，有時候我和開發可能也有類似的情況，比如新增幾個機構賬號的，機構id的生成規則，在我看來，這個功能程式自動生成，開發肯定沒有什麼疑問，但是在開發眼裡，這個功能是我需要明確的，因為他們的規則可太多了；首先字串長度，機構id取機構的全拼還是簡稱，若簡稱的時候，會有重複的拼音等等
有時候就是人員角色不同，看待問題的角度不同，齊心協力解決問題吧但是如果職業道德欠妥的人，懟就完了
如何應對 預防 避免代人受過 被人冒功 栽贓 甩鍋 嫁禍的處境？
基本無解。因為能搞你的人肯定是能力比你強，壞人一定是摒除了人性一切的積極面，而專門研究人性的消極面，而且越是積極的人他們越是會破壞。除非也當個壞人，用壞人的方法對待壞人，同流合汙。沒有一無是處的壞人，逮著他的積極面搞破壞。同時提高自己的消極能量，挖掘壞人的缺點和缺陷，加以利用和訛詐。壞人的虛榮心更盛...
產品經理，遇到強勢的業務方如何應對？
產品經理的那點事 業務方一般有老闆，合作方 合作夥伴 客戶，使用者，運營等公司內部人員。這種 強勢 指的是性格強勢吧。每個公司都有自己的核心目標，既然業務方提需求了，從業務方自己的角度肯定有一定道理，但是業務方僅僅是站在自己的角度思考提出需求，這都沒問題。但是作為產品經理，要有同理心和大局觀念。同理...
產品經理如何應對開發團隊中的刺頭？
吻住我的香腸嘴 如果產品經理的原型能滴水不漏，我相信沒有哪個開發喜歡沒事找事。然而我遇到的產品經理給我的原型通常我理解為示意圖，它們缺乏大量的細節，離優秀原型開發者的距離還很遠，每當我無法理解的時候，我就想到去看需求文件，結果需求文件屬於大綱級別的，經常還說開發人員針對他，我就很好奇了。 尹奇成 挑...