產品經理如何與開發打交道，才能實現合作與共贏？

接收程序員的 8 點技術早餐

作者｜邱岳

編輯｜馬越

在產品經理的日常工作中，開發工程師可能是我們打交道最多的角色，可是，這兩個角色之間卻有很多難以調和的矛盾，網上開發工程師怒懟產品經理的藝術作品很多，各種吐槽圖片和文章俯拾即是 。我自己寫過程序，又成為產品經理，對這個問題有一些自己的理解，今天我就根據這個話題來談談產品經理如何同開發打交道。

寫在前面

因為角色的差異，產品經理和工程師變成了上下游。也就是產品經理折騰半天，做需求收集、分析討論等等，然後做出 PRD （產品需求文檔）交給工程師之後就不管了，工程師拿到 PRD 之後做系統設計研發實施。我們希望工程師可以盡量早地參與到流程中來，產品經理則盡量晚地從流程中退出去。

本文摘自邱岳在極客時間 App 上開始的全年付費專欄《邱岳的產品手記》，已獲授權。欲閱讀更多獨家文章，請點擊文末訂閱專欄閱讀（支持微信支付）。

全流程參與

對產品經理來說，首先要做到儘可能在項目的早期去跟工程師溝通。我們在安排一些項目的早期，可能因為很多東西沒有最終確定，也不太想跟工程師說，覺得等確定了再溝通；但這樣做很容易導致說的時候已經來不及了。比如 11 月 3 日通知工程師說：「咱們 11 月 11 日大促，這是三個需求你儘快做一下」，工程師會非常反感這種帶著截止期限的突然襲擊。

最好的方式是當某個業務有苗頭的時候，產品經理就應該開始跟工程師交流，但這時候不要正式地去提需求，而是做一些非正式的溝通，否則後期如果有變化會讓工程師覺得你出爾反爾。

除此之外，一定要邀請工程師來參與項目前期的需求收集和需求評審，不要覺得這種場合不需要工程師，等確定了再轉述或者產品經理去宣講就可以了。你需要儘可能讓工程師參與，他可以更全面地了解項目和特性的目的，和不同利益相關者的顧慮和立場，也可以讓工程師理解一些產品經理對產品細節的堅持。

除了讓工程師往前走參與需求過程之外，產品經理也要主動往流程的後半部分延伸，去參與設計、開發、上線中的技術部分。比如在產品上線過程中出了 Bug，服務不可用了。

這時候產品經理應該幹什麼？可能有的人不參與，等著工程師自己處理，還有的在群里吵，誰的 Bug，什麼時候修好等等；但是，其實更合適的方式是能夠參與到問題解決中，去問一下具體是什麼問題，需不需要幫助。

很多時候工程師在考慮故障的時候，主要會去想如何把出現的問題修好，而產品經理在考慮問題的時候，可能會考慮怎樣把問題規避過去。比如說付款流程走不下去，工程師會想著去修復它，而產品經理或許可以協調一些資源，直接在某個時間段內就免費掉，先把付款流程繞過去，不損失用戶。

但要注意的是，產品經理可以參與，但不要添亂，人家工程師在緊急地寫補丁，你拉著人家說：「別寫，先給我講講。」這樣做就很不得體了。

多聽工程師的意見

我們在產品設計的過程中要多鼓勵工程師給產品經理提意見，這裡產品經理和工程師都要擺正心態。對於產品經理來說，不能聽不得反對意見，覺得工程師都是在指手畫腳。對於工程師來說，不能覺得產品做成什麼樣子跟我沒關係，反正做不好是產品經理背鍋。

跟我合作過的工程師，讓我最感動也是印象最深的都是那些能夠在業務上跟我有不同意見，提出自己想法的工程師。你會發現工程師角度提出來的想法有時會非常有價值，他們有時候會幫忙指出邏輯中的缺陷，或者從可行性的角度中提出更有創造力的實現方法。

作為產品經理，如果總是不願意聽取工程師的建議，時間久了大家都不願意跟你提建議，狀態也會越來越被動，隔閡就會越來越深，造成雙方的對立。

還有一個辦法，就是讓工程師和產品經理輪番做項目經理，當希望工程師儘可能早一些參與的時候，就讓工程師做項目經理，因為需要約各種會議，判斷利益相關者，還要理解功能的輕重緩急，這就會推著工程師去完整地了解業務。

如果需要產品經理了解更多技術細節，就讓產品經理去做項目經理，他要組織和參加各種技術評審，有時候還要判斷是否通過，也一樣推著產品經理關注到流程的後半段。

不要強迫工程師做評估

這也是我之前犯過的錯誤，我有時會強迫工程師給出發布時間點，不給的話我就說他不負責任；但是，你要理解很多時候工程師是沒辦法給出具體發布時間點的，那這種情況下該怎麼辦呢？

