产品经理跟开发人员在日常工作中有着非常频繁的沟通与协作需求

产品经理跟开发人员在日常工作中有着非常频繁的沟通与协作需求，可以说PM跟RD是一对矛盾体，两者之间因为有着共同的项目驱动目标，而需要相互沟通协作。

但同时两者又存在个人利益的对立，比如PM可能会想着RD能够在最短时间内有尽可能多的产出，而RD可能会想着用最小的投入完成自己的工作任务。

于是，矛盾便产生了。

如果产品经理无法处理好与开发人员的沟通协助工作，很可能会使得项目举步维艰。如何高效、和谐的与研发人员打交道，是产品经理需要掌握的一门学问。

我曾经遇过一群关系很好的开发同事，当时大家都是刚步入职场，彼此成为了朋友，在日常的合作中也很愉快。

我也遇到过一群在家文化的企业氛围中成长，情商很高，凡事都耐心沟通，以解决问题为目标导向的开发同事。当然，我也遇到过一些缺乏耐心，但凡线上沟通都习惯带好几个问号，怼得产品经理极为尴尬的开发同事。

很多情况下，我们无法选择共事的同事，但我们可以掌握技巧，把自己的本分做好，追求双赢。在这里，就结合自己的经验跟大家分享关于产品经理如何跟开发同事沟通协调的问题吧。

首先我们先看看产品经理跟开发同事产生冲突场景一般有哪些：

前期的需求沟通环节：

• 开发人员不认同产品经理的解决方案，导致撕逼冲突；
• 开发人员认为产品经理输出的需求文档不够清晰，影响开发工作的展开。

需求开发与测试环节：

• 开发人员对产品经理的需求变更带来的代码返工、任务量加重存在抵触心理；
• 产品经理缺乏技术相关知识的沉淀，与开发人员沟通的效率低下，易引发矛盾；
• 在开发过程中，产品经理与开发人员的口头或者线上沟通调整方案未及时更新到文档，导致后期发生问题双方存在扯皮的现象；
• 测试暴露的问题在需求文档中的描述模棱两可，责任无法划清，导致双方相互发生争执。

项目进度把控环节：

• 在项目推进的过程中，产品经理因不懂需求背后的技术工作量，与开发人员就项目的开发进度安排存在分歧；
• 产品经理迫于项目上线压力，继而转移压力催促开发人员，久而久之引发开发同事的不满。

以上就是产品经理与开发同事产生矛盾的主要场景，有些产品经理可能会遇到一些性格比较独特的开发人员，常见的特点就是不苟言笑，说话容易误伤他人，这属于比较特殊的性格问题，需要特别注意。

下图是我在网上看到的，描述的是开发人员对产品经理的各种吐糟，相信很多产品经理看到会觉得很受伤。

既然双方天生存在矛盾，那么如何去缓解或者避免这种矛盾呢？

一、目标驱动

我们在职场中的大部分事情其实都带有目标性，希望实现预期的效果，如果缺乏目标的驱动性，做什么事情都是茫然的。产品经理在跟开发的过程中，双方可能会因为观点的分歧而争论，有时候争得面红耳赤，半天下来都没有把问题解决。

这时候建议双方都冷静下来，想想我们本次沟通的目的究竟是什么？我们希望为用户解决什么问题?继而及时回到正确的沟通轨道，减免无效的内耗。

之所以提出目标驱动的沟通原则，主要是建议大家沟通之前、沟通过程中需要明确本次沟通的目标，避免为了争论而争论，面红耳赤拍桌板，到最后发现解决不了问题，还影响到双方的关系，不欢而散。

二、利益驱动

最近看了一本书《穷查理芒格》，里面有句话：“如果你想说服别人，要诉诸利益，而非诉诸理性！”

人对自己切身利益的事情显然更为关注，假设一个环保主义者，想说服大家通过少开空调减少氟里昂排放，从而减少臭氧层的破坏，保护环境。

这个诉求很高尚，然而并非所有人都可以理解。但是如果你换个角度说“经常开空调容易导致关节疼痛与呼吸道疾病”，这种说法直接将少开空调与用户的利益相关联，可能说服力还更为强些。

产品经理与开发人员的沟通也是同样的道理，尝试从开发的角度出发，寻找对方的利益点，作为沟通的突破点。

如果你一直跟开发说这个项目很紧急，这个项目对公司来说很重要，希望早点上线，可能他还是依旧根据自己的节奏来走，未能达到你的预期，因为你没有切中他的利益点。

这时候你除了需要按照项目指定的时间节点定期跟进开发的进度外，还可以给予正向激励与反向激励。

所谓的正向激励，指的是你做到了，对自己有什么利益。

比如当遇到某个技术难点时，某些开发人员可能会先觉得很麻烦，产生了抗拒心理，但是换个角度想，如果开发人员如果集中精力攻克后，其实是有利于自身的能力提升与职业成长的，这个可以成为其中一个激励的要素。

所谓的反向激励，就是你做不到，对自己有什么利益损失。

比如你跟开发说，根据公司的要求，新开发的功能本周五必须得上线，否则可能需要辛苦团队人员加班加点，为了不周末加班，一般大家都愿意做一下冲刺。

当然，这个得建立在对开发工作量有合理的评估基础上。

职场上的正向激励一般包括物质的（薪酬福利等）与精神的（职业晋升与成才、团队认可等），适当利用某些激励要素，会有意向不到的效果。

三、维护好你的PRD文档

PRD是产品经理需求方案的表达形式，是产品经理与开发同事精准的沟通工具。如果PRD本身的质量不高，将会影响开发效率与质量。

关于PRD的规范与标准，各个公司的要求可能还不一样，但是核心目标都是一致的，就是要清楚的向开发、测试同事转达你的需求，说明白你想干什么。关于PRD，有以下几点建议：

1. 产品解决方案的核心环节必须保证逻辑的严谨性，避免低级错误

如果一个解决方案的核心环节都出现了原则性的错误或者出现了某些非常低级的错误，那么在需求评审环节，就已经让开发同事对产品经理的能力产生了质疑。

心理学有种效应叫“刻板印象”，就是一旦某个不好的印象在心理已经产生了，那么就会长期形成一种固定而笼统的看法，当他人对我们失去了信任，那么后面干什么事情都不会太顺利。

2. PRD文档要注重逻辑，而不止描述

什么是逻辑描述呢？传统的软件需求分析领域，在对一个use case（用例）进行需求的细化时，往往会包括以下几点：前置条件（即用例出现的前提条件）、主干流程（即正常流程）、后置条件（即流程结束后本体的状态）、分支流程（即异常流程)。

在这里并不是要求大家严格按照这种格式去写需求，只是建议大家在描述一个需求时，要从开发同事的角度出发，想想如何表达，才能让开发清楚的知道产品需求是什么，而不是模棱两可，一头雾水。

但是如果这名开发同事比较尽责，他会追着你问细节，但这也造成了效率低下的问题。如果这名开发同事稍微缺乏点耐心或者责任心，他可能直接就开怼了或者按照自己的想法去实现，反正需求文档没有写清楚。