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

起点学院产品经理365成长计划,2天线下闭门集训+1年在线学习,全面掌握BAT产品经理体系。了解详情

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

1374129249

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、小结

无论任何一份工作,沟通是一门必修课。或许有千千万万种沟通技巧,本文探讨的感情沟通只是其中一种。用心沟通、让大家懂你,不仅仅带来工作上的高效,也带来了很多小伙伴的认可。一起努力,一起成长,做个优秀的产品经理。

 

作者:Andy

来源:小水滴(微信公众号:minidrupal)

您的赞赏,是对我创作的最大鼓励。

评论( 0

登录后参与评论
加载中