據說，持有這四種工作態度的產品經理們可保性命無憂，可保不受白眼，可被人人喜歡，以及可帶團隊玩耍。你，想知道嗎？
最近看到知乎上一個問題，“外科醫生為什么很喜歡講黃段子？”在大批答案下，默默地收獲了好多之前沒看到過的專業污段子，果然一污更比一污深，小女子還是“太連清”。
雖然好像答不對題，但是我也好想回答一下這個問題：
什么外科醫生喜歡講黃段子呀，明明是人多的地方都喜歡講呀，尤其男人多的地方，金融呀、互聯網呀，都一樣，套路都“嬸嬸”的。
比如，我今天中飯又點了上海人家的仔排年糕外賣，旁邊的骨哥就感嘆了一下，“你愛上了上海人家。”，一下子不得了了，套路都來了：
“你們說，‘你愛’是誰？”
“那個‘了’又是誰？”
“難道你們已經知道‘海人家’是誰？純純的我并不懂呀！”
臥槽，已經腦洞了一整部人體蜈蚣了好咩……
知道俺們測試環境的圖片都是啥咩？都是漂亮妹紙們，中國的日本的美國的泰國的（真的不是18禁）哪天要是看不到妹紙皂片了，還以為自己進錯正式環境了；
知道俺們平常碼代碼吐血了怎么辦咩？分分鐘就有老司機開起小火車，不趕緊上車都不行啊！
話說到這兒，成功迎來產品汪們保命的第一招：
集體火車開起來，污污更和諧
不是說真的一定要講黃段子啦， 重點在于，要和開發們在非需求條件下還關系融洽。
什么叫“非需求條件下”？就是不做需求的時候，大家關系還是比較好。
為啥要關系融洽呢？先說說大家選擇一家公司的目的是什么好了，無非幾點：
- 公司給得了利
- 公司給得了名
- 公司總體氣氛不錯
- 團隊氣氛好、靠譜
- 團隊小伙伴有意思
利與名都和公司有關系，我們沒有辦法改變。但是，團隊的氣氛如何？伙伴有木有意思？我們還是可以影響的嘛。 非需求情況下的我們，友愛兼有愛那是極好的。
至于怎么個友愛且有愛，這個就各自發揮了：
- 一起吃個飯啊
- 一起污一污啊
- 一起討論業務碰撞火花啊
- 一起團個建啊
- 一起吐個槽啊
- 一起色個誘啊
- 一起搞個基啊
方法千千萬，就不多贅述了。
碼prd、搞設計、擼代碼，正常情況下，不太可能連續高度集中轉一小時以上，這種情況下咋整？一起活躍下氣氛嘛，緩解下腦補壓力，順便不知不覺中增進點團隊感，多好。
剛剛講了“非需求情況下”的關系和諧，以下再來講三個“需求情況下”的關系和諧必備三招：
需求別亂提，要有理有據，我們是需求的百度百科
看起來感覺是廢話，對咩？其實并不是的。太多產品汪們其實并不知道這個意味著什么。
1、需求要對自己有理有據
決定做一個需求前，自己要想清楚為什么要做、做了有什么好處、怎么去檢測好處、如果做錯了怎么辦等等。
把這個版本根據產品現有狀況想做的需求都列出來，它可能是這樣的：
- 產品要做的需求1
- 產品要做的需求2
- 產品要做的需求3
- 產品要做的需求4
- 產品要做的需求5
- 產品要做的需求6
然而，產品狗們都懂的，事實離以上相差甚遠，實際上很有可能是這樣的：
- 產品要做的需求1
- 產品要做的需求2
- 公司層面要做的需求1
- 公司層面要做的需求2
- 項目負責人要做的需求1
- 項目負責人要做的需求2
在這種情況下，你要去理解公司/項目負責人為什么要這么做、原因是什么、是否和現有的產品方向違背、是否和現有的產品節奏違背。
- 如果你能理解并且支持，那么自然是最好的，可以有理有據去做需求；
- 如果你能理解但不支持，那么以上層決策大于個人決策的基本法，在溝通依舊無效的情況下，還是只能放下個人想法，但依舊可以有理有據去做需求；
- 如果你不能理解但支持，那無法對自己有理，雖然有據，這個需求就沒辦法做下去了；
- 如果你不能理解也不支持，那感覺您可以從公司撤退了。
很多產品經理在第三種、第四種的情況下還依舊把這個需求丟給開發，這其實是非常不負責任的。
因此，務必讓自己處于前兩種狀態中。
2、需求要對對接方有理有據
產品經理們要端正一個態度，那就是： 不要把設計師們當做作圖工具、不要把開發們當做代碼 工具。 其實，他們也感興趣自己做的到底是個什么東西、到底為什么要這么做。
所以，在出來一個需求的時候，需要在和他們溝通具體邏輯的前面，先和他們溝通為什么要這么做。
同時，這么做還能無形中帶來一些好處：身處需求中的設計和開發，能夠慢慢從對做的產品有業務概念上的認知到對用戶需求的認知。雖然這個時間可能比較長，但是建立在實際理解的基礎上做出來的東西和沒有理解基礎上做出來的東西，無論是做的過程還是做的結果，都會有比較大的差別。
那怎么和對接方們溝通需求背景（為什么做）呢？可以從公司決策上、從業務上、從數據上等單方面或者多方面結合的看人下菜進行講解。
舉個我們自己遇到的實例：
其實昨天下午，這個討論就在我們團隊里發生了。在我講完幾個需求之后，聽講的飛哥和韓哥哥提出了一個質疑和一個建議：
- 為啥我們要做這些需求呢？
- 是否可以在確定這些需求之前讓我們參與討論呢？
然后翻墻仔也說了自己的看法：“你不能單從用戶的數據角度就說我們要做這個需求呀。”
然后，我就突然發現還不能單從一個角度去說服他們，所以又從業務、從公司的角度來描述了一遍做那幾個重要的需求的原因，最后他們表示理解了。
同時，我們也暫時約定了在定下需求列表但未進入確定的需求分析的時候，就告知他們這些，同時可以征求大家的想法。
我覺得這種氛圍在小團隊里其實很好，每個人都參與，是一份子，而不僅僅是你遞交需求，我實現需求的關系，這樣也更容易在“需求條件下”雙方關系和諧。
需求別亂接，要接接完整，我們是需求的人肉過濾器
這點，我覺得可能是開發們吐槽產品們亂提需求的一個很大的原因。
產品會天天跟運營（內容、活動、社區、投放、用戶）、廣告和開發溝通，免不了這邊來點需求，那邊來點需求，但是這些需求一般有以下幾種可能性：
- 需求方不知道自己到底要干嘛的，死活要做某個需求的；
- 需求方不知道自己到底要干嘛的，就嘗試性的提一提需求；
- 需求方知道自己最終要干什么的，但不知道過程怎么弄，就干脆不弄的；
- 需求方知道自己最終要干什么的，嘗試弄清楚過程，但沒弄清楚的；
- 需求方知道自己最重要干什么的，也給清楚的把需求整理了的。
以上列舉的還沒包括需求合理與不合理的可能性。
現實工作中，前面1、2兩種不知道自己要干嘛，但是又要跟你提需要的人多了去了。
這個時候你不能順著他，不然倒霉的就是你，還有在你后面的設計、運營以及開發們了。
這個時候你可以怎么辦呢？
- “大殺器”：用“為什么要做這個，說不出原因就拒絕”的態度把這個需求給直接打回去；
- “小溫柔”：通過多問一些問什么，把需求方逐漸轉化成3、4、5、情況。當然，搞不清自己目的還要做需求的人，目測也不太可能變成e這種類型。
說完a、b兩種情況后，我們再來說說該怎么解決3、4、5這些情況。
這些情況還算好，至少知道提這個需求的目的是什么，那就好辦多了：
- 如果你不認可他的需求，并且覺得這個需求不合理、優先級低，那么可以通過溝通回絕；
- 如果你認可他的需求，也覺得這個需求合理、優先級可以比較高，那么就該幫助他一起正確的達到目的。
舉個運營需求的例子：
運營部門要做個目的明確的活動 ，同時他們也做了一個活動流程出來。你看過之后，覺得可以做，但是現有的流程比較亂，導致用戶會懵逼同時開發資源也可能會被不必要占用。
這種情況下該怎么辦呢？
應該運用自己的邏輯，幫助他們一起梳理這個流程，提出可能性的解決辦法，大家一起溝通商量，把東西做好，最終讓后面的設計和開發們都不會做白用功。
再舉個產品需求這邊的例子：
因為公司政策問題，導致乃們要做某個需求，這個需求涉及的大部分功能，其實其他小組已經做好了。也就是說只需要自己開發小小的量，同時接入對方小組的東西就可以了。
那么，問題就來了，產品汪們在分析完自己要開發的部分之后，就完成這個需求了嗎？
顯然不是，是否考慮過以下問題？
- 功能的整套流程是否有走順？
- 怎么對接比較好，邏輯比較干凈？
- 對接需要提前注意到哪些問題？
- 對方開發的頁面是否和你的頁面UI、交互一致？
以上都是在進入到設計和開發前，“產品汪們”就要實現做掉的工作，而不是到設計到開發后，才開始的工作。
一個需求，并不是寫完需求分析就完事了，而是要把圍繞著這個需求的所有相關事情都要先搞清楚，繼而整理清楚，再進入下一步，這樣才省時省力，合作起來才不會這么累。
鍋要背起來，不要怕被罵，我們是大家的人肉防彈衣
這點，其實很明確，不管是這個版本bug率過高了、還是用戶流失嚴重了，亦或是新出來的功能被用戶罵了等等，都有產品汪們的責任，不要想躲。
舉個例子：
假設某一次版本上線后，bug率蹭蹭蹭往上漲，用戶流失的比較嚴重，各項指標都在刷刷往下掉。這個鍋該誰背？我覺得產品汪一定逃不掉。為什么？
- bug率過高，那說明測試大人們沒有好好測試（測試的鍋）或者沒有時間好好測試；
- 測試沒好好測試，但汪們居然驗收通過了，那汪就該背鍋；
- 測試沒有時間好好測試，那是不是說明上線時間安排的有問題？是不是進一步說明項目時間沒安排好？那是不是又進一步說明需求沒安排好？汪又要背鍋了；
不管如何，“產品汪”們是上線前的最后一道線，一旦線上，說明你認可了上線這個行為。不管有什么結果，都得擔著。
這個不是鼓勵大家把什么錯都攬上身，而是 千萬不要覺得，自己在一件事里一定沒有責任。
好啦，以上就是保命四招：
- 會一招，可保性命無憂；
- 會兩招，可保不受白眼；
- 會三招，可被人人喜歡；
- 會四招，可帶團隊玩耍。
我還在練習……大家互勉……
本文由 @killifer原創發布于人人都是產品經理。未經許可，禁止轉載。
Tags: 產品經理
文章來源：http://www.woshipm.com/pmd/421772.html