12 十二
2011
Posted in: 项目需求分析
By    2 Comments

需求分析之六大原则

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

1、需求分析第一个原则:永远不要显得比客户更聪明。
聪明反被聪明误,这样的事情太多了,我们产品经理都是有智慧的人,而不是耍小聪明的人。
2、原则第一点:了解需求,而不是去批评客户。
产品经理不是批评家,心理上要重视客户,行动上要尊重客户,平等对待每一个客户。
3、 原则第二点:客户比你更熟悉业务的环境。
产品经理熟悉的仅仅是产品本身,但是,产品经理要做的却不仅仅是产品本身。
4、原则第三点:真正的问题只有客户知 道,我们要做的就是让客户愿意说出来。
客户会给你反馈,但是这些反馈有些是真实的,有些是敷衍的,你希望真实还是敷衍,请参考原则第一点。

需求分析的六个原则(二)尊重用户的现实选择

1、需求分析第二个原则:尊重用户的现实 选择。
产品是客观的,用户是客观的,使用是客观的,需求也是客观的,一切都是现实的。
2、 原则第一点:客户永远是对的。
客户不是我们的敌人,客户不会害我们,客户提出的需求看似在为难我们,但本质上是为了让客户自己更好的使用产品,因此,客户不会为难自己。
3、 原则第二点:提供最合适的解决方案,而非最好或最贵的方案。
我们能够做的不一定是最好的,我们不想做的有时候往往是客户最需要的,找到最合适客户的,而不是最合适我们的。
4、 原则第三点:不要把客户当傻瓜。
这个世界上没有傻瓜,自以为对方是傻瓜的人才真的是傻瓜,不要忽悠客户,不要欺骗客户,如果非要在这个前面加上一个期限的话,我希望是“永远”。

需求分析的六个原则(三)转述需求的人也是客户

1、 需求分析第三个原则:第三方也是我们的客户。

只要是对我们的产品和业务提出需求,就是我们的客户,应该一视同仁。

2、原则第一点:第三方一般会把自己想象成设计者。

他们对产品或许很熟悉,但是对整个业务可能不熟悉,因此,他们成不了设计者。

3、原则第二点:第三方可能会遗漏或补充一些额外的需求。

每个人都期望产品能做好,这种强烈的成功心理容易让人们产生日晕心理,从而影响我们对需求的筛选。

4、原则第三点:对第三方的自由发挥不应抱怨和生气,而是将其视为客户。

客户是第一位的,而他们又是我们的客户,因此,我们应该心平气和的对待他们的想法,无论这些想法是出于公还是出于私的。

需求分析的六个原则(四)客户和用户要区别对待

1、需求分析第四个原则:客户和用户要区别对待。

客户是客户,用户是用户,有时候一致,有时候分离,这是我们首先要搞清楚的。

2、原则第一点:产品为最终用户设计,需求的功能转换为最终用户的使用要求而确定。

用户决定产品,我们需求工作基于用户,始于用户,归于用户。

3、原则第二点:为客户寻找价值上的需求。

客户是多样的,价值导向也是多样的,我们的产品能否承载多样化的客户价值决定了产品能否实现最终的交换。

4、原则第三点:用户的利益高于一切。

产品的最终价值是通过用户来体现的,脱离了用户的产品,就是“皮之不存,毛将焉附”。

需求分析的六个原则(五)用最简单的文字工具记录需求

1、需求分析第五个原则:用最简单的文字工具记录需求。

客户并不麻烦,需求也不复杂,麻烦的是我们把一切做的太复杂了。

2、原则第一点:所有人都能懂的东西,最不容易出错。

没有人喜欢复杂的东西,需求也不例外。

3、原则第二点:不需要再学习的东西,最不容易出错。

产品是需求的表现,没有人喜欢复杂的产品,要做到这一点,就从需求开始吧。

4、原则第三点:不要希望客户能花更多的时间来了解需求转换后的原型。

我费些事,客户就可以省些事,客户省事了,我们最终也就省事了。

5、原则第四点:保持沟通的通畅,是了解需求的保障

要实现需求的清清楚楚,就要做到沟通的反反复复。

需求分析的六个原则(六)天下没有免费的午餐

1、需求分析第六个原则:天下没有免费的午餐。

要得到就一定要付出,付出的量并不一定和得到的量相等,作为产品经理来说,就是要让客户尽量少的 付出,尽量多的得到,但永远不会是免费的。

2、原则第一点:客户从来没有不合理的需求。

客户的需求都是现实的,都是合理的,因为这些需求都是客观的,但我们通常习惯于用主观去看待客观。

3、原则第二点:客户的要求都是可以实现的。

没有不可以实现的需求,只有我们了解的不够深入的需求。

4、原则第三点:我们能做这事-这是所需的费用。

成本第一还是需求第一,客户把这个问题交给了我们,我们就用用我们的智慧去解决这个问题。

 

无觅相关文章插件,快速提升流量

|2|left|yes

2 Comments

  • 通过各种需求采集的方法,得到很多信息,接下来我们要做的自然就是需求分析了。

    听到过一个说法,说需求分析与技术分析的最大的不同是思路的本质差异,技术分析是“树干——树枝——树叶”的任务分解过程,技术人员很适应并乐于用这种方式思考,可以把大问题分解成小问题,发现难点逐一攻克。很多做需求的人都是开发出身的,所以开始往往会用这种思路做需求,听到客户提到的功能点,直接想怎么做系统设计了,有时候需求分析甚至已经越俎代庖到“详细设计”的职责了。而真实情况是,需求分析是“树叶——树枝——树干”的分析过程,一定不能漏掉提炼用户需求的这个过程。

    确实很有道理,后来仔细一想,其实另有两个问题值得继续思考补充在这个说法上。

    第一,这里玩了一个偷换概念,两者的“分析”定义不同,按照逻辑学的通俗定义,第一种分析是真正的分析,而第二种“分析”似乎更应该被称为“归纳”。可是,如果现在提出一个“需求归纳”的概念,连我自己都觉得拗口,所以继续用“需求分析”这个词。

    第二点更关键,“树叶——树枝——树干”的描述并不完整,它只是前半部分。其实完整的“需求分析”是一个先归纳后分析的过程,试想如果做到“树干”就结束,后端的开发人员还是不知道要做什么东西,所以我们还要继续把树干再次重新分解成树枝、树叶。

    小结一下,需求分析的目的是把从客户那里收集到的“用户需求(更接近Want,有时候甚至是解决方案,但我们不能不假思考的照做)”做归纳,然后得到一个总体概念(用户的Need,真正的欲望所在)后再分析、分解为“产品需求(给出我们的解决方案)”。

    举个例子结束:小明说要吃肥牛火锅(18元,iamsujie补:涨到20+了),我们分析认为他是饿了,不是馋了或者真的想吃牛肉,最后给出我们的方案,扔给他2个馒头(0.5元*2),结果他虽然眉头一皱,但考虑到性价比(省了94.4%的成本啊!他省的多我们的利润空间也会大些),还是很愉快的吃了……

    伟大的需求分析师。

  • 软件需求包括三个不同的层次:业务需求、用户需求和功能需求(也包括非功能需求).
    1.业务需求(business requirement)反映了组织机构或客户对系统、产品高层次的目标要求,它们在项目视图与范围文档中予以说明.
    2.用户需求(user requirement) 文档描述了用户使用产品必须要完成的任务,这在使用实例(use case)文档或方案脚本说明中予以说明.
    3.功能需求(functional requirement)定义了开发人员必须实现的软件功能,使得用户能完成他们的任务,从而满足了业务需求.

So, what do you think?

使用新浪微博登陆