產品經理和程式設計師，在很多人看來他們是不共戴天的兩個群體，但實際工作中，他們的關係更傾向於相愛相殺。作為一個產品經理，如何和程式設計師搞好關係，合作共贏呢？本文作者根據自身工作經歷，分享了一些經驗，一起來看看吧。

在很多段子裡，產品經理和程式設計師都是相愛相殺的生死冤家，而在真實工作中，對於很多初入職場的產品新人，確實也會面臨如何與開發相處的困惑。經常是你提需求他說實現不了，你評審他質疑為什麼這樣設計，上線出了問題他說是你方案沒考慮到……難道產品經理和程式設計師真的就不能和諧相處麼？

你好，我是當過7年武警國防生，工作 3 年躲過 6 輪裁員，現在大廠做產品的小雨。

回顧自己 4 年產品生涯最自豪的事就是基本跟每個深度合作的開發都配合得高效又愉快。其實最初我跟開發也是衝突頻頻，直到在實踐中摸索出 3 招，才跟開發處成了兄弟。現在開發們不僅不砍我需求，還會主動提最佳化建議甚至自閉環最佳化上線，遇到緊急需求也都是無條件配合。那麼我是如何做到的呢？ 今天就把這 3 招教給你。

一、產品方案要靠譜

一個值得被開發信任的產品經理，最重要的特點就是專業度高。

你要確保自己出品的每份 PRD 都屬精品。

需求背景調研廣泛、資料充分，方案框架流程清晰、邏輯自洽，需求詳情細節詳實、邊界明確。這裡我不做詳細介紹，你可以多參考優秀的PRD範本。

除了 PRD 寫得好，體現專業度還有一個要點是：每個產品決策都要有依據。

不管是基於使用者場景分析、競品調研，還是依靠資料洞察，要能在開發提出質疑前就先把關鍵問題解答清楚。

那麼靠譜的產品方案為什麼能讓開發立刻對你刮目相看呢？

第一，更容易拿到符合預期的結果，有助於他們述職和晉升；第二，他們不用考慮太多產品邏輯，按照方案設計技術實現即可，節約時間精力；第三，能最大限度避免因為考慮不周造成的線上問題，他們背鍋踩坑的風險更低。

舉個我自己的例子，我認識很多產品經理PRD都寫得很簡單，背景一筆帶過，需求配合原型圖做簡單描述，缺乏邏輯細節，有時候甚至出現“一句話需求”。因此他們在評審時經常會被開發打斷確認邏輯，有時雙方甚至在會上撕逼。

而我的PRD，從詳細的背景調研，到清晰的流程圖、用例圖，再到各種邊界場景的展示互動邏輯一應俱全。

甚至在對於優惠湊單引導欄這種複雜邏輯的描述之後，我都會列上case表格，窮舉各種可能的場景和處理方式。

開發根據我的PRD可以直接進入技術方案設計，因此我的評審會基本都非常高效，甚至不會收到提問，會後也很少有Todo。

這不僅保障了需求的質量，還讓我能在評審完上一個需求後安心投入下一個需求而不用擔心被打斷。

要知道沒有一個開發是不願意與專業產品經理合作的，因此要想跟開發和諧相處，最有效的辦法就是讓自己變得更專業。

二、把開發當做共創夥伴

雖然大家都想工作得更輕鬆，但其實沒有人心甘情願變成工具人。不把開發當工具人，而當做方案的共創夥伴，是你需要培養的理念。

具體怎麼做呢？我的建議是：

方案階段預溝通+評審階段背景同步。

很多產品經理為了省事，習慣完全敲定產品方案後直接拉需求評審。

對於簡單的小需求這樣做無可厚非，但對於複雜的大專案，

跟開發進行預溝通不僅能提前瞭解技術上的難點，還能透過開發視角感知上下游改動，及時引入相關方避免造成需求遺漏。

比如我以前不做預溝通，經常出現評審會上發現還涉及其他模組改動，但是沒拉相關產研，導致整個專案節奏受到影響。 後來習慣預溝通後，不僅沒再出現沒拉相關方而重複評審的情況，還能對開發成本有所預期，提前考慮砍掉某些低ROI的需求點。

還有些產品經理評審時花在同步背景上的時間就少之又少，這樣做雖然看似能節約時間，卻會造成開發們一頭霧水。開發們只知道產品想做啥，卻不知道為啥做，不僅難以貢獻自己的想法，還容易對需求提出挑戰。

因此我建議：

無論多簡單的需求，都要進行詳細的調研，把背景和目標完善清晰。

在你做到這些的基礎上，甚至可以對方案中一些拿不準的邊界邏輯寫上一句“以技術方案為準”。

當你花功夫這樣做，不僅能讓需求本身更靠譜，而且對開發的感受同樣有益。

