产品经理需要更多的了解非技术层面的知识，与研发沟通的能力就是其中一项。作为“没有什么技术含量，人人都可以做”的产品经理来说，沟通能力才是最核心的价值。

我是Rookie Chan，“产品+运营”的混合岗，最近刚有的打算，把自己的工作心得，不定期的做个记录，分享&受教。

付诸行动的第一天，写的主题却是：关系最好的研发离职，对产品经理的影响。就在刚刚，公司的资深PHP工程师跟老大在“小黑屋”聊了好久，出来后老大官宣了这个噩耗：小哥要自己创业去了。

当然了，小山头我是不提倡的，所谓关系最好，翻译一下：沟通成本最低。

看过很多调侃产品和研发势不两立的段子，也亲身经历过面红耳赤的唇枪舌剑，不得不说都是讲求效率的人，时间都花在了沟通上。

这里所说的沟通成本，其实是基于一定的经验之上，对产品设计的理解去除一些基本层面的确定，直接对核心的功能和交互的实现进行探讨。评审项目过需求时，各端的配合都要抠细节来确认，产品经理和研发工程师往往会从进会议室的第一刻起，就在内心有了些抵触情绪。

搞好关系也是对自己的一种能力提升，不是说一起团建吃顿饭那么简单。

首先，产品经理需要更多的了解技术层面的知识，自己提的需求实现难度有个大致的评估。

当然了，现在去学代码转研发，一是要本人有勇气吃得了苦，二是要家里有矿捱得过积累经验的初级阶段。我都不符合，所以这里说的是了解自己的研发兄弟们的一些工作习惯。

比如用的什么软件，接的什么sdk，有什么好的数据分析产品等等，我们确实需要把控甚至“压迫”一下进度，但要有理有据，被回怼时也有底气，从容的继续“压迫”。

其次，研发小哥的思维逻辑和产品运营的思维逻辑是有差异的，但是本质上又有着相通的部分。

用这一部分作为切入点协调，这块主要是在需求文档里体现。

网上有很多调侃研发的段子，说做研发的小哥哥们都有比较木讷，没啥人情味，沟通起来比较难。对此我不敢苟同，研发都有了一定的经验，也多少了解些每个产品经理的工作逻辑，每天都是那些代码确实索然无味。

尤其有的时候他们辛苦做出来的东西，没过多久就不去使用或者运营了，谁都喜欢自己做的东西被认可，但他们被认可的点可能由我们来决定。

再次，说研发听得懂、愿意听的话。

想节省沟通成本，往往不能做到两者都同时各自退让，从我做起还是可以实现的，根据之前的一些交流熟悉每个研发小哥的调调，其实产品经理也算半个心理学家了。

经常挂在嘴边的用户体验，可以把研发也当作用户，出个用户画像，弄个A/B测试，做个版本迭代，如果这样跟研发还有矛盾，那产品经理要好好反思了。

最后，如果产品本身设计的确实槽点一堆，那么衷心的建议不要去麻烦研发。

不是说皮厚没关系，你浪费了大家的时间。我也要面子的啊，不希望自己的产品被各种删改需求，就是确定要这么做，为了达到目的，我可以一直对你笑。（last but not least）

写在结尾：关系最好的研发小哥离职，对产品经理的影响……没有影响！换一个人换一种沟通方式，作为“没有什么技术含量，人人都可以做的”产品经理来说，沟通能力才是最核心的价值，祝大家工作顺利，祝创业去的研发小哥商祺。

本文由 @RookieChan 原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自 Unsplash，基于CC0协议。