简体中文
会员名称: 登入密码: [Register] 注册 忘记密码 启用我的帐号
 
[转]别把用户需求看得太远  XML
论坛首页 »项目开发» 软件工程
发表人 内容
ttyyiiee

[Avatar]

注册时间: 2006-11-21 23:17:55
文章: 28
离线

1:用户的需求并不是一定代表着技术的超越。

白鸦的文章中一匹“更快的马”中提到。福特在听到别人“需要更快的马”的时候推出了汽车。其中关键的地方就是找到用户的真正的需求。于是后面有了很多有我能和我该作什么的讨论,但,找到真正需求的意义并不是我们有什么样的技术或者是去发展什么样的技术。后面keso提出的内燃机技术是解决用户这个需求的限制条件,某些时候是这样的,但这只占有很小的一部分。大部分时候产品的开发失败不是技术原因,而是设计的原因;当找到了用户真正的需求,甚至小小的改变就能收到很明显的效果。

用户并不关心自己的需求是被怎么满足的,至于采用什么样的方法去满足,多数用户并不会去注意。

圆珠笔的例子是个不错的证明,在发明之初,用户的需求无非是:“成本低廉,书写流利,携带、使用方便”。写2万个字无非是生产者增加上的一个条件。但是当漏油的问题出来以后,“使用干净”也会成为这个使用上的一个需求,而解决这个需求在改善钢珠质量无望的情况下,“偷工减料”也成为解决这个需求的一种方式。并且这个方式沿用至今。这个解决方案的关键也就是找到了,“写2万个字”并不在用户真正需求范围内。

2:用户的需求不只被购买力所限制

我们常常说用户的购买力问题,这个的确是限制需求的一个很大的条件,但并非是唯一的条件。任何商品的使用价值除了它自身可以影响以外,使用环境也是个重大的影响因素。当使用的满意度瓶颈并不在于产品本身的情况下,提升产品本身的性能和解决用户需求的关系也就不大了。

如果出现这样的问题,那么产品本身对用户需求的提升空间会和其本身性能有一条曲线,而所发布产品的性能超过折点一些(一些,而不是很多)往往是产品性能确定的最好位置。这一个是考虑考虑时间的影响,二是各个产品的信息往往是相互关联的,没有一个产品性能的提升,对于整个产品链并非是好事情。三是:这一点的提升往往是一个非常大的盈利空间,而过多部分的提升对于盈利的帮助什小。

古代的时候,边报是采用800里加急的方式传递的。传递军事信息也采用过狼烟和烽火的方式。这样的信息传递速度,甚至比我们的快递并不慢多少。在古代却没有用在民用上。甚至普通的公文都没有采用这样的传递方式。

在古代的信息处理上讲,除了告急边报,其他的信息都没有必要用这么快的速度。如果某些地方发生问题,处理的人到场的时间是信息传递的一个很重要的限制。某地出现问题。朝廷反映的时间就很长。处理方案,人员组织,物资调拨和实施的时间要在30天以上。那么这信息传递上的时间差一天半天,对于行动是否成功产生的影响并不大。(采用信鸽的速度并不会比快马快多少,而且有丢失的风险)。

3:多于用户需求的成本无效

在设计中,由于用户的需求找的不准确,常常存在用户可能要**,**功能最好作上吧!我们实现**功能吧,用户最终会需要的。于是不得不去开发N多我们不知道是否该上的功能,这些功能除了给信息构架的工作带来N多问题以外,更关键的是用户不会为我们增加的这部分的运营成本买单。

我们都有发现自己预算1000,最后却花了1200甚至更多的情况。单这个仅仅限于我们的在销售人员的引导下,发现自己其实是有**的需求的,并且愿意为这个需求付钱的情况。在电子商务网站中,提升客单价的功能就是体现,和销售人员的引导一样。

铱星系统可以作为这个的一个反例,keso把铱星系统的失败归结为超过了消费能力,但在我看,铱星系统失败的原因很多,其中一个就是铱星系统没有找准用户的需求,作了很多用户不需要的功能。在非洲某个国家里面的某个地点的通讯和我有什么关系,甚至中国新疆某个地点的通讯和我有关系吗?那么凭什么要我为铱星这些我用不到的功能付钱。

这篇文章被编辑了 2 次. 最近一次更新是在 2010-01-21 16:02:56

[Email]
 
论坛首页 »项目开发» 软件工程
前往:   
Powered by JForum 2.1.8 © JForum Team Template: Trydone