首先能給開發帶來業務參與感，感受到自己寫的程式碼將創造的業務價值；

其次也能讓他們在明確需求目標的前提下，以技術視角給出自己的建議，從而對專案產生歸屬感和成就感；

最後也是最重要的，能感受到你這個產品經理給予他們的尊重和信任。

反之，如果你不這樣做，開發就會因為感受不到專案對業務的價值和你對他的尊重，而逐漸喪失做專案的動力和跟你配合的熱情，成為擺爛的工具人。

我認識個姐們，她是一個非常強勢的產品經理，要求對自己的需求掌握“獨裁”式的話語權。

只要開發提意見她就會擺出一副“我是產品還是你是產品的”姿態，結果跟她合作的開發都不再主動。

有次她一個大需求忘記寫需要上線的客戶端了，開發預設就只支援了主App端，結果微信小程式等其他幾個核心客戶端都沒上線，甚至因為沒做端控而出了線上問題。當大老闆氣勢洶洶找來時，開發們紛紛表示是產品沒提其他端需求。其實功能同步迭代各個客戶端早就應該是大家的共識，而她由於平時把開發當工具人，這次不得不自食惡果。

當你開始跟開發一起共創方案，你們就不再是上下游的合作方，而是同一條船上的夥伴，彼此信任，共同前行。

三、給予充分的理解和支援

很多人都知道職場中與人為善，處理關係的法門是具備同理心。那麼產品經理要如何做才能讓開發們感受到理解與支援呢？我的答案是：

平時不壓迫+關鍵時刻挺身而出。

平時不壓迫的具體表現包括不催排期和接受延期。

除非有不可抗力否則絕不要求倒排期，評審後不著急催排期。給開發充分的時間做技術方案設計，並基於技術方案給出客觀的排期。

如果開發過程中出現意外情況，比如系統複雜度超預期，或踩了之前留的坑造成未評估到的額外工作量。你要能積極參與其中明確問題，考慮是否可以把那些造成實現複雜度提升但重要性較低的需求點放入迭代。如果確實有必要做，則要能接受延期。明確延期後，積極協調測試確定新的排期，並做好各方資訊同步，保證下游影響可控。

除了正常專案推進過程中不壓迫，你還要能在發生線上故障等關鍵時刻挺身而出。

線上故障的發生率和影響面與開發的績效息息相關，沒有一個開發不討厭處理故障。而此時你作為他們的堅強後盾，應該勇敢地站出來幫助協調相關方配合解決問題。並在事後積極配合覆盤，提出一些建設性意見避免後續再犯相似錯誤。

如果你能做到這些，開發們的感受如何呢？

當你停止壓迫，就不會激發開發們的牴觸情緒，不僅能讓他們更主動，還能避免因為估時不準造成的加班，或者故意拉長排期導致專案延期。

當你在關鍵時刻挺身而出，他們會感受到被理解和支援，從此不再只把你當做提需求的產品經理，而是榮辱與共的戰友。

我也是付出了一些代價才明白了這個道理。

我剛進入大廠時，由於急於求成，經常強勢地催排期，需求不滿足預期時，我甚至會拉開發老闆來進行施壓。

結果有一個跟我合作的前端因為壓力太大而失眠痛哭，這件事傳到了前端組，我的口碑一度變臭，以至於從前端老闆傳到了我老闆這兒。於是我有了第一次被老闆 1 v 1 約談批評的經歷。

這件事後我深刻反省了自己的問題，不僅不再施壓，還在很多關鍵時刻幫開發擋掉容易踩雷的噁心需求。

而跟那個被我逼哭的前端同學，我們喝了幾頓大酒敞開心扉，最終處成了能互相幫彼此背鍋的兄弟，雖然他現在已經另謀高就了，但我們還時常保持著聯絡。

用實際行動給予開發們理解與支援，他們也會給你最有力的回報。

四、最後的話

產品經理是一個充滿挑戰、細碎、心酸的職業，獨自面對職場的暴風雨是難以走遠的。

最好的成長策略是與身邊的合作方結盟。

跟開發處成兄弟不僅是一種選擇，更是高階產品經理的一種能力。

我總結親身經驗給你分享了 3 招：

首先，拿出靠譜的產品方案，體現你的專業度；

其次，把開發當做共創夥伴而不是工具人；

最後，用實際行動給予開發充分的理解與支援。

掌握這 3 個原則，相信你也能在苦逼的職場中，交到一些可以長久走下去的開發兄弟。

本文由 @小雨雜談 原創釋出於人人都是產品經理。未經許可，禁止轉載。

題圖來自 Unsplash，基於CC0協議。

該文觀點僅代表作者本人，人人都是產品經理平臺僅提供資訊儲存空間服務。