为什么你每次和开发沟通需求,都像打仗一样?

今天不谈产品规划,也不谈框架,更不谈原型,咱们谈谈为什么你的需求每次和开发沟通,都像打仗一样?

沟通的场景

PM:战斗在革命一线的同志,为了革命成功后能快速步入小康生活,你看这个基础设施能否再打造的完美一点?

开发人员:说人话(情绪平静)

PM:能不能加个需求?你看哈……(还没说完)

开发人员:加不了(听见加需求,有明显的情绪波动)

PM:怎么就加不了?这又不是什么复杂的功能,我逻辑都给你想好了(皱着眉头,非加不可的语气)

开发人员:你项目上线周期定那么死,我现在还有好多接口没完成,哪有时间加啊?(抱怨,情绪不稳定)

PM:那我也没见你们加班啊?再说这需求也不复杂啊,最多1天就能搞定!(鄙视的语气)

开发人员:我在家加班不行吗?1天能搞定,你能你上啊!(爆发的边缘,声音分贝调高)

PM:……(被噎着了,准备出绝招)

PM:反正这是老板的要求,你要是不想加,那你直接去找老板吧(同样用很大分贝的声音搬出老板,来展现自己的气势。顺手把笔记本往桌子上一扔,不再说话,再聊下去就要撸起袖子开干了。)

沟通的结果

大家沟通了10分钟,闹的彼此很不愉快;最后的结果就是PM觉得很不爽,原因是:我好声好气和你聊需求,你给我脸色,我招谁惹谁了?我还不是为了公司的产品着想,心累。开发人员呢,也很不爽,就差点拿刀砍人了,心里在想:你丫就知道加需求,你加一个需求,老子要写5000行代码,时间还限制的那么死,还搬出老板压我,就不加,爱咋咋地。

双方情绪都不稳定,一个没心思思考需求,一个没心思写代码,还可能一不小心搞个bug出来。

其实呢,这个事情,PM和开发都没有错(当然也不是老板的错,捂脸),错就错在没有正确的沟通。

上述只是简单阐述了沟通中的一个问题,PM在日常工作中,上对接领导,下对接开发、设计、运营、财务,左右还要对接客户,回到家还要考虑女朋友的感受,难免会遇到沟通的问题,那如何沟通才能在工作生活做到游刃有余呢?

沟通学的三大要点

1、要理解沟通的定义

什么是沟通呢?很多PM思考这个问题的结论都是:为了某一目的,进行信息交流,以达到彼此都满意的状态。其实这个理解只对了一半,沟通的定义其实很简单,无非是6个字“听得懂,能接受”。

就像沟通场景中有这么一段,PM刚说加个需求,话还没说完,开发人员的小情绪就如潮水般翻涌而来;这就导致沟通定义中前3个字“听得懂”都没有实现,如何继续沟通?再沟通下去,只会越来越糟。

我们来还原一下场景,可能PM是想这么说:“能不能加个需求?这个需求是……这样子的,逻辑是……这样子的,开发时间就放在你们完成手头项目之后”。诶,发现没有,PM原本的意思并不是想现在就加需求;但表达的时候是先说出了“加需求”这个目的,我们把这个目的叫做第4点,需求描述、需求逻辑、开发时间为123点;那么PM表达的顺序就是4123。开发人员呢,一般思维逻辑都是直线型的,也就是1234,拿到一个点就考虑一个点,听到加需求,就开始1234的想,想着想着情绪就不稳定了,开始炸毛了;直接就否定了PM的话,后面的完全听不进去,然后就有了接下来带有情绪的沟通。

这个场景沟通的问题:

  1. PM没有能站在开发人员的角度去把本次沟通的要点描述清楚;
  2. 开发人员没有听懂PM的沟通要点。

总结:PM没能让开发人员“听得懂”,更别说“能接受”了,如果PM能稳住情绪,把沟通的要点说完,那就是另外一种场景。

2、要学会把控情绪

“情绪”分为3种:“语气、场合、肢体动作”。

如上文,PM是知道开发人员没听懂的,但并没有用和善的语气去让对方听得懂,而是皱着眉进行反击;从而导致情绪进一步爆发,直至失控。

