產品經理怎樣和開發搞好建設？
產品經理跟開發人員在日常工作中有著非常頻繁的溝通與協作需求，可以說PM跟RD是一對矛盾體，兩者之間因為有著共同的項目驅動目標，而需要相互溝通協作。
但同時兩者又存在個人利益的對立，比如PM可能會想著RD能夠在最短時間內有儘可能多的產出，而RD可能會想著用最小的投入完成自己的工作任務。
於是，矛盾便產生了。
如果產品經理無法處理好與開發人員的溝通協助工作，很可能會使得項目舉步維艱。如何高效、和諧的與研發人員打交道，是產品經理需要掌握的一門學問。
我曾經遇過一羣關係很好的開發同事，當時大家都是剛步入職場，彼此成為了朋友，在日常的合作中也很愉快。
我也遇到過一羣在家文化的企業氛圍中成長，情商很高，凡事都耐心溝通，以解決問題為目標導向的開發同事。當然，我也遇到過一些缺乏耐心，但凡線上溝通都習慣帶好幾個問號，懟得產品經理極為尷尬的開發同事。
很多情況下，我們無法選擇共事的同事，但我們可以掌握技巧，把自己的本分做好，追求雙贏。在這裡，就結合自己的經驗跟大家分享關於產品經理如何跟開發同事溝通協調的問題吧。
首先我們先看看產品經理跟開發同事產生衝突場景一般有哪些：
前期的需求溝通環節：
- 開發人員不認同產品經理的解決方案，導致撕逼衝突；
- 開發人員認為產品經理輸出的需求文檔不夠清晰，影響開發工作的展開。
需求開發與測試環節：
- 開發人員對產品經理的需求變更帶來的代碼返工、任務量加重存在抵觸心理；
- 產品經理缺乏技術相關知識的沉澱，與開發人員溝通的效率低下，易引發矛盾；
- 在開發過程中，產品經理與開發人員的口頭或者線上溝通調整方案未及時更新到文檔，導致後期發生問題雙方存在扯皮的現象；
- 測試暴露的問題在需求文檔中的描述模稜兩可，責任無法劃清，導致雙方相互發生爭執。
項目進度把控環節：
- 在項目推進的過程中，產品經理因不懂需求背後的技術工作量，與開發人員就項目的開發進度安排存在分歧；
- 產品經理迫於項目上線壓力，繼而轉移壓力催促開發人員，久而久之引發開發同事的不滿。
以上就是產品經理與開發同事產生矛盾的主要場景，有些產品經理可能會遇到一些性格比較獨特的開發人員，常見的特點就是不苟言笑，說話容易誤傷他人，這屬於比較特殊的性格問題，需要特別注意。
下圖是我在網上看到的，描述的是開發人員對產品經理的各種吐糟，相信很多產品經理看到會覺得很受傷。
既然雙方天生存在矛盾，那麼如何去緩解或者避免這種矛盾呢？
一、目標驅動
我們在職場中的大部分事情其實都帶有目標性，希望實現預期的效果，如果缺乏目標的驅動性，做什麼事情都是茫然的。產品經理在跟開發的過程中，雙方可能會因為觀點的分歧而爭論，有時候爭得面紅耳赤，半天下來都沒有把問題解決。
這時候建議雙方都冷靜下來，想想我們本次溝通的目的究竟是什麼？我們希望為用戶解決什麼問題?繼而及時回到正確的溝通軌道，減免無效的內耗。
之所以提出目標驅動的溝通原則，主要是建議大家溝通之前、溝通過程中需要明確本次溝通的目標，避免為了爭論而爭論，面紅耳赤拍桌板，到最後發現解決不了問題，還影響到雙方的關係，不歡而散。
二、利益驅動
最近看了一本書《窮查理芒格》，裡面有句話：「如果你想說服別人，要訴諸利益，而非訴諸理性！」
人對自己切身利益的事情顯然更為關注，假設一個環保主義者，想說服大家通過少開空調減少氟里昂排放，從而減少臭氧層的破壞，保護環境。
這個訴求很高尚，然而並非所有人都可以理解。但是如果你換個角度說「經常開空調容易導致關節疼痛與呼吸道疾病」，這種說法直接將少開空調與用戶的利益相關聯，可能說服力還更為強些。
產品經理與開發人員的溝通也是同樣的道理，嘗試從開發的角度出發，尋找對方的利益點，作為溝通的突破點。
如果你一直跟開發說這個項目很緊急，這個項目對公司來說很重要，希望早點上線，可能他還是依舊根據自己的節奏來走，未能達到你的預期，因為你沒有切中他的利益點。
這時候你除了需要按照項目指定的時間節點定期跟進開發的進度外，還可以給予正向激勵與反向激勵。
所謂的正向激勵，指的是你做到了，對自己有什麼利益。
比如當遇到某個技術難點時，某些開發人員可能會先覺得很麻煩，產生了抗拒心理，但是換個角度想，如果開發人員如果集中精力攻克後，其實是有利於自身的能力提升與職業成長的，這個可以成為其中一個激勵的要素。
所謂的反向激勵，就是你做不到，對自己有什麼利益損失。
比如你跟開發說，根據公司的要求，新開發的功能本週五必須得上線，否則可能需要辛苦團隊人員加班加點，為了不周末加班，一般大家都願意做一下衝刺。
當然，這個得建立在對開發工作量有合理的評估基礎上。
職場上的正向激勵一般包括物質的（薪酬福利等）與精神的（職業晉陞與成才、團隊認可等），適當利用某些激勵要素，會有意向不到的效果。
三、維護好你的PRD文檔
PRD是產品經理需求方案的表達形式，是產品經理與開發同事精準的溝通工具。如果PRD本身的質量不高，將會影響開發效率與質量。
關於PRD的規範與標準，各個公司的要求可能還不一樣，但是核心目標都是一致的，就是要清楚的向開發、測試同事轉達你的需求，說明白你想幹什麼。關於PRD，有以下幾點建議：
1. 產品解決方案的核心環節必須保證邏輯的嚴謹性，避免低級錯誤
如果一個解決方案的核心環節都出現了原則性的錯誤或者出現了某些非常低級的錯誤，那麼在需求評審環節，就已經讓開發同事對產品經理的能力產生了質疑。
心理學有種效應叫「刻板印象」，就是一旦某個不好的印象在心理已經產生了，那麼就會長期形成一種固定而籠統的看法，當他人對我們失去了信任，那麼後面幹什麼事情都不會太順利。
2. PRD文檔要注重邏輯，而不止描述
什麼是邏輯描述呢？傳統的軟體需求分析領域，在對一個use case（用例）進行需求的細化時，往往會包括以下幾點：前置條件（即用例出現的前提條件）、主幹流程（即正常流程）、後置條件（即流程結束後本體的狀態）、分支流程（即異常流程)。
在這裡並不是要求大家嚴格按照這種格式去寫需求，只是建議大家在描述一個需求時，要從開發同事的角度出發，想想如何表達，才能讓開發清楚的知道產品需求是什麼，而不是模稜兩可，一頭霧水。
但是如果這名開發同事比較盡責，他會追著你問細節，但這也造成了效率低下的問題。如果這名開發同事稍微缺乏點耐心或者責任心，他可能直接就開懟了或者按照自己的想法去實現，反正需求文檔沒有寫清楚。
下面舉一個文檔描述的反面與正面例子：
錯誤的做法
正確的做法
3. 文檔更新要及時
需求方案在落地開發的時候，不可避免的會產生需求的變更，比如因技術問題需要對需求進行調整、產品經理的PRD未考慮到某些異常的場景，需要補充需求說明等。
考慮到這時候需求已經進入開發階段，產品經理可能會先跟開發人員口頭或者線上溝通具體的調整方案，然後開發同事可能就先行調整代碼了。
這時候產品經理務必要將調整後的結果及時更新到需求文檔，並且知會相關人員，主要是開發與測試同事。
這樣子做的目的在於讓工作有跡，一般產品驗收的標準以PRD為準，如果PRD未更新，那麼可能出現開發當時口頭承諾可以，但是因為其他事情忘記了，導致需求未實現，但是文檔也未更新，很容易導致雙方的扯皮。
4. 需求變更得謹慎
產品經理變更需求是正常的，任何方案都沒辦法做到十全十美。
但是在變更需求之前，產品經理需要仔細分析，不要隨意調整，若真的有變更的必要性，需要明確方案，並且跟開發人員溝通需求變更的背景，爭取對方的諒解。
沒有嚴謹的分析思路，想到什麼就做什麼的風格，容易導致方案存在考慮不周全的風險，繼而引發下一次的需求變更，開發人員是很抵觸產品經理經常性的需求變更的。
首先這個東西，開發已經投入了時間精力去完成了，最終確因為需求不明確而需要多次返工；其次，長期如此，會讓開發人員對產品經理越來越不信任，質疑你的能力。
四、掌握一些基本的開發知識
關於產品經理需不需要懂技術，這是一個被大家討論了很多遍的話題了。我覺得只需要懂一些基本的開發知識就可以了，如果是從事B端設計的產品經理，對開發知識的掌握要求還會稍高些。
掌握適當的開發知識便於我們提需求的時候可以考慮技術的可行性與投入成本，在跟開發溝通、轉達需求的時候能夠更有效率。
有些產品經理甚至會去學習如何編程，這個我認為投入產出比不是很高，實在不建議。
在這裡向沒有任何技術背景的初級產品經理推薦這本書《給產品經理講技術》，在微信讀書可以找到。這本書主要講解一些入門的技術概念，稍作了解即可，不需要太扣裡面的技術細節。
下面跟大家分享幾個我覺得需要關注的一些技術常識或者與開發人員在技術方面的溝通技巧。
1. 瞭解最基本的前端、後端分工
簡單粗暴的說，前端一般負責用戶操作界面的展示、交互處理，後端一般負責底層邏輯的實現。
這樣子說可能還是有點抽象，就拿最常見的登錄功能來說吧。你打開某個系統進入登錄界面，輸入賬號跟密碼，點擊登錄，最後成功進入APP。
這裡登錄界面就是前端操作界面，負責把需要填寫的欄位展示給用戶（賬號與密碼），並且用與用戶產生交互(輸入/清除賬號、密碼)。
當賬號與密碼輸入完畢，點擊登錄按鈕後，前端會把登錄請求傳送給後端伺服器，後端會根據資料庫表對賬號跟密碼進行校驗，後端會把結果返回給前端。
如果賬號跟密碼均正確，後端會通知前端登錄成功，否則就會通知對應的錯誤類型（比如賬號不存在、密碼錯誤等）。
瞭解基本的前後端分工的好處在於：
- 在前期的需求溝通環節，可以幫助產品經理了解本次功能模塊的責任分工與前後端大致的工作量，有助於產品經理做項目進程的管理；
- 當產品出現問題時，產品經理可以快速判斷問題在於前端還是後端，便於快速找到對應的責任人進行溝通，避免出現產品經理無法定義問題的歸屬，把後端的問題拋給了前端，或者把前端的問題拋給了後端，這會影響我們的工作效率，如果長期如此，也會影響開發同事對我們的耐心。
2. 與開發的溝通重在邏輯
有時候我們跟開發同事溝通的時候，他們很容易就突然冒出很多技術術語，你還沒來及反應過來，對方已經表達完了。因為開發人員有自己的思維習慣，他們需要從技術的角度向外界闡述自己的觀點，這個是正常的。
遇到這種情況，我一般會謙虛的請求開發同事把我覺得有疑惑的地方重新表述一遍，有些時候我還會讓其用紙筆畫出對應的邏輯思路，方便我直觀的理解。
如果涉及到後端，則會更為複雜些，後端重在邏輯的搭建，所以產品經理一定要明白對應功能點的技術實現邏輯，甚至有時候你可以指出某些邏輯上的漏洞。
多跟開發溝通，久而久之，你會發現，跟他們溝通起來會越來越輕鬆。
當開發同事說某個功能不好實現或者無法實現時，我習慣通過這種方式去了解背後的原因，有時候你會發現開發的邏輯是存在漏洞的，或者對需求的理解有誤，這才導致功能實現的出現了難度。
3. 不懂多查，不懂多問
當我們跟開發溝通時候時，你可能聽不懂某個術語，比如開發說這個下載功能我用的是非同步處理方式，這個時候如果你不懂這個東西，就得多問了。
平常自己看到某個陌生的技術術語，可以多百度，基本上多看幾遍就知道是怎麼回事了，技術術語是溝通的關鍵，我們需要多主動去了解。
比如什麼是同步、非同步、API、URL、APP技術框架（Native App、Web App、Hybrid App）、寫死，瞭解相關技術術語，相當於掌握了與開發溝通的語言，是自己專業素質的體現。
五、維護基本的人際關係
雖然這個是一個人盡皆知的大道理，但還是在這裡提出來。如果你的人際交往能力不錯，那麼跟開發維持友好的人際關係將能使自己的產品工作事半功倍。
你跟開發關係不錯，他可能會幫你提出產品的某些問題，你的需求他也願意幫你完成。
有些時候，產品經理跟開發人員可能到了水火不容的地步了，這個其實不太利於工作的開展。
當然了，不是誰都有能力可以把周邊的人際關係處理得很好，但是互相尊重，互相理解，減少不理性的衝突與矛盾，這是我們的一個理想的目標。人際溝通與交往是一門藝術，值得我們好好琢磨。
六、寫在最後
一個好的產品，背後往往有優秀的產品經理與優秀的研發人員，外界喜歡把產品經理跟研發人員的關係調侃成互相對立的局面。
我相信大部分的研發人員不會因為產品經理不是技術領域的專家就產生排斥，但是產品經理需要不斷提升自己的專業能力與溝通協作能力，爭取得到開發人員足夠的信任，這是一個需要長期努力的過程。
- 專業性是基礎。對於業務不專業的產品經理，對於開發的傷害是最大的。菜就是原罪，專業性是一切關係的基礎。人脈不是混出來的，你的能力在哪個階層，就只能在哪個階層混。尊重強者是大自然的普遍法則。所以，要想和程序猿搞好關係，首先要提高自己的專業性，一味的跪舔只能成為舔狗
- 真誠，和其他人搞好關係（不僅是程序猿），我覺得最重要的一點是：真誠。永遠打明牌，做人要敞亮，是自己的鍋不推脫及時認錯，不是自己的鍋也不要窮追猛打。以前帶我的飯大說過一句話：以單純應對複雜，以複雜保護單純。
- 擺正心態，還有一點也很重要，要在心態上先把對方當成合作夥伴來看待，不要割裂雙方的關係，你是怎麼對別人的，別人也只會怎麼對你。
- 具體實操就很多了，完成大版本，請大家喝杯奶茶；關注下朋友圈，點贊評論啥的不能少；平時主動找他們聊天，可以是請教問題，可以是找他們幫忙，可以聊人生，聊職業。如果你們能一起吐槽，那說明他們把你當自己人了，關係到位了。
請開發喫飯，進行表面意義上的拉關係、social都是治標不治本的行為。LZ作為一名略微社恐的產品經理，在工作中不僅與開發保持著非常良好且密切的合作關係，而且也很少出現開發不配合、不理解的情況，相反，雙方之間的信任關係隨著多個項目變得越來越堅固。
核心關鍵在於：要知道如何和開發和諧相處，首先要明白產品經理與開發恩怨的根源在哪。
Q：Why開發經常懟產品經理？
如果進行一下換位思考，就能很清晰的理解開發的訴求。每個人都希望自己的無效工作量能最小，而產出最大化。從這個視角來看，開發日常對產品經理的怒點無非可以歸結為以下幾點：
【1】需求不明確，產品經理自己都沒想清楚要什麼，開發無法執行（例如關鍵邏輯沒理清就push開發開工）。
【2】需求不穩定，頻繁向開發改需求，開發做的無用功多。
【3】需求不現實，對技術缺乏基礎理解，需求所隱含的實現成本過大，而產品經理並沒有意識到這一點。
【4】需求沒結果，面對技術吭哧吭哧做出來的功能，要不是沒能像預期那樣用起來，要不是具體達成了什麼效果沒有進行評估和反饋。
那麼，要和開發搞好關係，就要避免踩上述「雷區」，具體可以：
【1】避免需求不明確，意味著產品經理在提出方案前要最大程度夯實自己的方案。包括方案能夠實現的價值是什麼，如何推導出這個價值，論證過程是否嚴密，具體實現方案的邏輯應當是什麼。
總而言之，就是要講清楚：為什麼要幹這件事情（開發如果做了這件事情不是無用功），應該如何幹這件事情（明確清晰的prd，流程圖）。
【2】避免需求不穩定，如果能按照第一步去做，很大程度就能避免頻繁改動prd的情況。
但是如果遇到不可避免改prd的情況，應當採取「商量」的方式溝通，而非直接「通知」程序員。
首先，應當說明為何出現改prd的原因；其次，一起討論改動所帶來的排期、實現方式等變動影響。雖然從職責上來說，產品經理掌握著產品迭代方向的決策權，但要時刻保持傾聽，才能換來團隊合作中他人的尊重的配合。
【3】避免需求不現實，很大程度上意味著需要一些技術功能的積累。
如果作為一枚沒有技術經驗的小白，不能從客觀上判斷工作量時，一方面可以閱讀部分入門書籍進行學習；另一方面，可以」謙虛、深入「地向開發討教，即當開發說做不了的事情，進一步詢問技術原理具體是什麼，為什麼難以實現。
只要謙虛、誠懇、禮貌，開發很多時候是願意解答的。交流多了，小白產品經理也能積累一些技術素養。同時也能防止被一些不想幹活的產品經理忽悠。
【4】避免需求沒有後續，意味著很多時候可以主動向開發聊一聊需求上線後的效果。
如果需求沒能像之前一樣得到運用，或者數據效果不好，可以告知開發原因，同時在之後的工作中規避這類問題。如果需求上線後的用戶效果突出，也可以向開發反饋反饋，一起分享成功的喜悅。
基於「好結果有成就感，差結果能找原因」的反饋體驗，在下次尋找開發和你一起做項目時，他的配合程度和信任感就會有非常大的提升。
總而言之，任何人都喜歡在工作中有一個靠譜的合作夥伴。如果產品經理能夠從根本上構建這種信賴關係，那麼就能與開發搞好關係建設。
1.產品團隊架構，例如很多不小的廠都會設置項目經理來幫產品建設開發；
2.善於溝通，有時候說女孩子適合做產品經理一般還真是對的，因為女性一般溝通時比較溫柔；
3.技術上，產品經理懂數據流程，懂演算法是可以與開發有更多的共同語言；
4.需求環節 前置與開發的溝通時間點 幫助開發可以預選做好準備；
5.整個過程對事對需求，對目標，不對人。
6.練習辯證思維和戰略格局觀
產品經理與開發的梗大部分都是互鬥、互懟。彷彿這兩個職業是有你沒我，有我沒你，是天生的對頭。但根據自己從業多年的經驗，既做過開發又做了產品經理，對這兩個職業都有親身經歷，加上自己和開發關係都還比較融洽，其實雙方的關係是可以改善。
當然，一方面如果是一個新成立的團隊，那麼雙方需要一些時間磨合，另一方面雙方關係的好壞是需要兩者共同努力。但作為產品經理有責任和義務維護團隊的關係，我會更多的是站在產品經理的角度來闡述需要產品經理改進的，畢竟我們能改變的只有自己，讓別人和我們相處更愉快，也是一種能力。在日常工作觀察中，如果產品經理可以在下面兩個方面得到提升，那麼開發往往和你的關係會比較融洽。
專業
作為產品經理，首先，你自己的本職工作要做好，讓別人覺得你是專業人士。在和研發人員做溝通交流時，要能順暢的表達你所想要的，讓研發人員聽得懂。在提交PRD等文檔給研發時，要確保文檔前後邏輯一致，文檔框架清晰，內容完整，最重要的是確保能實現商業目標。
獲得認可
讓研發人員認可你，這點在我看來很重要。我本人是研發出生，做了三年開發工作。在技術方面有一定了解，因此在和研發溝通時，可以直接用技術對話，雙方溝通效率和效果就很高，也避免了很多歧義。
產品經理具備技術能力，有一定的技術工作經驗，它所能帶來的好處，遠超乎你的想像。當然，這並不是因為需要產品經理自己做研發，而是需要產品經理有技術的思維，能評估技術可行性、能和研發高效率的溝通。我們希望產品經理是一個獨立的個體，不需要依附於其他人才能做出必要的決斷。
它會從根本上拓寬你的技術視野，並能夠讓你與技術人員和設計師進行更廣泛而深入的討論。它還會讓你更好地理解技術實現的力量。
如果覺得對你有幫助，就點個讚唄，十分感謝！
推薦閱讀：
