求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Modeler   Code  
会员   
 
  
 
 
 

尊重用户的现实选择

 

2011-2-25 来源:网络

 

  我们常说,存在即为合理,但是在许多产品经理的需求工作中,似乎并不是这样。
    许多客户提出的需求,在经过了我们人为的过滤之后,被打上“不现实”、“不可能”的印记而束之高阁。
客户提出的这些被束之高阁的需求果然是不现实,不可能的吗?
    在01年的时候,我在一家通用软件企业,当时互联网已经开始平民化,许多传统的软件公司也开始关注这个市场,希望能在网络大潮中有所作为,当时,公司开发了一个基于IE内核的网上冲浪平台,之所以没说是浏览器,是因为这个平台集合了许多网络应用工具,例如邮件收发,网络下载,网上聊天等,有点像现在许多浏览器上增加的插件,但是我们那个产品的插件是不开放的,只能由公司来提供。
    当时,这个产品的产品经理获得了一个需求,用户希望能够通过这个平台订阅自己感兴趣的新闻,并且能主动推送给订阅者,类似于现在的RSS,这个产品经理分析了这个需求后,得出的结论是:这个需求在现阶段不能实现。
理由如下:
     1、网络环境:那个时候,家庭用户普遍还是56K猫,好一些的家庭用户顶多是ISDN,虽然已经有ADSL了,但是价格贵的离谱,这样的网络环境去实现搜索并整合成用户订阅的信息,简直是天方夜谭。
     2、信息来源:01年的时候,软件公司和互联网公司基本属于老死不相往来,软件公司的看不上互联网公司,认为一点技术含量也没有,这就出现了一个大问题,客户订阅的信息从何而来呢?去抓取互联网公司的信息,除了技术上的考虑,更关键的是质量上的考虑,如果没有固定的信息来源,即使第一个问题解决了,依然无法实现这个需求。
     3、表现形式:可能是因为当时受到新闻形式的固有思维所限,他认为推送给用户的新闻就应该是图文并茂并且能够让用户在线阅读的形式,如果是这种形式,那么,就又会受到第一个问题的影响而无法实现。
当时我记得这个产品经理列了很多个原因,但是我印象比较深的就是这三个,确实没错,即使仅仅是从这三个原因去看,确实对于实现这个需求是一个很大的挑战。但是,在前面说到了,存在即为合理,既然有用户提出了这个需求,那么就说明这个需求是合理的,也就说,客户提出的任何关于产品的需求都是对的,有朋友可能会说了,你这是吹毛求疵,怎么可能呢?
    其实原因很简单,首先,客户提出的需求可能是业余的,但很有可能是需要的,我们不能用我们专业的角度直接就否掉一个可能许多用户都非常需要的需求,这在第一篇文章里也说到了,关键是我们对待客户的心理决定的,其次,客户提出的需求可能是不好实现的,但不代表是不能实现的,正是因为我们有时候显得过于专业了,在思考许多问题的时候,陷入了一种专业思维的惯性中,尤其是一些技术转型的产品经理,更是如此,往往去思考一种最完美的实现形式,因此,许多不可能仅仅是因为我们觉的不够完美而已,第三,也是最关键的一点,客户提出的问题往往不会超出我们的产品范围,这很好理解,用户对于产品的需求都是引导式的,简单地说,也就是只有当用户在使用了产品的A应用后,才会促使他去想会不会有比A更好用的B能够更好的满足我的需求呢? 大家可以仔想想,我们在使用一个产品的时候,经常会想,“如果这个功能要是能这样或者那样改进一下就更好了”,而这种想法的前提一定是在我们使用了这个产品后才会有的。
    因此,用户提出的问题都是在目前这个产品范围中的,用户是不会提那些没有接触过,但是却能够靠空想描述出的需求来的。
    简单的说,想法一定是建立在客观上的。
    因为我们的产品是客观的,用户的使用也是客观的,他们的想法也是客观的,客观的就一定是存在的,存在的就一定是合理的。
    我们不要轻易否定用户的需求,不要轻易向用户说:你的想法是错误的。
    因此,需求分析原则二的第一点就是:客户永远是对的。 那么,基于这个前提,我们产品经理要做的事情又是什么呢?
    很简单,找到一个最合适的方法来满足用户的需求,而不要去找最好或者最贵的方法。
    继续刚才那个案例,最终那个需求实现了吗?当然实现了,并且实现效果在那个时期了还是不错的。
    先不说我们是怎么实现的,咱们先来做两个假设。
    第一个假设:
    去寻找一种最好的解决方法,我们会想,如果用户家里是512K的ADSL(估计那时候许多人还不知道AD呢)该有多好,要是互联网公司都开放接口该有多好,要是互联网上的信息都是规范的该有多好……当然了,最终我们会想,要是用户不提这个需求该有多好,省的我这么麻烦,呵呵。这个假设的前提本身就是有问题的,期望通过一种理想状态来实现需求,如果这种理想状态真的有了,还需要你产品经理干什么,产品经理不就是为企业寻找与众不同的机会,创造与众不同的产品,为客户创造与众不同的价值吗?如果做不到这些,企业能答应你吗?
     第二个假设:
    去寻找一种最贵的解决方法,刚才也说到了,其实从根本上来说,要是能够解决用户带宽的问题,那么,其他两个问题是比较容易解决的,那么,我们可以这样做,一方面从公司入手,增加自身服务器出口带宽,另一方面,从用户入手,要求用户都换成ISDN或者ADSL,这样,这个需求就很容易实现了。但是,成本呢?先不说公司自己,有那个用户会因为看几条新闻而付出这么大的成本呢?如果想做到这些,用户能答应你吗?两种比较极端的假设就不去多说了,好,我简单来说一下当时公司是怎么来实现这个需求的,可能用现在的眼光来看就显得有些可笑和幼稚了。
    我们无法改变用户的网络环境,那么我们唯一能做的就是优化信息的来源和形式,通过优化来尽量满足用户现实的网络环境。
