快捷搜索:

需求沟通中的艺术

《SERU需求历程框架系列文章之四》

需求沟通中的艺术

沟通原先便是一门艺术,而需求沟通的双方平日是不合专业背景的,这就更必要利用一些适合的“艺术性技术”。接下来,我们就经由过程几个场景实例来体会一下。

紧扣沟通工具选择话题重心

对付“需求阐发职员是用户与开拓职员之间的桥梁”的不雅点大年夜家都不陌生,但对付“需求阐发职员照样治理层和用户之间的桥梁”则没有予以足够的注重。信托大年夜家都邑发明这样的一个征象:在项目的启动大年夜会时,高层治理职员出席启动大年夜会时平日只会呆很短的光阴。

这个看上起并不起眼的细节彷佛并没有什么分歧理的地方,终究他们是很忙的。但实际上有隐藏着一些有代价的旌旗灯号,那便是实际上是很多项目在沟通历程中没有很好地回应这些人的核心关注点。

假如需求职员能够更好地从这个角度来完成与此类职员的沟通,那么将给项目带来很多积极的正面效面,下面这个小案例就能够从一个侧面印证这个事理。

案例&场景:

这是一个关于某手机分销商的真实案例,虽然在经营中老是碰到这样那样的问题,但李总却不停以为自己并不必要信息化系统,终究买卖还没有到管不了的程度,加上自己并不认识电脑,不想受那个洋罪。

也恰是基于这个来由,几年往返绝的信息化系统厂商无数。一天,又有一个信息系统开拓商的贩卖代表老马找到了他,他正想下送客令时,老马说道:“您近几年的利润率鄙人降!”。

“哦,您请坐。”,这便是传说中的电梯推销技术,当问题正中对方下怀时就能够为自己赢得光阴。

“经由过程我的懂得和阐发,发明一个对贵公司利润率孕育发生负面影响的身分”,老马开始进一步阐述自己的不雅点,同时在电脑上打开了一张PPT幻灯片,上面是这样一张图:

图1 商业模式示意图I

“您为了鼓励门店多贩卖利润率高的产品,会对自己利润高的产品给门店更高的利润。但有些二级手机厂商为了前进自己的贩卖量,会突破这种规则,直接给门店返利润”,老马说着就切换到了如下所示的图上:

图2 商业模式示意图II

“这时门店将转向主推手机厂商B的手机,由于其利润要高于手机厂商A的手机,而这是你不想看到的”。

“说得没错”,李总表示认同:“对这个问题,你有什么建议?”

这时老马不慌不忙地为其展示了一张产品贩卖阐发报表,然后说:“当然要办理这个问题的条件是找到影响利润的这个产品!”,边说着边开始在报表上辅导起来。

“太好了!”,李总也顾不上粉饰自己的心坎活动,“若何收拾出这张报表呢?”。

话题终于转换到老马所要的结果上,那便是:“应用我们的软件系统就能够天生这样的报表,为您的决策供给最真实的依据。”

故事的终局便是这位曾经执拗不化的李总花了一笔钱上了这套系统,而且全部系统实施历程很顺利,由于只要能够满意他这个目标就物有所值了,根本无需刁难老马。

从上面的例子中我们可以得出一个事理,高层用户关心的是“问题/时机”,平日不乐意细化懂得系统的内部。着实中层用户关心的是“流程”、“可治理性”、“效果”,而操作层用户则关心“营业活动”、“方便”、“速率”等。

从能引起对方兴趣的角度沟通

在上一篇文章中,我们已经提到过“转换关注点”的技术。在此,我们再先容一个有趣的沟通场景。

案例&场景:

有一次,笔者在喷鼻港迪士尼嬉戏时察看到一个治理细节:在太空船游戏区中,在排队区中会先放16人(每一船的容量)进入缓冲区,然后给每小我发一个牌子,上面画着船的号码、进口位置、你将坐的位置、以及进入进口之后的行走偏向(如图3所示)。

图3 路线指引牌示例

我对此深有感触,回来之后与一位做嘉年光光阴游乐场的同伙谈起这个工作。可以他的回应却是:“吃饱了没事干呀,有需要管到这么细吗?”

……

我接下来奉告他:“我当时用腕表掐了一下光阴,每换一船人花掉落的光阴是2分50秒以内,我们现在到你那掐一下”。

当我们用秒表掐了一下光阴,就发明在他这里,每换一船人花掉落的光阴都在5分钟高低。

我就趁热打铁地说到:“你看看,你这一天要少赚若干钱呢?”这时这位同伙说:“我顿时去做一些这样的牌子……”。

为什么这位同伙前后判若两人呢?由于前面的沟通听起来是“治理的资源”,后面的沟公则提到了“经营的效益”。信息系统很多光阴都给人一种“治理资源”的印象,是以假如能够多从“经营效益”的角度来沟通,必然会达到更好的效果,这也是高层治理层真正有兴趣的角度。

捉住问题的本色

问题常常会被表象所掩饰笼罩,假如不能在问题定义时揭开这个表象,那么常常会给办理规划带来问题。而对此类技术阐释得最完美确当属温伯格老师的大年夜作《你的灯亮着吗?—发明问题的真正所在》,在这本书中收录了十余个很故意思的故事,而书名恰是此中最有代表性的一个。

