两个常见的沟通场景问题
场景一：在产品设计的过程中，有的地方对于可实现性或难度拿不准需要向研发请教
在此种场景下，有没有遇到研发答非所问，甚至在你描述多遍的时候对方依然不能理解你在问什么，或者在双方讨论问题的过程中，发现双方讨论的问题根本不是一个点。
此时你可能开始怀疑对方的能力了“这么简单的问题你怎么理解不了呢？”，而对方呢可能想的是“卧槽，你到底想说啥呢？”
场景二：研发在开发的过程中对需求产生疑问或者质疑向你请教
工作中我经常见到的情况是，产品/交互同事正在忙着手头工作，研发忽然过来：
研发：你这里逻辑怎么能这样出呢/你这里交互做的不好
产品/交互：（看了一下）哪里有问题啦？是你自己没理解吧
研发：你自己没想清楚吧~balabala
……
研发：好！就按照你这个做，后续遇到问题不要找我改！
产品/交互：那就按照这个做
最后就是争吵一番，浪费了时间、增加了矛盾、问题没有解决。
以上的问题个人曾经也遇到过，但是在长期的工作与反省中，自己总结了一套我自己使用起来比较行之有效的方法——控制情绪，三步聚焦问题，分享出来，希望对经常遇到此问题的新人产品经理有所帮助。
控制情绪
绝大多数情况下，产品经理面对的研发都是比较耿直型的，说话不太会顾及别人感受，但是其实人都是比较好的，如果不是因为工作，你会发现和研发处朋友特容易。
但是在日常的工作中身边遇到这样的场面，多数会变为情绪上的对抗，竭力证明自己是对的，从而争吵、矛盾上升，此时控制好情绪是第一步要做的。
好了，不逼逼了，咱也不摆道理，如果你被研发怼过，或者研发说了你觉得过分的话让你感觉感情受到了伤害想要直接怼回去时候，跟我默念控制情绪口诀（可视个人情况修改）。
- 比较正经的：掌控情绪，才能掌控局面
- 比较不正经的：身为一名产品爸爸，我要以包容天下人为己任
三步聚焦问题
三步即交代清楚（问清）背景、共享知识、聚焦（解决）问题。
场景一：向研发请教问题（以输出优惠券需求为例）
第一步：交代清楚背景
探讨问题前，一定要尽量同步问题背景，让双方的话题都有一个边界框架，如果遇到场景二情况其实比较方便，因为需求是自己出的，直接问一下是哪个项目、哪个需求、什么功能出了问题等。
如果是场景一的情况，因为研发事先不知道需求背景，需要尽量说清背景：
XX大大，我现在在做一个优惠券需求，这个优惠券呢是提供给运营使用的，主要目的是用来做一些活动，其中用户领取途径有以下几种：
1.在活动页面，用户点击按钮领取
2.运营直接向指定用户发放
3.运营给一个领取码，用户通过我们提供的页面输入兑换码兑换
4.其他balabala
而且领取的限制规则有所不同，比如在活动页，可能只能抢到某一种优惠券、也可能抢到n种优惠券里的一种。
第二步：共享知识
共享知识其实就是在提问之前将自己已经有的思考说出来，或者说是将对方之前的思考问出来。
如遇到场景一情况可以大致这样说：
我现在比较纠结是该将优惠券的领取方式放在优惠券属性里还是将领取方式放在调用规则引擎里，我直观的感觉吧应该是放在调用规则引擎里，因为这样配置就会更灵活一些。
比如遇到活动场景会在N个券模板中随机给用户发一张，老户激活需要一次给多张，这样可以通过调用规则引擎层引入多个优惠券模板。
但是如果中间加入调用引擎层，就会涉及一个问题，引擎定制规则，如果有的活动有特殊的规则，那也比较麻烦。但是如果每个活动都去单独写使用规则又会造成重复开发，我在网上也看了相关资料balabala（就不阐述了，总之是将自己已有的知识尽量共享出来）
当背景与知识已经说清楚，总体上对方已经和你同步在一个频道上了，当然在与对方对话的过程中可以通过观察对方的表情、动作等来判断对方是否已经听明白，可以通过问答形式问一点细节几乎不太会有多少问题。
第三步：聚焦问题
当背景与知识已经说清楚后，聚焦问题已经是一件很容易的事情。
基于以上，我想和你讨论一下，我简单列一些常见的运营场景，我们看看能不能将领取规则抽取出来，做成动态配置，以方便后续高效使用。
场景二：研发向你询问产品相关问题（以优惠券方案输出后研发提问为例）
例子还是举上面那个例子，假设当时和你讨论的研发与实现的研发不是同一个人，当前实现的研发对你做的中间调用规则引擎层提出质疑，觉得这样太麻烦。
第一步：问清背景
在这种情况下相对来说简单，因为需求或者交互是自己出的，只需要询问是哪个项目下、哪个需求、哪个功能点即可，但是还是要强调下一定要控制情绪、控制情绪、控制情绪。
不好意思，我正在思考其他问题，思维还没转过弯来，没有太明白你所说的问题是什么地方，你可以再具体说一下吗？
这里有个小技巧就是将没听清的问题归结为自己，而不是归结为对方没说清楚，不太好的示范可能是：
你能不能把话说清楚点，忽然来这么一下，我怎么知道说的是哪里？
第二步：共享知识
此时与场景一不同的地方是，需要先引导对方共享知识，然后根据对方思考背景及提出的问题点做具体回答。
此时对方有可能说的是对的，是我们之前没有思考到的点（如规则引擎有些场景或者问题我们没考虑到），也有可能是对方没有考虑到的（如觉得调用规则引擎没用）。
一般比较好的沟通做法：
产品：嗯，你觉得它没用肯定是有自己的思考角度可能是我没考虑到的，你可以说说你具体是怎么想的吗？（引导研发共享知识）
研发：如果一个新的调用规则引擎被创建，限制每个用户只能领取一张券，但是如果这个引擎被A活动引用了，甲参加了A活动，后来又被B活动引用了，甲又参加了B活动，那不是就领不了券了
产品：对，你说的不错，的确会遇到这样问题。这个问题之前我也考虑到过，后来和XX讨论了这里的细节，解决方案是balabala（共享自己的知识），在文档2.3.4里有具体说明，可能是我过需求的时候没有强调这个地方，你在帮忙考虑一下这样是否可行
不太好的做法可能是，当研发很直白的否定方案，产品会觉得心理不舒服，常见的不太好的谈话可能如下
产品：哪里没用啦？你有没有想过这个做出来能节约后续的开发人力，balabala
这样通常会说了一大堆，然而对问题并没有帮助，可能所有的对话都是围绕怎么反驳研发的那句“没用”，但是具体的研发问题点在哪里都还没有搞清楚，最后很可能争吵很久问题没有解决。
由于上面所举得例子是已经有解决方案了，而且是事先考虑到的问题，所以不再会有继续讨论解决问题。