需求分析的六个原则(一)永远不要显得比客户更聪明

 

2010-12-1 来源:网络

 
     不知道大家想过没有,为什么要把这条作为产品经理进行需求分析的第一原则呢?

我个人觉的,之所以这条作为第一原则,就是告诉我们这些产品经理一个对待客户的基础态度,是什么呢?就是“平等”。
有朋友会说了,我们提供能够满足客户的产品和服务,客户付费享受这些,这肯定是平等的呀,有什么好说的呢?
果然如此吗?
02年的时候,我在一家软件公司做产品经理,当时我们公司为了能够让我们的客户更贴近公司产品,最好是参与到公司产品设计中(联盟里好像有这样一篇文章:《让顾客参与产品设计》)成立了一个叫“用户实验室”的部门,这是一个常设部门,专门有一个人在进行管理,主要的工作就是不定期的邀请一些公司的用户来体验公司的最新产品,并让他们提出自己的意见和建议,以方便产品部门进行进一步的改进,目的是在上市的时候,尽量能够达到用户期望的指标。
这个部门的运作就不具体说了,具体说一个案例吧。
有一次,公司另一个产品的产品经理组织了一次新产品用户体验,当时来了大概不到30个用户参与新产品的试用,大家想了,能够耽误个人时间来参加这次试用的用户肯定是公司或者产品的铁杆支持者了,因此,这些用户都显得非常认真,每一个细节都不放过,并且在试用完成后,都非常精心的完成了公司准备好的问卷,至少从我一个旁观者的角度来说,我觉的这次用户试用还是非常有成效的。
但是过了几天,我和那个产品经理闲暇聊天,问他看了那天的用户问卷,对产品有什么新的想法吗,他说“不瞒你说,你是没看那些问卷,那些人(指用户)的想法真幼稚呀,我就不信了,用户会提那样的问题出来”,我说“那你考虑去改进一下目前的产品吗?”,他说“改什么改,我设计的产品我还不知道,要是按照那些人的想法做,这产品成什么了,我和你说啊,那些人来就是一个噱头,咱们该怎么做还是怎么做”。

既然不是我负责的产品,我也就不好太多说什么,这件事情就这样过去了,直到看到这个原则了,我的头脑中才又浮现出这个事情。
通过这个案例,我就是想说明一点,其实在许多产品经理的心中,对客户有一种根深蒂固的“瞧不上”,只不过是看在客户掏钱的面子上,大家过得去也就算了。

后来开始带人,不止一次的看到有的产品经理在拜访完客户回来后,兴奋地和我说“我从来没见过这样的客户,简直什么都不懂,提的问题真是弱智”,满脸的不屑,甚至是鄙夷。
因此,在需求分析原则一中的第一条就是“了解需求,而不是去批评用户”,而我们的许多同行却是一直在扮演着批评家的角色,对于用户的需求阳奉阴违,当面说的是“非常感谢您的建议,我们会认真考虑的”,头一扭,就对团队的人说“提的这是什么,大家别管这些,继续按照我们的做”。

更为可怕的是,这种对待客户的态度已经蔓延到整个产品团队甚至是整个公司,大家如果留点心,可以去观察一下团队里的对待客户的态度。

那么,为什么会出现这样的情况呢?

似乎联盟里也就这个事情进行过一些讨论,大家都能说出许多原因来,我总结了一下,无非就是三点:

1、我是内行,客户是外行

2、我是设计者,客户是使用者

3、我是产品专家,客户是产品用户

这三点其实都反映出许多产品经理的一种心态,就是五个字:我懂你不懂。

果然如此吗?

再来说一个例子。

04年的时候,我在一家做SP的公司,负责他们的小区短信产品,这个产品大家都很熟悉,就是每当我们进入到某个区域的时候,例如你从北京进入到河北,就会自动收到一条河北移动发送的欢迎短信,我们的产品可以由用户来划定范围,例如北京-海淀-中关村-科贸大厦,只要一进入到科贸大厦,就可以收到一条短信,具体短信内容可以由发送者来制定,同样,也可以设定接收者在离开的时候收到短信。
有一次,某省举办了一次高规格的展会,省里面的头头闹闹们都出动了,那些参展商为了吸引领导能够到自己的展位一观,于是都到移动开通了这项服务,并指定了领导的手机为接收手机,短信内容都差不多,基本都是领导来进入指定区域的时候,收到“欢迎XXXX领导来我展位指导,展位编号:xxxxx”,领导离开的时候,就会收到“非常感谢您对我公司的厚爱,XXXX公司敬上”类似这样的内容。
按说从服务流程上一点问题也没有,但是却出现了一个很大的问题,那次大概有500家参展商,据说有400家开通了这个服务,大家可以想象了,当那些领导在一踏入指定区域的时候,他们的手机该是多么的热闹呀,当这些领导离开这个区域的时候,又不得不热闹一次,这还不是最麻烦的,最麻烦的是有一些领导因为某些事情,必须反复进出这个区域,我想那些领导的手机在那一霎那,就似乎开了一场交响乐,交相辉映,热闹无比了。

最终的结果是移动的老总被省里警告,我们被移动警告,差一点封了我们的端口。
这说明什么呢?