有時候就會有衝突，我很強勢必須要，那工程師就隨便定一個，結果還是會延期，而且關係鬧得很僵，所以如果確實很難確定工期，就不要定非常精確的時間點，可以做個模糊處理。比如 7 月 1 日交付別定成 7 月 1 日，就定成 7 月第一周，留一點緩衝。

另外，產品經理也不要代替別人做評估。比如跟業務部門交流完了之後，隨口給個承諾，說一周做完；畢竟不是你做，不要越俎代庖，最好讓工程師自己來做預判。

更不要在工程師做評估的時候去諷刺或者評價，產品經理經常會犯一個錯誤，工程師說某個功能有點難，我們就會說這有什麼難的，你看騰訊早就做出來了。工程師會很反感這種溝通方式，技術基礎不同，技術積累也不同，不能這麼簡單去做橫向對比。

背黑鍋與爭取利益

產品經理有一個天職就是背黑鍋，產品經理要勇敢地、毫不猶豫地在第一時間站出來幫工程師承擔責任。要有這樣的姿態，不要往後躲。

並不是說工程師不能自己去承擔責任，工程師一般也都不是軟蛋，但產品經理應該有這樣的意識和態度。讓大家知道這個產品經理是敢去擔當的，不能跟人家看月亮的時候叫人家小甜甜，出了事兒又喊牛夫人，長此以往工程師就不願意依賴和相信你了。

還有一個特別重要的事情，就是產品經理一定要幫工程師爭取利益，很多時候產品經理是有這個渠道的，產品經理會跟技術主管有更多的接觸。

這時候你要想辦法給優秀的工程師爭取利益，努力幫他做背書，施加你的影響力幫他晉陞，給他加薪。尤其有些工程師會比較靦腆，在爭取利益上很儒雅，那產品經理就應該要去幫他爭取，可能他很多優秀的地方或許只有你有機會看到，要勇於去表達。

互背 KPI，同仇敵愾

產品經理的 KPI 一般都是產品指標，業務指標，而工程師可能會是可用性，特性交付等等。我一直鼓勵產品經理去背一點工程 KPI，比如穩定性和可用性。這樣做一來可以讓產品經理對工程師的顧慮有切身的理解，不能說不在乎系統掛不掛，隨意上線什麼的。

另外也是防止立場的對立，跟工程師談具體項目的時候，有時候開發會以影響穩定性作為推脫，如果穩定性也是產品經理的 KPI，那很多事情就容易溝通一些，因為這個事情也會影響你的績效。

另外一個辦法叫做尋找外敵，這個說起來有點腹黑，但確實非常好用。產品和開發也是，如果你們找到一個「外敵」，這個外敵可能是競爭對手，甚至是整個領域的一個敵人，比如我是一個製藥公司，我們共同的敵人可能是癌症和腫瘤，比如我是一個做新零售的，那我們共同的敵人可能是傳統的供應鏈巨頭。

當有共同的敵人時，團隊就更容易結合在一起，科幻電影里也是，人類之間互相打，一來外星人，馬上團結起來同仇敵愾。

所以有時候大家可以適當地去樹立外敵，有些公司，具體不說什麼公司了，會故意在外面引發一些與競爭對手之間的罵戰。本來這個業務團隊內部鬧得一塌糊塗，一看老闆在外頭被人欺負了，怎麼辦，立刻變得特別團結。

當然也不是一定要罵架，對於一條產品線，你完全可以在內部找一個具體的競爭對手，把一些業務指標對標起來，大家本著這個指標去努力，這時候可能很多內部矛盾會被消解掉，團隊空前團結。

建立良好的個人關係

最後一個建議，是鼓勵做產品可以多跟工程師交朋友。我工作這麼多年，結交到的朋友大部分都是工程師。當跟他們真的成為朋友時，你會本能地考慮他們的立場，擔心他們的擔心，當然他們也會用心理解和幫助你。

我之前工作中偶爾會有自己沒處理好的事情，或者因為任性捅的簍子，有時候對應的工程師可能就會加班，甚至通宵幫我處理掉。甚至也有朋友為了保護我，幫我承擔了一些東西。這些工作量和付出其實都算是友情贊助的，也都不算是他們的績效，這些感情我一直都記在心裡。也想借著專欄的版面，向他們表達我的感激。

總 結

到這裡我們關於如何與工程師打交道的分享就全部結束了，這次我們提到儘可能讓產品經理和工程師都全流程參與到一個產品的規劃和實施中，建議產品經理多去聽取工程師的建議，不要強迫或代替工程師做評估，盡量幫工程師爭取利益等等。

所有的這些方法都只是方法，最重要的還是要始終重視打造與工程師之間合作氛圍，與工程師相互尊重，始終保持合作的態度和意識，只有這樣才能發揮各自的優勢和長處，把產品做好，把事情做成。

你有沒有讓你印象深刻的，產品經理與工程師之間合作的故事？

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！