现实生活中也有很多没把控好“情绪”的例子。一朋友和我聊天的时候提出一个问题,以下是聊天记录,你们随意感受下。

“我女朋友让我陪她一起逛街买衣服,街也逛了,衣服也买了,为什么她总是一副不开心的样子呢?”(明明就是欺负我这个单身狗,哼哼)

我回答说“那她是不是问你累不累?衣服好不好看?”

“是啊,我说不累,怕她觉得我嫌弃陪她逛街,也说了衣服好看,但为什么她还是不开心呢,问她原因又不说,真是搞不懂”。

“问题就出在你的肢体动作和语气上面,你肯定在说话的时候表现的很不耐烦。”

朋友说“确实有点不耐烦,语气也有点敷衍”

对于这种问题进行分析,得出两个原因:

  1. 他没听懂女朋友话的含义;
  2. 他的情绪没有把控好。

最终导致既陪了时间,又掏了钱,依然不落好。女人问你累不累,其实是想知道你内心愿不愿意陪她,既然都已经陪着逛街了,何不笑着的回答她“累是累了点,但好不容易陪你逛一次街,再累也值得”。既然衣服都已经买了,钱也花了,女人问你好不好看,并不是让你来做任何评判的,而是想获得你的赞美,何不温柔的回答她“你穿什么都好看”。

这样一来,她还能不高兴?所以说,搞懂需求,把控好情绪去沟通很重要。

3、要懂的反馈

这个意思就很简单,我说了,你就要反馈有没有听见,是不是理解;如果没有理解,我可以再说一遍。

假如你老板在公司群@你,并提到一个问题,如果你没有反馈,结果是怎样的呢?

可能是这样的:你没有反馈,你老板就需要花时间去想,你到底有没有看见呢?如果你没有看见,那这个问题怎么处理呢?处理的方式有哪些呢?什么时候能搞定呢?一连串的问题在他脑海中飘过,花费了他大量的时间去帮你思考问题。最坏的结果就是认为你这个人不靠谱。

一定要懂的反馈,那怕是回复“好的、收到”或者是一个的符号都行。

最后

沟通是一门艺术,需要长期的锻炼才能修有所成。一旦你懂的了沟通,你会发现很多问题都不再是“问题”。而沟通对于PM来说,至关重要!

本文来自投稿,不代表性价比网立场,如若转载,请注明出处:https://xjb.yiqirom.com/213.html

Like (30)
Previous 2017年4月20日 下午11:43
Next 2017年4月21日 下午3:24

相关推荐

  • 干货,产品经理如何进行需求分析

    需求分析做错了,做再多也是无用功

    2017年4月17日
    1472
  • 亚马逊产品负责人详解产品优化:流程零阻力策略

    你需要打磨出最佳的用户体验路径。永远留意那些会造成阻力的流程和功能——那些不好的产品总是忽略了这些。这很费力但是值得。并且这个过程并不如你想象的那么难。有时候,阻碍用户和你产品之间的可能只是两颗电池。

    2017年4月17日
    1952
  • 产品终极化形态关键指标:用户洞察(User Insight)

    互联网终极化形态必将是其对应企业的商业化形态,依托营销的方式销售其产品并获得盈利是互联网企存活下去的根本。而对于用户的深度解读是产品业务线开展的参考依据,用户洞察概念在互联网产品上的应用也将越来越凸显其重要意义。

    2017年4月17日
    1800
  • PEP8 Python 编码规范整理

    决定开始Python之路了,利用业余时间,争取更深入学习Python。编程语言不是艺术,而是工作或者说是工具,所以整理并遵循一套编码规范是十分必要的。所以今天根据PEP8整理了一份,以后都照此编码了,还会持续更新。 一 代码编排 1 缩进。4个空格的缩进(编辑器都可以完成此功能),不使用Tap,更不能混合使用Tap和空格。 2 每行最大长度79,换行可以使用…

    2017年4月17日
    2440
  • 一份简单的外包项目产品方案模板

    和内部项目的方案不同,外部项目(外包或者合作)的受众群体是客户,所以应该更加侧重于对产品功能、技术的展示。今天整理外部项目产品方案模板,给可能需要做外包项目的产品经理们。

    2017年4月17日
    1921