产品经理怎样和开发搞好建设？
产品经理跟开发人员在日常工作中有著非常频繁的沟通与协作需求，可以说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）、写死，了解相关技术术语，相当于掌握了与开发沟通的语言，是自己专业素质的体现。
五、维护基本的人际关系
虽然这个是一个人尽皆知的大道理，但还是在这里提出来。如果你的人际交往能力不错，那么跟开发维持友好的人际关系将能使自己的产品工作事半功倍。
你跟开发关系不错，他可能会帮你提出产品的某些问题，你的需求他也愿意帮你完成。
有些时候，产品经理跟开发人员可能到了水火不容的地步了，这个其实不太利于工作的开展。
当然了，不是谁都有能力可以把周边的人际关系处理得很好，但是互相尊重，互相理解，减少不理性的冲突与矛盾，这是我们的一个理想的目标。人际沟通与交往是一门艺术，值得我们好好琢磨。
六、写在最后
一个好的产品，背后往往有优秀的产品经理与优秀的研发人员，外界喜欢把产品经理跟研发人员的关系调侃成互相对立的局面。
我相信大部分的研发人员不会因为产品经理不是技术领域的专家就产生排斥，但是产品经理需要不断提升自己的专业能力与沟通协作能力，争取得到开发人员足够的信任，这是一个需要长期努力的过程。
- 专业性是基础。对于业务不专业的产品经理，对于开发的伤害是最大的。菜就是原罪，专业性是一切关系的基础。人脉不是混出来的，你的能力在哪个阶层，就只能在哪个阶层混。尊重强者是大自然的普遍法则。所以，要想和程序猿搞好关系，首先要提高自己的专业性，一味的跪舔只能成为舔狗
- 真诚，和其他人搞好关系（不仅是程序猿），我觉得最重要的一点是：真诚。永远打明牌，做人要敞亮，是自己的锅不推脱及时认错，不是自己的锅也不要穷追猛打。以前带我的饭大说过一句话：以单纯应对复杂，以复杂保护单纯。
- 摆正心态，还有一点也很重要，要在心态上先把对方当成合作伙伴来看待，不要割裂双方的关系，你是怎么对别人的，别人也只会怎么对你。
- 具体实操就很多了，完成大版本，请大家喝杯奶茶；关注下朋友圈，点赞评论啥的不能少；平时主动找他们聊天，可以是请教问题，可以是找他们帮忙，可以聊人生，聊职业。如果你们能一起吐槽，那说明他们把你当自己人了，关系到位了。
请开发吃饭，进行表面意义上的拉关系、social都是治标不治本的行为。LZ作为一名略微社恐的产品经理，在工作中不仅与开发保持著非常良好且密切的合作关系，而且也很少出现开发不配合、不理解的情况，相反，双方之间的信任关系随著多个项目变得越来越坚固。
核心关键在于：要知道如何和开发和谐相处，首先要明白产品经理与开发恩怨的根源在哪。
Q：Why开发经常怼产品经理？
如果进行一下换位思考，就能很清晰的理解开发的诉求。每个人都希望自己的无效工作量能最小，而产出最大化。从这个视角来看，开发日常对产品经理的怒点无非可以归结为以下几点：
【1】需求不明确，产品经理自己都没想清楚要什么，开发无法执行（例如关键逻辑没理清就push开发开工）。
【2】需求不稳定，频繁向开发改需求，开发做的无用功多。
【3】需求不现实，对技术缺乏基础理解，需求所隐含的实现成本过大，而产品经理并没有意识到这一点。
【4】需求没结果，面对技术吭哧吭哧做出来的功能，要不是没能像预期那样用起来，要不是具体达成了什么效果没有进行评估和反馈。
那么，要和开发搞好关系，就要避免踩上述「雷区」，具体可以：
【1】避免需求不明确，意味著产品经理在提出方案前要最大程度夯实自己的方案。包括方案能够实现的价值是什么，如何推导出这个价值，论证过程是否严密，具体实现方案的逻辑应当是什么。
总而言之，就是要讲清楚：为什么要干这件事情（开发如果做了这件事情不是无用功），应该如何干这件事情（明确清晰的prd，流程图）。
【2】避免需求不稳定，如果能按照第一步去做，很大程度就能避免频繁改动prd的情况。
但是如果遇到不可避免改prd的情况，应当采取「商量」的方式沟通，而非直接「通知」程序员。
首先，应当说明为何出现改prd的原因；其次，一起讨论改动所带来的排期、实现方式等变动影响。虽然从职责上来说，产品经理掌握著产品迭代方向的决策权，但要时刻保持倾听，才能换来团队合作中他人的尊重的配合。
【3】避免需求不现实，很大程度上意味著需要一些技术功能的积累。
如果作为一枚没有技术经验的小白，不能从客观上判断工作量时，一方面可以阅读部分入门书籍进行学习；另一方面，可以」谦虚、深入「地向开发讨教，即当开发说做不了的事情，进一步询问技术原理具体是什么，为什么难以实现。
只要谦虚、诚恳、礼貌，开发很多时候是愿意解答的。交流多了，小白产品经理也能积累一些技术素养。同时也能防止被一些不想干活的产品经理忽悠。
【4】避免需求没有后续，意味著很多时候可以主动向开发聊一聊需求上线后的效果。
如果需求没能像之前一样得到运用，或者数据效果不好，可以告知开发原因，同时在之后的工作中规避这类问题。如果需求上线后的用户效果突出，也可以向开发反馈反馈，一起分享成功的喜悦。
基于「好结果有成就感，差结果能找原因」的反馈体验，在下次寻找开发和你一起做项目时，他的配合程度和信任感就会有非常大的提升。
总而言之，任何人都喜欢在工作中有一个靠谱的合作伙伴。如果产品经理能够从根本上构建这种信赖关系，那么就能与开发搞好关系建设。
1.产品团队架构，例如很多不小的厂都会设置项目经理来帮产品建设开发；
2.善于沟通，有时候说女孩子适合做产品经理一般还真是对的，因为女性一般沟通时比较温柔；
3.技术上，产品经理懂数据流程，懂演算法是可以与开发有更多的共同语言；
4.需求环节 前置与开发的沟通时间点 帮助开发可以预选做好准备；
5.整个过程对事对需求，对目标，不对人。
6.练习辩证思维和战略格局观
产品经理与开发的梗大部分都是互斗、互怼。仿佛这两个职业是有你没我，有我没你，是天生的对头。但根据自己从业多年的经验，既做过开发又做了产品经理，对这两个职业都有亲身经历，加上自己和开发关系都还比较融洽，其实双方的关系是可以改善。
当然，一方面如果是一个新成立的团队，那么双方需要一些时间磨合，另一方面双方关系的好坏是需要两者共同努力。但作为产品经理有责任和义务维护团队的关系，我会更多的是站在产品经理的角度来阐述需要产品经理改进的，毕竟我们能改变的只有自己，让别人和我们相处更愉快，也是一种能力。在日常工作观察中，如果产品经理可以在下面两个方面得到提升，那么开发往往和你的关系会比较融洽。
专业
作为产品经理，首先，你自己的本职工作要做好，让别人觉得你是专业人士。在和研发人员做沟通交流时，要能顺畅的表达你所想要的，让研发人员听得懂。在提交PRD等文档给研发时，要确保文档前后逻辑一致，文档框架清晰，内容完整，最重要的是确保能实现商业目标。
获得认可
让研发人员认可你，这点在我看来很重要。我本人是研发出生，做了三年开发工作。在技术方面有一定了解，因此在和研发沟通时，可以直接用技术对话，双方沟通效率和效果就很高，也避免了很多歧义。
产品经理具备技术能力，有一定的技术工作经验，它所能带来的好处，远超乎你的想像。当然，这并不是因为需要产品经理自己做研发，而是需要产品经理有技术的思维，能评估技术可行性、能和研发高效率的沟通。我们希望产品经理是一个独立的个体，不需要依附于其他人才能做出必要的决断。
它会从根本上拓宽你的技术视野，并能够让你与技术人员和设计师进行更广泛而深入的讨论。它还会让你更好地理解技术实现的力量。
如果觉得对你有帮助，就点个赞呗，十分感谢！
推荐阅读：
