産品經理如何與研發打交道？

産品經理這個崗位經常需要和研發人員進行溝通，這個過程中，産品經理就需要掌握一定的溝通技巧了，有效的溝通才可以最大程度地提升效率。這篇文章裡，作者總結了一些溝通秘訣，一起來看。

産品經理是一個需要經常與研發人員進行頻繁溝通的崗位，挂着“經理”級别的頭銜，卻沒有指揮指令别人的實權。隻能靠一張嘴，去販賣你的産品理念，讓研發部門的小夥伴幫你去實作。

如果你在産品研發過程中總是充斥着各種“吵架”，那一定是你的溝通方式出了問題。

專業技術如果是硬實力，溝通能力就是軟實力，軟硬兼備，才能成為一個合格的産品經理。

一、産品和研發之間存在的溝通問題

作為産品經理，研發人員說的讓你記憶最深刻的一句話是什麼呢？

• “這個需求實作不了。”
• “這個改動太大了，做不了。”
• “這個需求文檔沒有定義啊！”
• “這個得重新做了。”
• “這個功能設計的不合理。”
• “這是第三方的問題，我解決不了。”
• “xxx幫忙催一下啊！”——“為什麼要我催啊？”——“你是産品經理啊！”
• ………

那麼，反過來，研發人員内心對産品經理的獨白又是什麼呢？

（都不算内心獨白，大部分研發都是耿直boy，有啥不爽都是對着你的臉開噴，從不需要考慮你的感受，就是這麼屌炸天！）

• 又要改需求，我X！
• 産品經理整天都在幹啥啊，需求寫的這麼垃圾。
• 我跟你解釋這麼多幹嘛，你又聽不懂，我懶得跟你解釋。
• 這麼奇葩的需求還非得讓我寫代碼實作！
• “這個需求很簡單，怎麼實作我不管，明天就要上線。”——你個沙雕。
• ………

程式員吐槽大會中有人說，産品經理和程式員就像唐僧和孫悟空：

• 唐僧：“我就要取經。”
• 孫悟空：“那得殺了白骨精變成的妖怪。”
• 唐僧：“不能濫殺無辜。”
• 孫悟空：“那怎麼辦？”
• 唐僧：“我不管，我就要取經。”

這段話多麼形象的描述出産品和研發之間的沖突，雖然目标一緻要取得真經（産品上線），但取經路上總是充滿了争執。

溝通就是解決你和研發之間diss不斷的一種有效方式，掌握一定的溝通技巧，可以讓你與研發和平共處在一個“水泥格子間”這種壓抑的空間裡，保持心情愉悅。

二、分享10條和研發的溝通經驗

1. 明确團隊作戰的目标

• 研：“這個需求開發預計要兩周的時間。”
• 産：“就這麼簡單的功能，要那麼長的時間嘛？”
• 研：“你看下你設計的功能多複雜，涉及到的改動點很多。”
• 産：“我覺得你在框我，最多一個星期就可以完成。”
• 研：“那我做不了。”
• 産：“那我不管，一個星期就得上線。”
• 研：“你不能每次都這樣，這麼短的時間怎麼做？”
• 産：“我哪裡有每次，明明就是你們故意把時間估長。”
• 研：“那你需求要設計的這麼傻B我有什麼辦法？”
• 産：“我需求設計成什麼樣，要你來教嗎？我是産品經理我說了算！”
• 研：“你是産品經理了不起啊，你要能寫代碼你來寫呀！”
• ………

産品經理在跟研發的溝通過程中，雙方經常會因為觀點的分歧而發生争論，有時候争的面紅耳赤、口吐芬芳，甚至都開始人身攻擊，從否定這件事情，到否定對方做人有問題。

最後，也不知道争論的問題是什麼，演變成了一場完全沒有意義的“口水仗”。

為什麼會出現這種毫無意義的“口水仗”呢？

因為，沒有目标傳導，大家做事情的方向不一緻。研發認為做産品是給産品經理做的，而不是給客戶做的，不是為了公司的業績去做的。

為此，就很容易出現，産品經理想什麼是你産品的事，我研發想怎麼做是我研發的事。彼此不在一個方向上使勁，甚至還會在對立的方向上互相較勁。

是以，在做産品之前，你需要告知研發團隊做這個産品的目标是什麼，做這個産品可以給客戶帶來哪些價值，給企業帶來哪些收益。

這樣大家才能“心往一處想，勁往一處使”。

2. 講需求告知前因後果

• 産：“這個功能你怎麼給我改成這個樣子了？誰讓你改的？”
• 研：“我覺得改成這樣資料結構比較合理，邏輯上也更簡單。”
• 産：“問題是你改成這樣子，客戶用不了啊！”
• 産：“客戶是因為xxxxx，是以才需要做這個功能。”
• 研：“啊！你開始沒跟我講，我怎麼知道？”
• 産：“這種東西還要講嘛？”
• 研：“廢話，我又不是客戶。”
• …….

在一個需求的決策鍊條上，産品經理掌握了來自客戶、銷售和上司提供的各種資訊，清楚自己為什麼要這樣做功能設計。而作為需求鍊最末端的程式員，因為情報資訊的閉塞，就隻能自己去意淫産品的使用場景，這樣就容易做出來的程式偏離實際，帶來糟糕的使用者體驗。

是以，産品經理在給研發講需求的時候，一定要結合客戶實際使用場景去介紹，為什麼功能要這樣設計，這樣研發才不會按照自己的了解去進行架構設計。

最好的方式是可以講一個故事：什麼人，在什麼時間，什麼地點，做了一件什麼事情，遇到了什麼樣的問題，希望怎麼樣去解決，不解決會帶來什麼樣的後果。

故事講完了，研發對這個功能也就了解了，在做這個開發的過程中，也就知道如何去設計自己的程式更好的去解決客戶問題了。

3. 養成資訊同步的習慣

• 産：“這個功能怎麼做的和原型設計的不一樣啊？”
• 研：“我不是問過你，這麼改嘛？你同意了。”
• 産：“我什麼時候同意了？”
• 研：“我不記得了，反正是問過你的。”
• 産：“那我不管，得給我按照原型來做。”
• 研：“靠，你這不是坑我嘛！”
• ………

需求在開發過程中進行來回調整，是再正常不過的事情。為什麼會經常發生上述的争吵呢？因為，沒有證據死無對證，各說各有理。

不管做了多麼細小的需求變動，最好第一時間去更新相關的需求文檔，并進行郵件的資訊同步。

産品出了問題，即使是研發的原因，産品經理也都需要為之負責。如果有工作郵件存檔，那這個責任就不是“無限”的，而是可以明确責任界限的。

同時，千萬不要有“擔心打擾到上司”這種多餘的顧慮。所有的工作郵件，都建議你抄送給上級。如果是對外的郵件，或者是涉及重要敏感内容的郵件，還需要抄送給更上一層的上司。

一方面，是為了“有鍋一起背”；另一方面，也是為了確定，如果自己“犯傻”，能有人及時發現并提醒。

4. 用上做産品的同理心

• 研：“這個功能我們評估了一下，要做成這樣至少要一個星期的時間。”
• 産：“那我不管，這是你研發的事情，我隻管功能實作。”
• 研：“這個功能想和你讨論下怎麼實作的問題？”
• 産：“我不是做技術的，怎麼實作是你們的事情。”
• 研：“就是和你交流下，看下這樣做可不可行。”
• 産：“我都說了，怎麼做是你們技術的事情，不要找我。”
• 研：“那好吧！”
• …….

在研發的過程中，确實會遇到研發人員對于功能了解不到位，對于實作方式有疑慮的情況。這種時候，研發就想找個人一起讨論一下，不一定是要你改需求，或許隻是想和你交流下可行性。

當你可以站在研發人員的角度去思考如何實作，就可以積極去貢獻自己的想法和思路，一起去探讨出更優的技術方案。

換位思考，也有可能發現，是自己的需求文檔描寫的不夠詳細，描述的不夠清晰，容易讓人不好了解，甚至産生誤解。

是以，不要和研發在崗位職責上把界限劃的太清，大家組成一個團隊就是要一起去解決問題，一起去保障産品的順利上線。

5. 不做資訊的“搬運工”

• 研：“X工，幫我問下xx他們的接口文檔什麼時候可以給出來？”
• 産：“這個問題你不可以自己去問嘛？”
• 研：“誰叫你是産品經理啊，當然是你去問了。”
• 産：“他們說沒有那麼快，還需要一周左右的時間。”
• 研：“那你再幫我問下，可不可以先提供xx這部分的接口，我先看下。”
• 産：“你有問題能不能一起說完？”
• 研：“我也是剛剛才想到的。”
• 産：“我沒空，你自己去問吧！”
• 研：“那這個功能就不做了。”
• …….