下面我们就简要地回首一下这个故事,看看它背后的哲理对日常的软件开拓事情有什么样的启示:

隐喻:

话日内瓦湖上的山脉中建成了一条很长的汽车地道,为了防止停电时发生劫难,必须提醒司机进入地道之前把车灯打开。针对这个问题,大年夜家提出了办理规划:“警告!前有地道请打开车头灯” 。

但不久之后,路政部门接到了一些反馈与投诉:地道出口风景很美,返回时发明汽车没电,原本是忘了关车头灯!!

这个问题看起来并不难办理,有人顿时提出了一个办理规划:在出口处立一个标牌,写上“关掉落车灯”。

这样问题办理了吗?当然没有!假如夜行车颠末这个地道时,看到写着这个“关掉落车灯”的标题应该作何处置惩罚?难道真的关掉落车灯,那是多么危险的行径呀!在软件开拓历程中,常常也会呈现类似的“惯性思维”,看上去办理了问题,实际上将会孕育发生更麻烦的问题。

案例&场景:

小林在一次电子政务项目中碰到了这样一个问题,用户要求对每个政务申请的各类处置惩罚都必要记录光阴。因为他们选择的是C/S布局,是以取光阴时就碰到问题,每台机械上的光阴都不尽相同。

“不便是光阴不统一吗,让所有客户端登录时先从光阴办事器上取一个光阴就搞定了!”。

但这个规划在实际的运行时却带来了不小的麻烦,因为光阴办事器写得不敷稳定,常常会自动退出,当这种环境呈现时客户端软件就根本无法进入,严重影响了客户的正常应用。

着实办理这个问题的措施有很多,例如在数据库存储时来处置惩罚,即取数据库办事器确当前光阴。而且纵然采纳这种措施,也不应该在光阴办事器同步掉败时阻拦用户登录系统。

隐喻:

既然“关掉落车灯”的办理规划是弗成行的,那么就换个思路吧:前面的思路是事前预防,那就改成事后解救吧。是以就有人提出一个新的办理规划,那便是扶植一个充电站。

然则建充电站也有问题,不仅掩护开支很大年夜,而且本身也会出故障。要办理这个抵触,又有人提出是否将充电站交给私人经营,但这又不相符当地的律例。

“用一个资源很大年夜的办理规划去增补自己的差错”是很常见的问题,蓝本不是什么大年夜问题,却花费了伟大年夜的资源。这种征象在软件开拓历程中也不少见:

案例&场景:

在小陈认真的一个客户关系治理系统项目中,用户在应用了一段光阴之后提出了这样一个问题:客户数据库的数据对照乱,有重名、同客户多笔记录等征象。

小陈绝不踌躇地说:“不要紧,我可以为你们开拓一个功能强大年夜的客户数据清理对象,经由过程对象可以自动识别出这些纷乱的数据,并且供给一些合并、汇总、删除功能”。

跟着这个功能的开拓,项目的范围也赓续扩展,针对这个功能的需求也层出不穷。这便是软件开拓历程中的“充电站”,资源付出了,但真的对项目有好处吗?

这样做相宜吗?彷佛很多人会举手同意,然则也付出了伟大年夜的资源。假如我们细究一下,这个问题是怎么孕育发生的呢?为什么数据会纷乱呢?实际上根源问题是在用户输入数据时,系统对数据的校验不够,是以更科学的措施是加强输入时的数据校验,而不是开拓一个大年夜“充电站”来事后解救。

隐喻:

在万般无奈下,有人提出了一个蹩脚的主见:在出口立一个大年夜牌,上面写上“假如这天间,并且车灯开着,请熄灭车灯;假如天色已晚,并且车灯没开,请打开车灯;假如这天间,并且车灯没打,就别打开它;假如天色已晚,并且车灯开着,请别关掉落它”。

这样能够办理问题吗?显然不能呀,在汽车行驶历程中谁能够涉猎完这么长的一段话呢?

有些时刻,软件开拓职员也会采纳类似的提示语,例如安装历程中的领导便是这样的例子:明知道大年夜家都是闭着眼睛点击“下一步”按钮的,那么为什么还要赓续地重复这样的设计呢?这难道不便是这个蹩脚的标牌吗?

那么如何才能够办理这个问题呢?关键在于对问题的定义,先确定这里到底存在什么样的问题?假如从这个角度来看,不难发明:

图4探求问题的本源

体现出来的问题是车没电了,而为什么没电了呢?由于司机忘了关大年夜灯。为什么会忘了关大年夜灯呢?每每是没有人提醒他而造成了纰漏。经由过程这样的阐发,我们就知道必要的办理规划是“提醒机制”,这时就不可贵出有效的办理规划:

隐喻:

着末终于有一个清醒的人提出了一个有效的办理规划,那便是在出口出立一个标牌,上面写上“你的灯亮着吗?”。

我想这时让你给出类似的办理规划也并训斥事,为什么前面会绕了一圈呢?关键便是没有精确地熟识到什么是问题?这个案例诠释了“对问题进行了精确的定义,意味着成功办理了一半”的内涵。

您可能还会对下面的文章感兴趣: