本文作者就该问题做了解答，一起来看一下。
在很多互联网公司，研发团队作为一个支持部门而存在，同时支援着产品、运营、市场等部门，产品经理要经常跨部门沟通提需求，面对如狼似虎的开发和严肃认真面带凶相的开发主管，产品小白往往不知所措，需求评审被批的体无完肤不说，还严重地打击了自信心，在各种论坛上，到处留下了对开发的控诉，觉得开发们真的太难相处了。
刚看到有个产品小姑娘，就被一个资深的开发主管打击得失去了信心，觉得他很凶、很不讲理、被刁难，推进需求好难，整个人很难受，估计一去提需求就心里发憷；很多人给她出谋划策，但都过于理论，操作性不强，要不就是让小姑娘提升自己的产品和逻辑能力，不能说错，只能说无法救急。
作为一个开发出身的产品，带过类似的研发支持部门，也曾经作为业务方给支持部门提过需求，从公司角度来说，这个开发主管的做法并没有问题，只是作为当事人突然遇到这样的人，不知道如何处理，导致自己压力很大。
所以，如何和开发相处就是产品新人的一门必修课，但要成长为一名经验老到，对自己的需求有强大的逻辑支撑，且能够拿捏好开发们的心态，把事情做成的产品经理还是需要时间的，少说2~3年，多则5年起步。
那有没有那种短期内可以见效的方法呢？
在下不才，说一说自己的看法，各位灵活使用。
一、认识开发
开发团队在公司的定位是公共支持部门，为业务团队提供弹药的，基本上不冲在第一线。所以业务部门大多数都认为你要听我的，谁让我背着KPI呢，你都没听过炮火声；今天说要做这个，明天插个需求，不能有意见，公共资源嘛不用白不用，个个还都急哄哄的，稍微问下为什么要做这个，还给脸色看。
久而久之开发团队发现了一个问题，上线的功能没人用，到年底一总结，我擦，70%的功能白做了。
年底给老板汇报的时候
战战兢兢地说：今年做了很多需求，小伙伴们加了多少班。
老板问：做了这么多开发给业务带来哪些提升了吗？
开发：额……
老板：不要给我讲你们有多少苦劳，要讲你们给公司创造了多少功劳，不然养你们这么多人干嘛。
开发：额….老板，我们做了一个XX功能带来了很多用户。
老板：哦，你说的那个我知道，XX部门的想法嘛，创意确实不错。
开发：额……
从领导办公室出来，开发对着远方一片雨云唉声叹气：MD，和人打交道真不是个事，还不如敲代码来得纯粹，明年我一定要认真评审需求，让团队做更有价值的事，唉，我的青春啊，我的头发啊……
经过几年的积累，这种对外情绪就被一代一代传承下来，直到有一个在公司呆了很久的开发成为了这个部门的主管，他经历过很多大风大浪，自己也沉淀了一套对付不合理需求的方法，他的头发可能很少，但对付需求方的方法一定不少。
所以开发们经常会说两句话：
- 这个需求能带来什么价值？
- 我们的计划已经排到月底了，你这个需求我会排到下个月去。
询问价值并不一定是对你的需求不信任，其实是有三层含义：
- 是判断下这个需求目前的紧急程度，是否和公司近期的重点相关；
- 知道价值点之后，看是否有其他的解决方案可以满足需求；
- 就是真的想看需求方是否想清楚，而不是头脑一热提的需求。
我相信你也看出来了，这句话的主要目的是进行筛选，然后再判断需求的优先级，方便开发主管进行资源调配。
当然，很多人对需求排期深恶痛绝，觉得永远都在排期，等你做完了时间窗口都过了，那能不排期吗？
答案是不能。
一个需求是怎么来的？可能是来自用户的反馈、老板的想法、或者数据分析，所以需求天生具有不确定性，开发团队不能说什么都不做，就等着你的需求开工，那做需求的时候又来新的需求怎么办？直接开做吗，不现实，那得招多少人，而且需求方又不是一个，所以势必会出现开发资源争夺的情况。
所以一个有责任感的开发主管，一定会进行需求的筛选，在有限的资源下做最有价值的事情，给团队带来产出，避免出现忙忙碌碌一年，年底一算和我毫无关联的情况。
那怎么判断需求的价值呢？
来自于主管的经验、信息的交换、需求的逻辑，和老板的命令。
因此，我们看到一个在需求江湖上闯荡多年的开发大叔，和了几个刚入门产品小白的交锋，双方完全不在一个等级上，你一上来就用一些经典套路，就想对付已经修炼到九层的大力精钢掌和狮吼功，肯定会被砍瓜切菜般怼回来。
所以，想要取胜就不能使用常规招数，需要用一些巧劲。
二、人物画像
先纠正一下观念，产品们千万不要把开发团队只当成一个执行角色，只要听话接活就好，要什么自行车？一个搞开发的对我的方案总是指手画脚，也太难搞了吧，甚至可能还搬出老板来施压，你会发现对方的脸更黑了；我TM平时受领导和其他负责人的气也就算了，你一个刚毕业的小屁孩，自己业务水平不行，还拿着鸡毛当令箭，吓唬谁呢，凭什么都听你的？我不敢反驳老板，难道还不敢反驳你吗？
这叫什么？这叫人性。
这是一种双方角色错位带来的本能反应。
你认为开发就应该那样听话的，老老实实讨论技术实现就好。
而他认为产品经理要了解清楚用户目的，逻辑思维严谨缜密，连我都觉得没什么价值，开发出来有人用吗？不要浪费我的精力。
这就带来了落差，矛盾就产生了，紧接着就陷入了“开发要不要听话”和“产品经理是不是想清楚了”这两个观点的争论，观点的争论从来都没有对与错，只有站的角度不同。
所以我们要解决解决问题第一步，先把自己和开发团队拉到同一阵营，告诉他，我们是一伙的，这样统一双方的目标，才能实现平等对话。
然后，我们来看看开发的人物特点。
说实话，我带过多种类型的团队，纯开发的团队是我认为最好带的，他们简单直接，心思单纯，没什么心机，所追求的也比较纯粹，做的事有意义有价值，能提升自己开发能力。
一个典型的开发主管，都不太怎么会说话，或者说不太会沟通，也不会怎么考虑他人的感受，说话很直接，多年需求争吵导致嗓门也比较大，说话比较冲，再加上不苟言笑的表情，正面看就是一张扑克脸，给人一种好凶好凶的感觉，让人敬而远之；但他是一个有原则的人，认可的事情还是会去做，有可能做的比你想象的还要好，他所在乎的理不是我要不要给你面子，而是这个事情该不该做，有没有价值。
这种人的特点就是外表凶悍，内心柔软的直男，好面子，经不住夸，夸奖他的时候，别看表面上波澜不惊，其实内心早已汹涌澎湃了。
三、解决方案
我们现在清楚了开发的心态，以及他们的性格特征，接下来就是有针对性的进行解决，用一句话概括就是：让开发们爱上你~
1. 战略同盟
不要把你们双方放在对立面，把矛盾从内部矛盾转换成外部矛盾。
参加一些大的需求调研会上，邀请开发主管一起（可以让你的领导邀请），一起沟通需求时，可以让他提出解决方案，或者你提出解决方案之后，询问他的意见，在会议上达成共识，把方案变成了他自己认可的方案。
如果他没空参加，你可以先出方案，过需求之前，先抛出用户需求目的（不管提什么需求，先抛出用户的目的），采用“用户故事”的形式来表达，格式如下：
作为一个<用户角色>，我想要<完成活动>，以便于<实现价值>
然后你说，“哥几个，我们的用户遇到了这样一个问题，需要我们一起想办法解决它，这是我的初步方案，大家看看有没有问题？”，目的是一起解决用户的问题，而不是让你接受我的方案，这样就是告诉开发，我们是一伙的，不要误伤友军。
不认可我的方案，没问题，大家商讨出一个合理的方案，我改，犯了错我认，最终能解决用户的需求才是你想要的。
有的时候让开发们知道需求意义会收获一些意外的效果，他们会变得积极主动，而且提出多种解决方案（有的时候也是想偷懒），有的方案真的只有开发能提出来，高效快捷还不掉头发，既快速解决了你的问题，开发还觉得自己的获得了认同，工作上更有劲了。
2. 价值传递
关心他们所关心的，认同他们的付出，经常同步他们产品上线后的结果，包括数据结果、用户反馈、使用感受等等都可以，让他们觉得在做有意义的事情，不要把他们当作工具人。
具体方法有很多种，在群里说、当面说、公司邮件说、领导汇报说等等，就是让开发知道，你们做的东西出结果了，这个功劳，有你们的一半，下次他们做事更有劲了。
3. 花式夸奖
前面两个还是正常的武功，这招就厉害了，用的好真的可以实现四两拨千斤，如果是女孩子更适合。
当对方不情愿的时候，撒撒娇，嘴巴甜一点，直男的心真的很柔软，不会撒娇？没关系。
那在他们答应做你的需求，比个心，会吗？就像这样。
他们在加班的时候，过去临时充当下鼓励师，说几句辛苦了，会吗？
他们加班加点完成了你的需求，买点奶茶小点心啥的，带去感谢下，会吗？
奶茶太贵了，好，那下次家里带的一些土特产，记得给他们那边捎上一些，既有心又便宜。
当他们快速解决你的一个需求，动作夸张点对他们喊，你们太棒了，你们是最牛的，就费几口唾沫，换来的可能是他们开心爽朗的笑声。
曾经在创业时，我们的销售小伙伴这招就用的特别好，逢人就夸，作为研发方的我很是受用，我也能感受到他们对研发团队深深的爱。
开发可能是最经不住夸的群体了，又容易害羞，你要是认可了他们，他们真的会把心都掏给你，最起码要有1~2个和你关系很好的（最好是能力强的那个，或者就把开发主管搞定），关键时刻能救你。
最终的目的，是让他们认可你，接受你，这样在后期的沟通上在原则问题上，你们还是会争论，但基本上不会对立了，而他们也会来帮你思考。
你可能会说，大家都是打工的，凭什么我要对他们低声下气，这样讨好他们？因为开发团队天生就是弱势群体，一直被需求方压着，没有话语权，做得好可能没他们什么事，做的不好可能还会被甩锅，你所做的只是平等地对待他们，对他们好，他们也会双倍奉还。
4. 排期沟通
每个人都希望自己的需求能够尽快开发，但现实往往不允许，除非你的产品结果很优秀，让开发和其他需求方服气，老板支持，大概率上是可以实现即提即开的，这对新人来说，还有很长的路要走。
要让需求的排期符合你的心理预期，一是要学会关注开发团队的进度，做到心理有数，然后尽早提需求；二是如果恰好真的一个需求很急，开发安排不上，那你在之前和其中一个搞好关系就派上用场了，充分表达你的诉求之后，让他们提供一个临时方案，这个方案他们能顺手就做掉，不占开发时间，你先用着，然后耐心等待正常的功能上线。
顺手做掉的需求，其实是一个很有意思的事情，有的时候需求能不能立马安排上，就在一念之间。
但有一点要注意，不要说“这个需求很容易，需要这么久吗？”，可以改口说“我觉得这个时间有点长，能不能加快点呢？”，需求的难易程度不是你来判断的，这句话开发主管可以说，或者和你关系好的那个开发可以帮你说，需求方说就是拿自己的业余爱好去挑战别人的饭碗，他们一句话“那你来”，你就接！不！住！
5. 虚心请教
每个公司总有几个人能和开发主管这样的人打交道，顺利的推进事情，向他请教学习，可以很好的发现问题的所在，让他指点你一下，说不定就能找到突破点。
最后，我想说的是，遇到这样的开发主管或团队并不是坏事，最起码他的行为能让你认认真真思考需求的可行性，力争每次的需求都无懈可击，去深挖用户的真正需求是什么，你的产品能力会直线上升，失败了就接受，回来再改。
有的时候产品们也不要太把自己当回事，不接受你的方案不是问题，推进不了需求才是问题，没有人天生就喜欢和人对着干，认真思考他的意见建议，理解他是怎么思考的，回来和领导商量下怎么再去沟通（商量的就是信息交换，也不要指望领导能帮你解决，凡是靠自己）。搞定了这种人，其实也没那么难，因为不是玩心机，而是摆事实讲道理，可能累点，但这对你后期更难的跨多部门合作非常有帮助。
当然了，你要是把第3条运用得好，和开发们相处也不是什么难事了。
