在产品经理这个岗位上，沟通能力非常重要，尤其是注入感情的沟通更加高效。笔者总结了工作中一些沟通的方法和技巧，希望对大家有帮助。
1、沟通是什么
百度百科中是这样定义沟通的：沟通是人与人之间、人与群体之间思想与感情的传递和反馈的过程，以求思想达成一致和感情的通畅。我个人很认同这个定义，在实际的沟通过程中，很多时候产品经理都停留在思想的传达。例如：我要做**需求，这个功能用不了是不是有bug，你们什么时候可以给我体验功能等等。这些沟通没有很好地表达出自己的感情，而是硬生生地表达出自己想做什么而已。
2、注入感情的沟通
先举工作中一个实际的例子。技术GG很辛苦地把需求做出来了，兴致勃勃地让产品经理体验功能。过了一段时间产品经理走到技术GG的座位，对技术说：“这个功能用不了，是不是代码有bug，麻烦你看看。”我们尝试使用同理心，当听到这样的话，技术GG的心理反应是：
1. 我自测都没问题，是不是你的环境有问题；
2. SB你会用么
3. 肯定不关我事，你找服务器同学看下吧
或许还有很多其他不好的反应。这里的沟通停留在表明自己思想，如果要加入感情要素，应该是怎么的沟通方式呢，以下是参考建议。可以委婉地跟技术GG说：“这个跟我的需求有点不一样，是不是我的使用方法有问题，我们一起来看看是什么原因？”此时技术GG会是心理一震：“我擦，是不是有bug了”，然后双方很友好地去跟进这个问题。这是有效的沟通，是注入了感情的沟通。
第一，结果先行，需求跟我期望的不一样；
第二，自我反省，把问题抛出来说明可能是我的原因；
第三，合作解决，一起找原因。
接下来继续通过实际的案例，阐述感情沟通之美。
3、感情沟通之美
我们都是坐同一条船的
在公司里每个小组都肩负着各自的KPI，而KPI的完成情况决定着每个人的升职加薪和年终奖。正是这种KPI制度，会让很多很多的员工都只是关注自己的KPI，而忽略了部门的KPI。一般来说产品经理肩负着用户在线、日活跃、收入等指标，研发则负责需求研发、提升开发效率、优化性能等等。
很多时候，赶进度加班都成为了家常便饭，尤其是技术GG更是无限吐槽。几个比较经典的吐槽：麻痹的，产品又改需求了，导致工作量增加；现网有bug，本来用于开发的时间被临时占用了，又得加班了；工作量很大，时间又短，被PM催死了。。。。
作为产品经理，很应该去思考用户（技术GG）的吐槽，找出痛点，然后进行优化。技术GG的为什么会吐槽，主要是不爽。为什么不爽？因为很多时候感觉是在帮产品经理干活，而不是在做着有兴趣有意义的事情。找到用户痛点之后，就需要出方案解决问题。我的思路是：我们都是坐同一条船的。这里的关键是我们，在沟通中让大家意识到我们一起在战斗。
分享一下产品经常遇到的沟通难题。
1）产品需求变更。每次变更需求都会带来研发和PM的反感，大家都懂的。这个时候，我会站出来做几件事情。
第一：需求变更的目的
第二：为什么需要变更，变更后的方案比之前的方案有什么好处，对用户和部门的价值是什么
第三：变更后给技术带来什么难处，我们一起罗列一下，然后再评估是否在本迭代变更
这就是美：让所有人懂你，理解你的变更，才能支持你的工作。
2）加班赶需求。每次我们都会定下***时间需要发布版本，然后全部人都被逼去加班。好吧，这是件蛋疼的事情，怎么让大家打鸡血，是个难题。
第一：清晰表明为什么要定下这个时间点。上升一个层次，从部门的KPI出发，这个版本的成功直接影响到部门的发展前景和每个人的年终奖，与我们息息相关。例如配合某游戏做活动，赶上世界杯，冲PCU里程碑版本等等
第二：这个版本核心功能是什么，哪些功能是可以适度削减的（一定要留有讨价还价的空间）
第三：阐述领导的期望。我们做得事情领导时时刻刻都在关注。
第四：加班的不只是技术，而是整个团队。对关键的核心人员做好思想工作。
第五：加班偶然请吃饭。这个非常有效，尤其是长时间加班作战的团队。
这就是美：提升思考层面，让参与者感受到目前的困难和挑战，一起去战斗。
希望技术写出高效的代码
项目迭代节奏很快，需求评审的质量直接影响到最终的产出。为了保证需求评审的质量，我提出了需求初评环节。初评，就是初步的沟通和评审。这个环节有几个好处
1）提前预告需求功能，让技术GG心理有底。研发都追求简洁的代码和优秀的设计方案，提前知道产品规划方向，有助于更好的制定设计方案。在沟通中需要关注技术GG的反 应，希望可以写出高效的代码，提升产品开发效率。
2）发现技术难点，产品方案规避。产品遇到很尴尬的地方就是在需求评审上技术GG说这个功能实现不了，或者说要一个月才能做出来，评审的结果必然是产品修改需求方案，择日再评审。遇到难题，需要明确沟通，可以把产品的烦恼抛出来，让技术也参与到产品方案的设计。
初评中需要注意控制相关的参与人员和评审时间，因为是初评控制好成本，讨论核心问题即可。
这就是美：我中有你，你中有我，相互协助，把活干好。
产品经理无处不在
在项目过程中，目前产品参与的会议包括：需求评审、测试用例评审、迭代计划会，这三个会议都是必须参加的。另外还有一个技术评审会议，一般来说产品经理是不需要参加的。由于本次需求很复杂，涉及到的交互细节也很多，为了防止技术方案中的遗漏关键点，这次的技术评审我主动参与了。
一般来说，是不建议产品参加技术讨论的。
第一：产品听不懂技术的讨论，整个会议感觉异常无聊
第二：浪费你很多时间，说不定一个小时下来你才参与几分钟
我以前做过技术和项目经理，很容易融入到技术讨论中。基于自身的经验，如果要参与技术评审，产品经理需要具备以下条件：
第一：有技术背景。
第二：有移动办公设备。技术评审不是我们的主场，产品只是协助技术团队而已，所以参与感很低。为了不浪费时间，所以需要 有移动设备办公，在技术需要我么的时候，立刻提供协助即可。
重要：技术评审就像一个菜市场，产品要在这个环境下工作，适当时候提供协助。对于个人能力要求很高，如果受到外界影响很大的话，建议不要参加了。等技术需要你的时候，再电话或者来会议室参加讨论即可。
这就是美：适当参与，帮助技术，无处不在的服务精神
4、小结
无论任何一份工作，沟通是一门必修课。或许有千千万万种沟通技巧，本文探讨的感情沟通只是其中一种。用心沟通、让大家懂你，不仅仅带来工作上的高效，也带来了很多小伙伴的认可。一起努力，一起成长，做个优秀的产品经理。
