【产品干货】感情沟通之美

在产品经理这个岗位上，沟通能力很重要。尤其是注入感情的沟通更加高效。笔者总结了工作中一些沟通的方法和技巧，希望对大家有帮助。

1. 沟通是什么

百度百科中是这样定义沟通的：沟通是人与人之间、人与群体之间思想与感情的传递和反馈的过程，以求思想达成一致和感情的通畅。

我个人非常认同这个定义。在实际的沟通过程中，非常多时候产品经理都停留在思想的传达。

比如：我要做**需求，这个功能用不了是不是有bug，你们什么时候能够给我体验功能等等。这些沟通没有非常好地表达出自己的感情，而是硬生生地表达出自己想做什么而已。

2. 注入感情的沟通

先举工作中一个实际的样例。技术GG非常辛苦地把需求做出来了。兴致勃勃地让产品经理体验功能。

过了一段时间产品经理走到技术GG的座位。对技术说：“这个功能用不了，是不是代码有bug，麻烦你看看。”我们尝试使用同理心，当听到这种话。技术GG的心理反应是：

1. 我自測都没问题。是不是你的环境有问题；
2. SB你会用么
3. 肯定不关我事。你找server同学看下吧
也许还有非常多其它不好的反应。

这里的沟通停留在表明自己思想，假设要增加感情要素，应该是怎么的沟通方式呢，下面是參考建议。能够委婉地跟技术GG说：“这个跟我的需求有点不一样。是不是我的用法有问题，我们一起来看看是什么原因？”此时技术GG会是心理一震：“我擦，是不是有bug了”。然后两方非常友好地去跟进这个问题。这是有效的沟通。是注入了感情的沟通。
第一，结果先行。需求跟我期望的不一样；
第二。自我反省。把问题抛出来说明可能是我的原因；
第三。合作解决。一起找原因。
接下来继续通过实际的案例，阐述感情沟通之美。

3. 感情沟通之美

3.1 我们都是坐同一条船的

在公司里每一个小组都肩负着各自的KPI，而KPI的完毕情况决定着每一个人的升职加薪和年终奖。正是这样的KPI制度，会让非常多非常多的员工都仅仅是关注自己的KPI，而忽略了部门的KPI。一般来说产品经理肩负着用户在线、日活跃、收入等指标，研发则负责需求研发、提升开发效率、优化性能等等。

非常多时候。赶进度加班都成为了家常便饭，尤其是技术GG更是无限吐槽。几个比較经典的吐槽：麻痹的，产品又改需求了，导致工作量添加；现网有bug，本来用于开发的时间被暂时占用了，又得加班了；工作量非常大，时间又短，被PM催死了。。。。

作为产品经理，非常应该去思考用户（技术GG）的吐槽，找出痛点。然后进行优化。技术GG的为什么会吐槽，主要是不爽。为什么不爽？由于非常多时候感觉是在帮产品经理干活，而不是在做着有兴趣有意义的事情。找到用户痛点之后，就须要出方案解决这个问题。我的思路是：我们都是坐同一条船的。这里的关键是我们。在沟通中让大家意识到我们一起在战斗。
分享一下产品常常遇到的沟通难题。

1）产品需求变更。每次变更需求都会带来研发和PM的反感，大家都懂的。这个时候，我会站出来做几件事情。

第一：需求变更的目的
第二：为什么须要变更，变更后的方案比之前的方案有什么优点。对用户和部门的价值是什么
第三：变更后给技术带来什么难处，我们一起罗列一下。然后再评估是否在本迭代变更

这就是美：让全部人懂你，理解你的变更，才干支持你的工作。

2）加班赶需求。每次我们都会定下***时间须要公布版本号，然后所有人都被逼去加班。

好吧。这是件蛋疼的事情，怎么让大家打鸡血，是个难题。
第一：清晰表明为什么要定下这个时间点。上升一个层次，从部门的KPI出发，这个版本号的成功直接影响到部门的发展前景和每一个人的年终奖，与我们息息相关。

比如配合某游戏做活动，赶上世界杯，冲PCU里程碑版本号等等
第二：这个版本号核心功能是什么。哪些功能是能够适度削减的（一定要留有讨价还价的空间）
第三：阐述领导的期望。我们做得事情领导时时刻刻都在关注。
第四：加班的不仅仅是技术。而是整个团队。

对关键的核心人员做好思想工作。
第五：加班偶然请吃饭。这个很有效，尤其是长时间加班作战的团队。

这就是美：提升思考层面，让參与者感受到眼下的困难和挑战，一起去战斗。

3.2 希望技术写出高效的代码

项目迭代节奏非常快，需求评审的质量直接影响到终于的产出。为了保证需求评审的质量。我提出了需求初评环节。初评，就是初步的沟通和评审。

这个环节有几个优点
1）提前预告需求功能，让技术GG心理有底。

研发都追求简洁的代码和优秀的设计方案，提前知道产品规划方向。有助于更好的制定设计方案。

在沟通中须要关注技术GG的反应，希望能够写出高效的代码。提升产品开发效率。
2）发现技术难点，产品方案规避。

产品遇到非常尴尬的地方就是在需求评审上技术GG说这个功能实现不了，或者说要一个月才干做出来，评审的结果必定是产品改动需求方案，择日再评审。

遇到难题。须要明白沟通。能够把产品的烦恼抛出来。让技术也參与到产品方案的设计。

初评中须要注意控制相关的參与人员和评审时间。由于是初评控制好成本。讨论核心问题就可以。

这就是美：我中有你。你中有我，相互协助，把活干好。

3.3 产品经理无处不在

在项目过程中，眼下产品參与的会议包含：需求评审、測试用例评审、迭代计划会，这三个会议都是必须參加的。另外另一个技术评审会议。一般来说产品经理是不须要參加的。

因为本次需求非常复杂，涉及到的交互细节也非常多。为了防止技术方案中的遗漏关键点，这次的技术评审我主动參与了。
一般来说，是不建议产品參加技术讨论的。
第一：产品听不懂技术的讨论。整个会议感觉异常无聊
第二：浪费你非常多时间，说不定一个小时下来你才參与几分钟

我曾经做过技术和项目经理。非常easy融入到技术讨论中。基于自身的经验，假设要參与技术评审，产品经理须要具备下面条件：
第一：有技术背景。
第二：有移动办公设备。技术评审不是我们的主场。产品仅仅是协助技术团队而已。所以參与感非常低。为了不浪费时间，所以须要有移动设备办公，在技术须要我么的时候，立马提供协助就可以。

重要：技术评审就像一个菜市场。产品要在这个环境下工作，适当时候提供协助。对于个人能力要求非常高，假设受到外界影响非常大的话。建议不要參加了。等技术须要你的时候，再电话或者来会议室參加讨论就可以。

这就是美：适当參与，帮助技术，无处不在的服务精神