产品经理是一个协作型职业，所以经常会在工作中遇到来自于各方各面的沟通问题。有的时候问题多起来真的让人很头疼。
比如，你的工作中一定会遇到过下面这些问题。
开发哥哥A会跑过来告诉你，这个需求实现不了，你想办法吧。
开发哥哥B会跑过来告诉你，你这个逻辑有问题，走不通，想出来再提需求好嘛？
你们这是在搞事情啊！说好的大家和乐融融的好好工作呢！为啥要为难我这个可怜的小土狗！
既然你们要搞我，那我就要有相应的对策才行，怎么能天天让你们虐。
针对于不同的部门，应该采取不同的处理方式，将他们当成你的用户，满足他们的痛点和需求。
下面来解锁姿势！
对付开发哥哥的正确体位解锁方式
大家都是一起搞事情的，开发哥哥们也不会一直针对你。他来跟你说不行的时候，你以为他真的不行了吗。
要知道他们都是傲娇的单身汉，怎么能轻易说自己不行。
那就要从以下几个方面来把把脉了。
-
用户需求与场景是否明确
现在大多数团队在与开发团队做需求评审时，就略过了用户需求的说明阶段，而直接去讲功能。这样对于开发来说就很难去理解场景，只能片面的去做功能，脑海中无法形成完整的场景认知，写的代码就会只针对于他所理解的业务逻辑来做处理。
等做出来以后经常会发现与你所说的有很大的出入。
这里我们就要求跟开发哥哥们讲清楚，用户是谁？什么时候会用？怎么用？以及为什么要用这个功能？
把用户需求与场景pia一下呼上去，开发哥哥门恍然大悟，oho~是这样蛤？
-
功能业务逻辑是否考虑完善
讲完需求，这时候开发哥哥一定会说：需求算是明确了。诺~来，给我们看下完整的业务流程吧，别挖坑了，讲明白点。
这时候你战战兢兢的打开你的visio，亮出了你画了很久的业务流程图。
开发哥哥看了你的业务流程图，啪一声打你脸上！
“这个输入框输入什么内容？能输入多少字符？特殊符号能输入吗？是必填项吗？
这个模块数据哪里来的？我靠，这个字段改不了，影响之前的逻辑了，我们来不及改！”
你一脸蒙蔽黑人脸，蛤？我没考虑啊？！
我们不是老板，做一个功能只考虑用户需求。
最终还是需要落地的，需要所做的功能具备可执行性。
功能必须描述清楚开始与结束。
数据需要知道来源，如何存储。
字段需要定义好异常情况，为空情况，以及字段类型和长度。
-
对产品是否有改进作用，数据上是否有所提升
终于说清楚了需求和流程。就可以拿出最后一招了。毕竟开发哥哥也是有追求的。希望自己辛辛苦苦写的代码会有人用啊！不然天天加班挥汗如雨桥下的代码都去吃土了嘛！
这时候应该拿出我们作为产品经理应有的数据敏感力，pia一下呼出你的数据化分析。
嗯。我们今天做的这个功能会对用户有这样那样的影响，我们预估会提升用户X%的注册率or转化率...
怎么样？方法很简单有木有？
3招啊！不用4招、5招，7、8招啊。我们要的就是简单实用。
记住，没有人在工作中来无缘无故的挑你毛病的，拿出你的职业范儿来，我们只做有效的沟通！
