2020年实体店做什么好呢_2020年实体会好做吗_2020年实体经济会好吗
创业准备

沟通管理:六步掌握沟通公式,避免“开口即跪”

时间:2020-03-22

本文总结了关于需求沟通管理方面的六步公式,并用一个事例做了具体形象的比喻,帮助你更好地理解内容要点。

老板:̶┒1;小赖,我看了一下我们的商城,我觉得不行,配色和排版得改Ц一下。改成这样…..,最近看了本书,都说红色有购物欲,就改红色好吧。”

产品:不行啊,老板,这样和我们后台界面就不搭了。

老板:这样啊。那会员界面也要一起改一下,整体设计我觉得还是可以优化一下的。

产品: 额…可是这一改前端要重新开发,上线时间咱们不是要28号么,今天都20号了,赶不上了…

老板:赶不上?那辛苦让团队周末加加班,我们赶在月底上线就行。

产品:额……好吧,兄弟们,老板说要加班改一下。

开发团队:????滚!

老板、甲方脑袋一热的一个需求,轻易的改变Ξ了原本的规划,产品想着努力沟通却ì把工作量从1聊成了10,最后谁都不待见,这是一个真实的互联网产品的日常缩影。

如何掌控沟通、如何有效汇报、如何避免“开口即跪”?

产品、运¤营、项目经理、开发在日常过程中类似情况真的不〓在少数。

过去,笔者见过许多专业能力非常强的老产品,能跟开发聊代码,能跟UI谈设计,画的一手好原型,业务逻辑无比熟悉,最终却无法掌控属于自己的产品节奏。

究其根本,几乎无一例外的是缺乏沟◇通这项“软技能”。

‖|

笔者曾在“某宝”ISV(技术供应商)两年的地狱式产品工作,积累了50+项εїз目负责人经验,在接触了近百位“甲々方☉以及身边的产∶品“真实案例后,总结了关于需求沟通管理方面的六步公式,和大家分享一下。

一、信息的确认

在项目管理指南《PMBOK》中沟通有专门的方法介绍,如推式沟通、拉式沟通、⿷交互式沟通等。

当我们与干系人间й直接产生对话的过程便是交互式沟通,针对交互式沟通最重要的一点便是信息的确认。

你是否Ⅱ有过在需求评审的时候,被开发不断的提问难倒?总有问题要留到会后再去确认?

所以在信息的确认这一步,看似简单,却是影响▬最大的一步⿰。

那么我们如何好信息的确认?◑↔↕▪

重复对方的需求 保证充分的理解 多问一句,我理解的对么

举个例子:

老板۞:”小赖,我看了一下我们的商城,我觉得不行И,配色和排版得改︴一下。改成这样…..,最近看了本Й书,都说红色有购物欲,就改红色好吧。

回答1:老板,我确认一下哈,是希望咱们这个商城整体的界面要做风格改进,还是主色调做一些调整呢?

回答2:老板,您是希望咱们这个商城的主色要调改为红色,我这样理解对么?

回答3:老板,您的意思把商城主色改为红色来增加用户的购物欲,对么?

如以上例子,Ⅳ每个回答都是以疑问句收尾,这样确认信息方式的好处有两个:

保证需求理解一致 通过反问,帮助对方─━梳理清楚需求,引导出真正目的

有时候我们在沟通时,很多人在第一时间是忙着先拿笔记录⊙,这一点笔者不是特别建议。

当然记录本身没有什么错,只是有时候在记录的过程其实会忽略掉一些信息背后的东西,如:沟通情绪、需求紧急度、需求的真实度等等。

所以,整体来说在沟通的第一步,就是确保信息的有效性、准确性。

二、去除部落效应

部落效应(tribeseffect): 对身份的威胁会引发部落效应,这是一种对抗的心态,让你的身份让另一方势不两立:有我们,就是я他们。最有可能出现这种心态的场合,是帮助集体保护本族人免受外部к威胁。——《๑不妥协的谈判》