我们做产品经理的,或许可以把产品本身设计的足够好用,足够完善,但是,我们很难把客户的业务流程设计的足够完善,也就是说,我们对于用户会在什么环境下使用我们的产品,往往是一无所知的,即使有了一定的数据去支持我们尽量能够在用户习惯的环境下使用产品,但是一切皆有可能,用户是不会按照我们的思路出牌的,除非你做的产品就是独一无二,无法或者不易被替代的,例如windows,即使这样,微软每年也要在用户使用环境上下很大的功夫。

这就是需求分析原则一中的第二点:客户比你更熟悉业务环境。

有朋友又会说了,这个问题其实也很容易解决呀,让用户把这个问题告诉我们不就可以了,从技术上来说,这个问题是很容易解决的。
果然如此吗?

还以上面那个短信产品的例子来说。

首先,如果没有这次展会,或许这样的问题根本不会出现,那么,我们永远不会知道如此集中的用户会在一个集中的区域发送短信,我们从何得知用户会有这样的一个使用环境呢?
其次,即使出现了这样的问题,而短信的接受人不是这些省力的领导,而是普通的参会观众,即使这个问题被反馈上来了,会引起我们的足够重视吗,如果能够引起我们的重视,引发我们的思考当然最好了,那么,如果没有呢?
最后,即使我们看到了这个问题,但是通知给我们这个问题的不是运营商(其实也是如此,如果不是移动的警告,我想这个问题还会拖下去)而是一个具体的客户,我们能否平等地去对待这个客户的意见呢?这就又和第一条联系在一起了,我们和客户之间应该是一种平等,这种平等不是建立在交换上的,而是建立在心理上的,尤其对于产品经理来说更是如此。

好,那么,如何来解决这种问题呢?

这就是需求分析原则中的第三点:真正的问题只有客户知道,我们要做的就是让客户愿意说出来。

这里面包含三层意思:

1、客户知道问题所在:作为产品经理,有时候会有一种心理优势,认为自己知道问题的所在,其实不然,你所知道的只是产品本身问题的所在,但是产品不是艺术品,不是放到博物馆展览的,而是要由用户在千差万别的业务环境中使用的,不同的使用环境也决定了问题的多样化,我们仔细想一下,其实有时候我们接触的大部分产品问题本质上并不是产品本身的问题,而是因为客户业务环境的不同造成的。
因此,从这个角度来说,客户才是真正知道问题所在的人。

2、我们如何得知:客户虽然知道问题,但他们并不是解决问题的人,最终还是要通过我们的分析来解决,那么,我们就必须知道出现了那些问题,这就得通过客户反馈给我们,无论是前面说到的用户实验室,还是现在咱们常用的许多形式,根本还是希望能够获得一手的用户使用信息。

3、客户如何给我们:这里不是说信息反馈途径,而是指客户传递信息时的心态,其实这是和我们的态度紧密相关的,正如前面第一个案例说到的,虽然通过用户实验室能够完成第一和第二个工作,找到问题和告诉我们,但是,我们可以假设一下,如果我以前那个同事对待客户反馈信息的态度被客户得知,那么,我们能认为这些本来很支持我们的客户还会继续支持我们吗?争取一个客户很难,但是放弃一个客户却很容易,大部分客户的流失并不是因为产品本什么,而是因为我们对他们的态度。
因此,在第三点里特别说明了,一定是要让“客户愿意说出来”,而这种愿意,本身就包含一种客户的主动,而这种主动就是建立在我们对待客户真正的心理平等之上的。

总结一下需求分析第一个原则的中心思想:

1、需求分析第一个原则:永远不要显得比客户更聪明。
聪明反被聪明误,这样的事情太多了,我们产品经理都是有智慧的人,而不是耍小聪明的人。
2、原则第一点:了解需求,而不是去批评客户。

产品经理不是批评家,心理上要重视客户,行动上要尊重客户,平等对待每一个客户。

3、原则第二点:客户比你更熟悉业务的环境。
产品经理熟悉的仅仅是产品本身,但是,产品经理要做的却不仅仅是产品本身。

4、原则第三点:真正的问题只有客户知道,我们要做的就是让客户愿意说出来。
客户会给你反馈,但是这些反馈有些是真实的,有些是敷衍的,你希望真实还是敷衍,请参考原则第一点。



需求分析方法—把测试流程图表化
敏捷需求分析五大关键因素
写好市场需求文档的10种技巧
需求分析中减少客户摩擦的法则
软件项目需求管理复杂性分析
EPC-事件驱动的流程链


软件需求分析与管理实践
业务建模与业务分析
软件需求分析管理
软件需求分析师
软件需求分析与管理
IT规划体系与实践

相关咨询服务
软件需求分析与管理


某电信服务商 需求分析与管理
普天物流 需求分析与管理
安世亚太 需求分析与管理
国际通信公司 嵌入式需求分析
中国电信 需求分析与管理
易宝支付 基于平台的需求分析
富士通软件 敏捷需求最佳实践
中创信测 产品需求分析与管理
广西移动通信 需求分析
紫光华宇 需求分析与管理
宇龙通信 软件需求分析与管理
 
 
 

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号