如何高效的開展工作，如何讓自己的時間産生的價值收益最大化？首要避免的就是去做資訊的“傳遞員”、“搬運工”。

最好的方式就是建群，遇到相應的問題@相關的人員，需要哪些資源@相關的人員。

盡量避免産品或項目上的事項，進行一對一的私聊，最好都在群裡或發郵件溝通讨論，讓所有人都可以看見。

這樣既可以提升溝通的效率，也能減少因為自己腦子突然短路，沒人提醒帶來的風險。

6. 把上司充當“擋箭牌”

• 研：“這個需求有點複雜，改動起來的工作量太大。”
• 産：“你是想說什麼問題？”
• 研：“能不能不要這樣做？”
• 産：“沒辦法，上司要求要做成這樣，要改你問上司去。”
• 研：“好吧，就當我沒說。”
• …….

一般來說和你溝通的都是同一級别的，說白了幹活的都是小兵，你派單，他幹活，老闆發錢。

是以，當遇到不好溝通解決的問題時，把老闆“端”出來，很多問題就迎刃而解了，畢竟沒有到要離職的份上，誰沒事會頭鐵到去找老闆理論。

就算這個需求是你提的，你也可以說是老闆要的，總不至于會有研發人員真的去問老闆，你為什麼要提那樣的需求？

當然這個“核武器”，不能常用，更不能亂用，要不等到真正要用的時候就失去了威懾力。一定是确實遇到溝通不了，僵持不下的時候，才把老闆“搬”出來。

7. 一定要有“資源”意識

• 産：“大家停一下，這個需求客戶要求改一下。”
• 研：“啊？我都開發完了，準備提測了。”
• 産：“那沒辦法，客戶說要改的。”
• 研：“為什麼一開始不問清楚，這個時候來改，前面的不都白做了嘛？”
• 産：“我也沒有辦法～”

……..2000 years later……….

• 産：“停一下，客戶後面還是覺得之前那個方案比較好，要改回去。”
• 研：“我靠，你這不是玩我嘛？”
• 産：“哎，說清楚，不是我玩你，是客戶要這麼玩。”
• 研：“那就是你需求沒有搞清楚。”
• 産：“我是産品經理還是你是産品經理？”
• 研：“你是産品經理，你牛逼！”
• ………

做産品研發的過程中，最怕的就是改需求，更可怕的是來回改需求。

這個時候，産品經理就得有“資源”意識，每一次需求的改動都是有成本，不能總是把刀口向内給研發一頓嚯嚯，也得硬氣幾回把刀口向外跟客戶講講道理。

要尊重研發人員的工作成果，涉及到需求改動甚至需求要砍掉的時候，盡量要跟大家說明白為什麼，多說幾句大家辛苦了的話。

這個時候要是再擺出一副“地主”心态，不管大家的死活，隻管收租要成果，早晚大家不得高舉“打倒地主老财”的大旗，拿你祭天解氣。

8. 别拿完美主義“作祟”

• 産：“這麼明顯的bug都測試不出來嗎？怎麼測試的？”
• 研：“我在測試環境的時候沒有出現啊！”
• 産：“現在就是使用者使用的時候，出現了，别跟我說測試環境。”
• 研：“那你驗收的時候，怎麼沒有發現？”
• 産：“我就是不驗收，你也得保證産品100%沒有問題，要不要測試幹什麼。”
• ………

做産品經理時間長了你就知道，項目過程中總會伴随着各種問題，即使測試了很長時間，在産品上線後還是會出現一些非常明顯或者莫名其妙的bug。

這個時候就立馬甩鍋給研發，沒有任何意義，想着如何快速修複bug，避免後續再出現類似的問題才是應該去做的事情。

在産品開發的過程中，總會因為資源有限，時間緊迫，面臨一些功能的取舍問題。如果一定要去強迫研發人員按時按質完成産品的上線，鐵定會導緻研發人員産生抵觸的情緒，最後即使按時上線了，産品品質也是小坑不斷，大坑難填。

你如果不能保證産品需求100%不改動，并且沒有邏輯漏洞，那就不要去要求研發和測試100%不出錯，沒有bug。

9. 化身客戶催項目上線

• 産：“這個功能還有多久上線？”
• 研：“還要評估下這個功能怎麼實作，現在給不出時間。”
• 産：“能不能給個大概的時間？”
• 研：“給不了。”
• 産：“這個月底上線，可不可以？”
• 研：“時間太短了，上線不了。”
• 産：“下個月初客戶要舉行一個釋出會，到時候會有上級上司來參觀考察。”
• 産：“客戶釋出會的時間已經定了，改不了。”
• 研：“那既然這樣，就隻能周末加班搞了。”
• …….

在做項目研發工時評估的時候，産品經理總是會擔心研發人員虛報工時，糊弄自己。

明明一天可以做完的内容，非得說三天才行。而客戶要求上線的時間又擺在哪裡，不能按時上線的話，到時候銷售還不得跟個“你欠他錢”似的“催死你”。

這個問題最好的解決方式，就是把你自己化身為客戶，說明下為什麼要在xxx時間内上線，不上線會有什麼問題風險，按時上線會有收益好處。

比如，上司要來視察；項目資金必須要在xxx時間節點付不出；xx月xx日正好是一個特殊的日子，公司需要借此時機宣傳造勢把産品推出去。

當然，還是會存在這種情況：就算把刀架在脖子上，把研發殺了，在客戶規定的時間内也上不了線。

怎麼辦呢？就不要去對研發“以死相逼”了，打工的何必為難打工的。

換做你是客戶，你是不是就可以有一些别的方式來解決。

比如，如果在上司視察的規定時間實在完不成産品上線，能不能先上線部分核心的功能，能不能先完成前端頁面的開發，能不能用UI效果圖先放上去呈現效果，先度過了上司視察這一關，後面再慢慢開發。

10. 必須得懂點技術語言

• 研：“這個功能你這樣設計不好做。”
• 産：“怎麼個不好做？”
• 研：“這裡每修改一次，我都要從後端接口擷取一次資料。”
• 産：“為什麼不可以先把資料儲存在前端呢？”
• 研：“好像這樣也行。”
• 研：“還有，這個資料能不能不要做成實時顯示的？”
• 産：“為什麼？”
• 研：“因為計算結果都是後端傳回給我的，後端資料都是當天晚上淩晨才會生成？”
• 産：“為什麼不可以在觸發這個按鈕，就去請求後端的資料呢？”
• 産：“為什麼一定要等到淩晨去生成資料，不可以隔10分鐘就跑一個batch呢？”
• 研：“好像這樣也可以。”
• …….

産品經理在和研發的溝通過程中，實際上讨論最多的并不是業務需求，而是技術實作細節。

但凡你不了解一些技術實作的方式，不知道技術相關的名詞術語，就有可能出現，雞同鴨講的“無厘頭式”對話。

産品經理說白話，研發人員說黑話。你說你的，他說他的，說的都不是一個事情，最後争執不下，就不了了之。

産品經理可以不會上手寫代碼，但你至少得能聽懂研發在說啥，能了解功能背後的技術實作原理。

要啥都不懂，研發人員一句“技術實作不了”，你就得屁颠屁颠回去改需求，回過頭還得感謝研發的提醒。被人賣了還幫着數錢，就是這麼傻白甜。

真要遇到自己不懂的技術術語，就問下研發人員，就去百度一下，慢慢的你不就懂了嗎？慢慢的你不就可以和研發在同一認知次元上對話了嗎？慢慢的你不就可以參與到技術實作方式的讨論和意見發表了嗎？

當然，要避免的一種情況：當你懂一些技術之後，認為自己的技術方案更合适，要求研發采用自己的方式去做，最後出了問題，就隻能是找你背鍋。要相信，每一個程式員都是自己代碼的産品經理。

最後的話：

和研發的溝通其實不需要什麼套路，不需要糾結說如何做到跟不同類型的人去打交道，因為你一直都是在和“需求”打交道。

隻要你站在使用者的角度，本着産品按時按質按量上線的目标去做溝通，就不會有那麼多的争論，更不會搞得辦公室的“劍拔弩張、戰火紛飛、硝煙彌漫”。

你有什麼和研發溝通的經驗呢？寫出來給大家看看吧。

本文由@武林 原創釋出于人人都是産品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基于CC0協定。

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