其实思路很简单,就是这个,当然,具体工作就多了,例如通过人工来收集信息(还好,当时互联网上中文信息有限,所付出的收集成本不是太高,如果是现在这种情况,靠人工来实现就肯定不可能了,并且当时投资我们公司的集团还投了一个互联网公司,做分类信息的,这种共享的资源对我们做这个服务起到了关键的作用),把信息通过自己开发的一个小软件自动导成纯文本的,虽然表现形式上不如HTML的,但是传输速度大大增加了,有时候用户订阅的最大新闻量也不会1K,现在RSS传输过来的也是纯文本。
反正通过利用了不少方法,在没有增加公司多少成本的情况下,这个需求还是实现了,也赶上当时许多用户确实是处于上网兴奋期,对于美观不美观没什么太多的要求,能有新闻看,能有论坛灌水,能有聊天聊天就非常满足了。
因此,需求分析原则二第二点就是:提供最合适的解决方案,而非最好或最贵的方案。

  我们能够提供给用户的产品在不断发展,不断改进,不断完善,同样,我们的用户也在不断进步,不断熟悉,不断精通我们的产品,我曾不止一次见到许多用户提出了非常专业的问题,甚至有时候看产品的眼光比我们许多产品经理还犀利,我曾经待过的一家公司就把一个用户招了进来,最终做到了产品经理。
    因此,如果用户的进步速度超过了我们的发展速度,那么,我们的产品在市场上就面临着很大的危险,这样的产品太多了,遍地都是,比如说winzip这个软件吧,想当年是多么的火,但是现在还有多少人去用它呢,没落的原因有很多,其中有一点就是当许多用户对zip和rar这两种压缩格式都非常熟悉,并期望用一种软件就能实现兼容的时候,winzip落伍了,当winrar能够兼容zip的时候,winzip依然守着自己的一亩三地,让许多winzip的用户投向了winrar。(备注:zip和winzip不是一回事,zip依然流行,但是winzip却不行了。)
    因此,我们许多产品经理不用想当然的认为用户对产品的理解永远不如我们,尤其是软件或者互联网行业的产品经理,认为自己是高科技的玩意,说实话,对于用户来说,没用,一个功能不好用,马上就可以转投他家,因为用户的转移成本太低了,有时候我就在想,是不是也是因为这个原因,造成了许多软件和互联网的产品经理不重视和用户的交流,相对于传统行业的产品经理来说,我们欠缺的太多了,需要向传统行业的同行们学习的太多了,而我认为最为重要的,最需要学习的一点就是:永远不要把自己和用户拉的太远,永远不要认为自己做的东西用户不懂,永远不要认为用户只能按照自己的想法来使用产品,简单的说,就是永远不要把用户当成傻瓜。
    对于产品经理来说,没有傻瓜用户,只有我们傻瓜的想法,我们有时候确实太天真,想着能靠忽悠和谎言来自圆其说,保持用户的满意度和忠诚度,如果你现在依然是这么想的,那么,我只能说这个傻瓜是你,而不是用户。
    因此,需求分析原则二第三点就是:不要把客户当傻瓜。我想,应该在这句话前加一个前缀,就是“永远”。
总结一下需求分析第二个原则的中心思想:
    1、需求分析第二个原则:尊重用户的现实选择。产品是客观的,用户是客观的,使用是客观的,需求也是客观的,一切都是现实的。
    2、原则第一点:客户永远是对的。客户不是我们的敌人,客户不会害我们,客户提出的需求看似在为难我们,但本质上是为了让客户自己更好的使用产品,因此,客户不会为难自己。
    3、原则第二点:提供最合适的解决方案,而非最好或最贵的方案。我们能够做的不一定是最好的,我们不想做的有时候往往是客户最需要的,找到最合适客户的,而不是最合适我们的。
    4、原则第三点:不要把客户当傻瓜。这个世界上没有傻瓜,自以为对方是傻瓜的人才真的是傻瓜,不要忽悠客户,不要欺骗客户,如果非要在这个前面加上一个期限的话,我希望是“永远”。



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


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


北京 软件需求分析与管理
某知名基金 软件需求分析
联想 业务需求分析与建模
财税领域某IT服务商 测试需求分析
医疗行业 面向产品的需求管理
某知名IT服务商 测试需求分析>
某高新技术公司 测试架构、需求分析
更多...