產品經理需要更多的了解非技術層面的知識，與研發溝通的能力就是其中一項。作為“沒有什么技術含量，人人都可以做”的產品經理來說，溝通能力才是最核心的價值。

我是Rookie Chan，“產品+運營”的混合崗，最近剛有的打算，把自己的工作心得，不定期的做個記錄，分享&受教。

付諸行動的第一天，寫的主題卻是：關系最好的研發離職，對產品經理的影響。就在剛剛，公司的資深PHP工程師跟老大在“小黑屋”聊了好久，出來后老大官宣了這個噩耗：小哥要自己創業去了。

當然了，小山頭我是不提倡的，所謂關系最好，翻譯一下：溝通成本最低。

看過很多調侃產品和研發勢不兩立的段子，也親身經歷過面紅耳赤的唇槍舌劍，不得不說都是講求效率的人，時間都花在了溝通上。

這里所說的溝通成本，其實是基于一定的經驗之上，對產品設計的理解去除一些基本層面的確定，直接對核心的功能和交互的實現進行探討。評審項目過需求時，各端的配合都要摳細節來確認，產品經理和研發工程師往往會從進會議室的第一刻起，就在內心有了些抵觸情緒。

搞好關系也是對自己的一種能力提升，不是說一起團建吃頓飯那么簡單。

首先，產品經理需要更多的了解技術層面的知識，自己提的需求實現難度有個大致的評估。

當然了，現在去學代碼轉研發，一是要本人有勇氣吃得了苦，二是要家里有礦捱得過積累經驗的初級階段。我都不符合，所以這里說的是了解自己的研發兄弟們的一些工作習慣。

比如用的什么軟件，接的什么sdk，有什么好的數據分析產品等等，我們確實需要把控甚至“壓迫”一下進度，但要有理有據，被回懟時也有底氣，從容的繼續“壓迫”。

其次，研發小哥的思維邏輯和產品運營的思維邏輯是有差異的，但是本質上又有著相通的部分。

用這一部分作為切入點協調，這塊主要是在需求文檔里體現。

網上有很多調侃研發的段子，說做研發的小哥哥們都有比較木訥，沒啥人情味，溝通起來比較難。對此我不敢茍同，研發都有了一定的經驗，也多少了解些每個產品經理的工作邏輯，每天都是那些代碼確實索然無味。

尤其有的時候他們辛苦做出來的東西，沒過多久就不去使用或者運營了，誰都喜歡自己做的東西被認可，但他們被認可的點可能由我們來決定。

再次，說研發聽得懂、愿意聽的話。

想節省溝通成本，往往不能做到兩者都同時各自退讓，從我做起還是可以實現的，根據之前的一些交流熟悉每個研發小哥的調調，其實產品經理也算半個心理學家了。

經常掛在嘴邊的用戶體驗，可以把研發也當作用戶，出個用戶畫像，弄個A/B測試，做個版本迭代，如果這樣跟研發還有矛盾，那產品經理要好好反思了。

最后，如果產品本身設計的確實槽點一堆，那么衷心的建議不要去麻煩研發。

不是說皮厚沒關系，你浪費了大家的時間。我也要面子的啊，不希望自己的產品被各種刪改需求，就是確定要這么做，為了達到目的，我可以一直對你笑。（last but not least）

寫在結尾：關系最好的研發小哥離職，對產品經理的影響……沒有影響！換一個人換一種溝通方式，作為“沒有什么技術含量，人人都可以做的”產品經理來說，溝通能力才是最核心的價值，祝大家工作順利，祝創業去的研發小哥商祺。

本文由 @RookieChan 原創發布于人人都是產品經理，未經許可，禁止轉載。

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