不知道大家工作中是否有见过类似这样的话:

“你们开发怎么老是出BUG” “你们产品到底懂不懂” “你们什么时候可以把这个项目上线”

诸如此类,在日常工作、生活中,我们经常会被套上各种身份,例如:甲方和乙方、业务方和研发方等等、甚至是产品经理和开发。

当沟通的过程开始陷入各种身份中去,就会引发部落效应。沟通变成了谈判,而谈判总是零和℉的博弈。

项目管理学中:“由于项目的实施与项目的成功,其利益会直接或间接地受到正面或负面影响的个人和组织”称之为项目干系人,能够针对产品提出需求、想法的人,证明其是关心产品成败的。

换句话说,对方正在为共同的产品做努力,这一时刻我们是一个团队,不是两个组织。

所以这一步,更多的话术上的技巧,首先要做的第一件事,就是改变自己对需求的看法。

作为产品的我们需要记住,任何项目、产品最佳实践都是合作,而非对抗。

那么有没有一些干货是我们可以直接用到的呢?

举个例子:

直接就对方的想法提出赞扬:“这个想法很棒” ╣将“你们”改为“咱们”:“咱们市场这边的想法,倒是一个不错的建议” 强调共同目标:б“咱们这个项目最重要的目标是卍抢时间上线,最快获得占用户反馈”

三、陈述实事,打破“我觉得”

知识的诅咒是▉一种认知偏见,指的是当一个人与其他人交流Ⅶ时,不知不觉地认为其他人有背景知识,并且无法理解没有该知识的人是如何看待相同事情

要知道知识的诅咒名词可能大家很陌生,但很容易在产品身上发生,想当然的从个人角度去理解用户是产品的大忌,所以作为产品人的我们,要时刻理解“用户是用户”。同样的,在沟通中也是如此。

我们都说最好的沟通一定是以诚实为基础的,但是有时候我们的诚实,并非真正的诚实,我们经常会忽略掉那些误以为

对方知道的信息,信息不对称,牛头对马嘴如何沟通呢?

所以在沟通的过程中,陈述需求完成的基本条件,是为了让双方能够存在一个共同的知识背景,避免“知识的诅咒”产生。那么这一步也就很简单了,尽量把沟通中需要用到的背景知识说全就好。

举个例子:

老板:&╞#8221;小赖,我看了一下我们的商城,我觉得不Я行,配色和排版得改一下&。改成这样…..,最近看了本书,都说红色有购物欲◁,就▣▤▥改红色好吧。

(按照前面的步骤对话)…

回┍答:如果只是改颜色的话,需要设计N天、需要投入N个 前后端开发N天、整个项目预计延N天,如果安排加急的话最快X时间完成。

类似的方式有很多,也很基础,最核心的地方是把实际信息说清楚,尽量避免模糊空间即可。

四、建立模型,全局分析

所有的沟通,背后的逻辑∞其实З都是щ需求,解决需∝求是沟通最终的目标。

在笔者和自己团队在分享“沟通”这个领域的时候,也反☼复有在强调人与人之间沟通的背后,其实就是需求。

很多@产品、项目新人在入行初期,都非常注意在文档、原型、或是某些软件技能上花过多时间进行钻研,包括笔者当初也是。

当然,画得一手好原型,写的一手好文档本身并没有错。

但是身处介๑于用户、市场与研发之间的产品们,我常常称之为“中间件”,如何保证需求与价值之间的其实才是这个岗位最重要的工作,也就是我们常说的“投资回报率”。

如何保证业务需求的准确性、高回报比,让〢研发的工作产生最大的价值,这个部分笔者不做详细赘述。

举个例子,笔者就经常使用类似价值成本分析法、OKR象限法等。

价值-成本图谱

1.本站遵循行业规范,任何转载的稿件都会明确标注作者和来源; 2.本站的原创文章,请转载时务必注明文章作者和来源,不尊重原创的行为我们将追究责任; 3.作者投稿可能会经我们编辑修改或补充。转载请注明模板网#