作为产品经理，如果得不到程序员的协作配合，工作将难以顺利进行。想要处好这个关系，必选先弄清为什么程序员讨厌产品经理。不管是产品经理，还是程序员，在一开始做的时候，或因为专业技术不过关，或因为工作不得法，也或许是因为自己本身就很笨。
自产品经理逐渐成为互联网企业标配以来，网上也开始流传着各种产品与开发之间巅峰对决的图片，贴切又形象，这些个梗可以笑个几天几夜了。
但是我相信作为一个有人格魅力的产品经理，一定有方法能轻松化解这些问题，而且会逐渐发现他们的可爱之处并建立天长地久的友谊。
接下来给大家分享一下个人“心机”，下面这些问题是经常发生在我们的工作当中的，只需要掌握这五个点：“看听说写问”就可以解决问题。
看：即察言观色
听：倾听他们的想法
说：表达自己的看法
写：尊重他人的说法，认真记录笔记
问：询问他们的建议或意见
情景一：临时新增紧急需求
故事背景
当用户提出某个需求，业务要求尽快优先完成，经过你的思考，觉得需求合理并可行，可和开发说临时增加这个需求的时候
开发：这个需求做不了
产品：加一下吧，用户要求的
开发：不行
产品：不是改下XXX就可以了吗？
开发：这样会影响了整个产品现有逻辑，改动太大了，你不懂技术，和你说了，你也不明白
产品：。。。。。。
准备工作
1）提前准备好实现需求的一种或多种方案，无论是否可行
2）纸笔或白板，讨论需求方案过程当中可能随时会用到
接下来
一看：
观察开发人员当前的面部表情，是皱着眉头正一本正经地在撸码，还是面带微笑和周边的人正在聊天，总之，发现他明显处理放松状态的空隙，再去找他
二说：
1）说明这个需求的来源是用户遇到了什么问题提出的。目的让他也能深入用户的使用场景，在心中模拟使用过程，产生同理心。
2）说明这个需求的紧急性。千万不要以“客户很着急，不做这功能这笔订单就黄了”的负面方式来“威胁”他，而要以正面的方式来鼓励他，比如“这个需求很重要，搞定这个用户你就是大功臣”的方式来鼓励他
三问：
将提前准备好的方案和他讨论（期间可能会用到纸和笔，或者白板），不用理会这个实现方案是否可行，重点是你要有，代表你仔细思考了这个问题，若是明知不可行可能效果更好。
产品：“我想了个方法，你看这样行不行？（描述你的方法）”
开发：“这样肯定不行的，这个可能会对系统造成不可磨灭的灾难XXXXXX”
产品：“啊?这么严重，幸好你提醒了，还是你厉害，你有其它的办法没”
开发：“有一个办法：（开始描述他的想法）”
产品：”嗯嗯，这个好，这样就不会产生这些问题了，那就按你的想法来弄“
开发：”好“（这时候再问开发需要的时间）
产品：”那你预计弄这个功能，需要多久时间？“
开发：”两天“
产品：”会影响你当前现在的工作进度吗？“
开发：“会”
产品：”那我把这次你的需求提测时间往后延一下，先完成这个吧”
开发：“好”
要点
引导他去思考，由他来实现他提出的方法，一切顺理成章、心甘情愿。。。
情景二：需求变更
故事背景
已经和开发说完了本期需求，开发过程中，你由于外部因素或内部因素等原因变更了需求，和负责开发这个功能的同事说的时候
产品：这个需求我改了一下，你按新的来做哈
开发：这个改动很大，我都做了一半了，又得重新来
产品：没办法，改吧
开发：。。。。
准备工作
1、对比新需求，找出需要推翻老需求的合理的“借口”，用来说服开发
2、若改动较大，则需要提前准备好纸和笔，或白板，则改动小，则不用
接下来
一看：
和情景一一样，尽量观察开发人员当前的面部表情，发现他明显处理放松状态的空隙，再去找他
二说与问：
说明原因并询问他的看法
产品：“关于XXXX的需求，我这边做了些调整”
开发：“又改动？”
产品：“是这样的，我发现现在的这种方式可能会存在几个问题：1……2……3……，你说是不？”
开发：“好像是的”
产品：“那我如果改成这样：XXXXXX，，这样这几个问题就不存在了，你看呢？”
开发：“这样也可能会有问题”
产品：“啊？是吗？我就感觉我考虑得可能不够全面，你说说看”
开发：“这个可能会影响到之前的XXX功能”
（这时候他说什么你都要点头）
产品：“你说得很对，要不这样，等功能出来之后，提给测试那边验证一下？”
开发：“嗯”
产品：“那好，那我就按这样更新下需求文档”
要点
引导他的“共情”，让他和你的看法一致，自然就达到目的
情景三：矛盾协调
故事背景
测试组提个bug给某个开发A，开发认为这个问题是当时另一位开发同事B让他这样改导致的，不愿意修改这个bug。
开发A：这个不是我的问题，是XXX当时让我改成这样的
产品：可现在这个改法现在出了问题，这块是你做的，你再改一下吧，不然影响上线进度
开发A：我为什么要改产品：。。。。
准备工作
1、找间会议室
2、准备你自己的“主动认错”陈词
接下来
1、听：
1）倾听开发A描述事情经过。
2）并开发B说明当前情况，倾听开发B描述事情经过，确认开发A是否属实。
2、说与问：
1）组织事件相关人员，测试，开发人员A，开发人员B等相关人员到会议室。。
2）开头陈述事情，并请开发同事B说明情况：“把大家叫到这里来，相信大家应该知道是什么事情了，开发同事B，麻烦你先说一下情况吧”，这里主要目的是为了让A同事的说法得到我们的尊重与认可。
3）陈述自己提前准备好的陈词：“这事情也赖我，没有进一步和你们确认这个，现在由于我们的失误导致这种问题的发生，实在很抱歉，那接下来麻烦开发同事A修改一下这个，可以吗？”
基本这个时候，开发同事A已经没什么抱怨了，心甘情愿去改了。
要点
主动承认错误，双方互相尊重，矛盾自然迎刃而解。尤其当内部矛盾产生的时候，一定要尽快解决并处理，否则越积越深，最终可能就会发生“手机壳变色”事件。
