本节试图从一个简单的“用户自助寄件”案例出发,分析业务需求、用户需求、功能需求之间的关系和差异,以及如何进行需求的分析和转化。
在产品的需求里面,经常有这三个概念:业务需求、用户需求、功能需求,但往往,我们很容易搞混,不清楚他们之间的关系和差异,我们先引用一下比较官方的解释:
业务需求( Business requirement )表示组织或客户高层次的目标。业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求描述了组织为什么要开发一个系统,即组织希望达到的目标。
用户需求( user requirement )描述的是用户的目标,或用户要求系统必须能完成的任务。用例、场景描述和事件――响应表都是表达用户需求的有效途径。也就是说用户需求描述了用户能使用系统来做些什么。
功能需求( functional requirement )规定开发人员必须在产品中实现的软件功能,用户利用这些功能来完成任务,满足业务需求
这个解释其实还是蛮明确的,其实理解这三者的关键点,是要先认清楚每个需求针对的对象不一样:
业务需求———对应的是组织或者客户,实质就是业务的建设方;你也可以类比房地产市场的开发商;用户需求———对应的是使用产品的用户;你也可以类比买房的人;功能需求———对应的是产品,即产品要具备怎样的功能,才能满足相应的业务需求和用户需求;类比房地产市场,那就是房子本身。
类比成房地产三个角色后,你发现,开发商通常的诉求是想多赚钱,买房的人诉求是买到物有所值,甚至物超所值的房子;但不管二者怎么想,最终都是需要通过房子来实现,必须建设的房子的属性达到某个标准才能满足二者的诉求;
所以,这么一看,你就明白了,其实这三者之间的关系是:
即,业务需求和用户需求,只有经过需求分析的转化,变成产品的功能需求后,才能得到实现。
需求实例
接下来,我们用一个简单的实例来进行说明:
案例:用户自助寄件的需求
业务建设方:某快递公司
需求描述:目前很多城市的小区都已经有了快递柜,但快递柜主要是用于送件使用,而对于快递公司收件,用得比较少,某快递公司,就希望利用快递柜,来实现用户自助寄件的需求。
首先,我们来分析其业务需求
这个案例的业务建设方是:快递公司,其业务需求也很明确,就是:用户自助寄件。
业务方之所以要建设这个需求,其目的是:希望利用快递柜,实现更高效的收件服务,减少人工上门收件的等待、低效、人力投入成本高等问题。
其次,我们来看用户需求
这个案例的用户,就是每一个要寄快递的人,那么他们的需求是什么了?
他们的需求,其实就是在进行“自助寄件”的过程中,你尽量让我简单、易用,高效、快捷。
接下来,我们进行需求分析的转化
需求分析的转化,核心是两个点,一是对这个业务的场景进行充分的理解和认知,二是想明白业务场景中需求点,要通过何种方式来满足它。
业务需求是“用户自助寄件”,这个业务要实现,我们结合寄快递的实际场景,其实还是蛮容易就能想到,有3个关键环节:
用户要填写单据:即填写收发件人的相关信息;用户要能找到周边的快递柜,并且能打开它;还需要进行计量、支付快递费的问题
这三个环节,基本把这个业务的三个关键阶段说明出来了,它就是:填单——>找柜子放件——>支付。
然后,逐一对三个阶段进行具体的分析:
填单阶段:
业务方需求:必须收件人、联系电话、寄件人信息清楚、明确等等。用户需求:能选的就选,能简单填写的就简单填。
转化为功能需求,你发现,无非是通过表单形式让用户把相关信息填上来,而为了满足用户需求,你肯定需要设计对收件人的记忆功能,让用户填写一次,后续每次只需要选择而已(相关的细节还很多,这里只做举例)。
找柜子放件阶段:
业务需求:把最方便最合适的柜子告诉用户,并确保用户能安全、准确的找到快递柜、放入快递件;用户需求:我就想知道我要把快递件放到哪里,别让我多走;
这个业务需求和用户需求说起来简单,转化成功能需求时,其实里面还蛮多细节的:
位置服务肯定需要,一是为满足发现柜子的需求,二是也有导航的需求;如何打开柜子呢?从我们的产品经验或者竞品参考来看,可以有扫描开启、验证码等方式;如何保证用户去到快递柜,一定就有其空的柜子可以给他放了,这里面就涉及一个快递柜忙闲资源的管理;
所以,这里转化为功能需求时,你发现:有位置服务功能、扫描开启/验证码开启功能,柜子资源分配管理功能等;
支付阶段:
业务需求:根据收费标准,准确无误、及时收到用户快递费。用户需求:支付方便。功能需求: 如何来计量,由于是自助寄件,称重显然不合适,那么按体积是一种较简便的方式,而如何按体积了,其实根据可快递柜的柜子;如何支付,这个还简单,可以使用比较常用的几种支付方式就好;
以上,都只是简单的需求分析和转化的过程,实际的需求过程中,我们经常讲需要结合业务场景、用户场景把一些关键细节挖掘出来,并能在产品设计时考虑进去,以给用户一个良好的体验。
业务场景细节的挖掘
比如:在上面的开启柜子的方式中,到底用扫描开启还是验证码的方式呢?
其实用“验证码开启”会更合适,因为会存在很多这样的场景,某个寄快递的人,刚好家里有人下楼,或者认识的邻居下楼,而快递柜就在小区门口,那么找人代劳一下放件是一种很正常的事情,那么这时候,使用验证码就是一种最合适、简便的方式。
又比如:某用户希望自己的快递能更快的被寄出去。
那么,如果在给用户呈现周边分布的快递柜的同时,还告诉用户,该快递柜的收件时间,目前快递员的分布位置,是不是能让用户更好的去选择呢。
这样的细节还很多,需要在实际分析中,更好的去理解用户场景、挖掘细节,并逐步的完善。
通过上面的分析,我们发现,只要你充分认清楚业务需求方的诉求、用户在执行具体任务时的诉求,并对产品的常规实现方式有了解的话,需求分析并不是一个多复杂的过程,就是这么一步步去推理、去转化的过程。
而要把每个细节做透,就必须在实际中多去磨练,在生活中多体验,学会场景化的思维方式。
转自:/pmd/587994.html