产品经理如何有效跟开发沟通协作？

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

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

于是，矛盾便产生了。

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

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

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

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

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

前期的需求沟通环节：

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

需求开发与测试环节：

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

项目进度把控环节：

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

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

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

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

一、目标驱动

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

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

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

二、利益驱动

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

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

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

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

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

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

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

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

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

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

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

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

三、维护好你的PRD文档

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

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

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

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

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

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

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

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

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

下面举一个文档描述的反面与正面例子：

错误的做法（图来自开课吧）

正确的做法（图来自开课吧）

3. 文档更新要及时

需求方案在落地开发的时候，不可避免的会产生需求的变更，比如因技术问题需要对需求进行调整、产品经理的PRD未考虑到某些异常的场景，需要补充需求说明等。

考虑到这时候需求已经进入开发阶段，产品经理可能会先跟开发人员口头或者线上沟通具体的调整方案，然后开发同事可能就先行调整代码了。

这时候产品经理务必要将调整后的结果及时更新到需求文档，并且知会相关人员，主要是开发与测试同事。

这样子做的目的在于让工作有迹，一般产品验收的标准以PRD为准，如果PRD未更新，那么可能出现开发当时口头承诺可以，但是因为其他事情忘记了，导致需求未实现，但是文档也未更新，很容易导致双方的扯皮。

4. 需求变更得谨慎

产品经理变更需求是正常的，任何方案都没办法做到十全十美。

但是在变更需求之前，产品经理需要仔细分析，不要随意调整，若真的有变更的必要性，需要明确方案，并且跟开发人员沟通需求变更的背景，争取对方的谅解。

没有严谨的分析思路，想到什么就做什么的风格，容易导致方案存在考虑不周全的风险，继而引发下一次的需求变更，开发人员是很抵触产品经理经常性的需求变更的。

首先这个东西，开发已经投入了时间精力去完成了，最终确因为需求不明确而需要多次返工；其次，长期如此，会让开发人员对产品经理越来越不信任，质疑你的能力。

四、掌握一些基本的开发知识

关于产品经理需不需要懂技术，这是一个被大家讨论了很多遍的话题了。我觉得只需要懂一些基本的开发知识就可以了，如果是从事B端设计的产品经理，对开发知识的掌握要求还会稍高些。

掌握适当的开发知识便于我们提需求的时候可以考虑技术的可行性与投入成本，在跟开发沟通、转达需求的时候能够更有效率。

有些产品经理甚至会去学习如何编程，这个我认为投入产出比不是很高，实在不建议。

在这里向没有任何技术背景的初级产品经理推荐这本书《给产品经理讲技术》，在微信读书可以找到。这本书主要讲解一些入门的技术概念，稍作了解即可，不需要太扣里面的技术细节。

下面跟大家分享几个我觉得需要关注的一些技术常识或者与开发人员在技术方面的沟通技巧。

1. 了解最基本的前端、后端分工

简单粗暴的说，前端一般负责用户操作界面的展示、交互处理，后端一般负责底层逻辑的实现。

这样子说可能还是有点抽象，就拿最常见的登录功能来说吧。你打开某个系统进入登录界面，输入账号跟密码，点击登录，最后成功进入APP。

这里登录界面就是前端操作界面，负责把需要填写的字段展示给用户（账号与密码），并且用与用户产生交互(输入/清除账号、密码)。

当账号与密码输入完毕，点击登录按钮后，前端会把登录请求传送给后端服务器，后端会根据数据库表对账号跟密码进行校验，后端会把结果返回给前端。

如果账号跟密码均正确，后端会通知前端登录成功，否则就会通知对应的错误类型（比如账号不存在、密码错误等）。

了解基本的前后端分工的好处在于：

• 在前期的需求沟通环节，可以帮助产品经理了解本次功能模块的责任分工与前后端大致的工作量，有助于产品经理做项目进程的管理；
• 当产品出现问题时，产品经理可以快速判断问题在于前端还是后端，便于快速找到对应的责任人进行沟通，避免出现产品经理无法定义问题的归属，把后端的问题抛给了前端，或者把前端的问题抛给了后端，这会影响我们的工作效率，如果长期如此，也会影响开发同事对我们的耐心。

2. 与开发的沟通重在逻辑

有时候我们跟开发同事沟通的时候，他们很容易就突然冒出很多技术术语，你还没来及反应过来，对方已经表达完了。因为开发人员有自己的思维习惯，他们需要从技术的角度向外界阐述自己的观点，这个是正常的。

遇到这种情况，我一般会谦虚的请求开发同事把我觉得有疑惑的地方重新表述一遍，有些时候我还会让其用纸笔画出对应的逻辑思路，方便我直观的理解。

如果涉及到后端，则会更为复杂些，后端重在逻辑的搭建，所以产品经理一定要明白对应功能点的技术实现逻辑，甚至有时候你可以指出某些逻辑上的漏洞。

多跟开发沟通，久而久之，你会发现，跟他们沟通起来会越来越轻松。

当开发同事说某个功能不好实现或者无法实现时，我习惯通过这种方式去了解背后的原因，有时候你会发现开发的逻辑是存在漏洞的，或者对需求的理解有误，这才导致功能实现的出现了难度。

3. 不懂多查，不懂多问

当我们跟开发沟通时候时，你可能听不懂某个术语，比如开发说这个下载功能我用的是异步处理方式，这个时候如果你不懂这个东西，就得多问了。

平常自己看到某个陌生的技术术语，可以多百度，基本上多看几遍就知道是怎么回事了，技术术语是沟通的关键，我们需要多主动去了解。

比如什么是同步、异步、API、URL、APP技术框架（Native App、Web App、Hybrid App）、写死，了解相关技术术语，相当于掌握了与开发沟通的语言，是自己专业素质的体现。

五、维护基本的人际关系

虽然这个是一个人尽皆知的大道理，但还是在这里提出来。如果你的人际交往能力不错，那么跟开发维持友好的人际关系将能使自己的产品工作事半功倍。

你跟开发关系不错，他可能会帮你提出产品的某些问题，你的需求他也愿意帮你完成。

有些时候，产品经理跟开发人员可能到了水火不容的地步了，这个其实不太利于工作的开展。

当然了，不是谁都有能力可以把周边的人际关系处理得很好，但是互相尊重，互相理解，减少不理性的冲突与矛盾，这是我们的一个理想的目标。人际沟通与交往是一门艺术，值得我们好好琢磨。

六、写在最后

一个好的产品，背后往往有优秀的产品经理与优秀的研发人员，外界喜欢把产品经理跟研发人员的关系调侃成互相对立的局面。

我相信大部分的研发人员不会因为产品经理不是技术领域的专家就产生排斥，但是产品经理需要不断提升自己的专业能力与沟通协作能力，争取得到开发人员足够的信任，这是一个需要长期努力的过程。

作者：小狼人，微信公众号：人称产品汪。不定期更新本人在对接第三方支付平台与银行存管系统中的经验心得、支付知识、产品心得等。

本文作者 @ 小狼人  。

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！