当前位置:首页 > 天道酬勤 > 正文内容

一卷搞定四上英语听力(一卷搞定四上数学)

张世龙2021年12月20日 04:01天道酬勤860

编辑指南:产品制作离不开需求的分析整理。 面对巨大的需求时,如何面对,如何应对,如何提取真正的需求作为制作产品的核心链条? 本文从需求分析的定义出发,教导我们分四个阶段解决需求分析的关键节点。 一起看看吧。

做这个需求还是不做? 这是产品经理日常应该做的选择。

每天都来自不同的地方,我甚至不知道什么时候会来,但我知道需求一定会来。

那么,如何判断需求是否值得做呢? 这将成为需求分析。 可以看出,需求分析也是一项基本功。

今天我们来谈谈需求分析。 我想给大家一些启发。

一、什么是需求分析

需求分析又称软件需求分析、系统需求分析或需求分析工程等,是开发者经过详细的调查和分析,准确了解用户和项目的功能、性能、可靠性等具体要求,将用户的非形式需求表达转换为完整的需求定义,并进行系统化的

关于需求分析的说明中最重要的是前面最后一段“将用户的非形式需求表达转换为完整的需求定义并决定系统必须做什么的过程”。

这句话说明了几种情况:

第一,需求通常来自用户;第二,用户在表达需求时根据自己的习惯表达,不完整,隐含,需要产品经理深入分析和定义;第三,用户表达需求后,系统当然需求来源于用户,但有可能不直接来源于用户,有可能是通过业务部门转发的,也有可能是数据分析的。

事实上,日常产品经理在正式开始需求方案之前会进行需求分析,所以是常规技能。

其次,具体说明需求分析的三个步骤。 只有完成了所有三个步骤,才能视为一次性完全完成需求分析。

二、需求真实性的判断

的第一步是先判断需求的真实性,如果是不真实的需求,就不需要实际进行后续分析。

一个需求是否真实通常可以通过回答以下四个问题来判断。

用户是谁? 需求场景怎么样? 用户面临的问题是什么? 用户想要解决的实际需求是什么? 这四个问题对应的是用户、场景、挑战和目的,回答这四个问题是判断需求真实性的前提,如果不能表达前面的问题,就可以判断它不是真正的需求。

让我举个例子说明一下:

我知道有问题,但是淘宝下单后为什么不能更改送货地址?

让我们按照前面的问题框架来回答:

用户是谁? 在淘宝购买商品的用户。 需求场景怎么样? 填写或选择错了送货地址。 用户面临的问题是什么? 淘宝不能修改送货地址。 用户想要解决的实际需求是什么? 让购买的商品送到正确的地址。 因为非常清晰,所以对于填错地址的淘宝用户来说,需要修改送货地址是真正的需求。

再举一个例子:

耿曾做过一个东西,能让这个碗在地震发生的时候不翻,继续吃泡面。

让我们按照前面的问题框架来回答:

用户是谁? 我饿了,想吃泡面的人。 需求场景怎么样? 地震发生时正在吃泡面。 用户面临的问题是什么? 如果发生地震,必须避开危险。 用户想要解决的实际需求是什么? 保证自己的生命安全。 虽然大家没有注意到,但是在地震中用户的首要需求是确保自己的安全。 地震发生后,大地还在摇晃,谁也不想吃泡面。

所以无论用户还是场景,都存在吃泡面的需求,但如果不是第一需求,而是第一需求是安全的,那么解决方案当然是错误的。

注意:我在这里不是说判断需求的真伪,而是说需求的真实性。 我看了市面上很多用户的需求分析文章,说的是虚假需求的问题。 我认为他们大部分对需求的理解错了,或者需求的价值也进入了虚假需求之中。 我认为这是非常错误的。

有名的例子是大家想要更快的马的需求,福特把他解释为需要更快的速度来制造福特汽车。

请注意这个例子。 福特改变了解读的角度,接近了需求的本质,所以福特胜利了。 但是,这并不能说想要更快的马是虚假的需求。 想要更快的马也是真正的需求。 如果把这个时间拉到工业革命之前,以当时的技术水平还不能制造汽车,那不是真正的需求吗?

所以不要混淆不同的问题。 全部归类为虚拟需求是非常ljdy的做法。

三、需求价值的评定

需求真实性判断完毕后,需要判断需求的价值。 需求的价值大小由以下维度决定:

用户范围:这个需求的接受面有多大? 使用频率:此需求的使用频率是日/周/月周期吗? 必要性水平:这种需求对用户有多强烈? 生态影响:对平台其他参与者的影响。 产品时机:这个需求符合产品计划、当前环境吗? 还是用之前淘宝的例子说明一下——淘宝下单后为什么不能更改送货地址?

1. 用户广度

这个需求的接受面是多少?

虽然不知道具体的数据,但是应该有相当多的人遇到过这个问题。 假设为10%。

2. 使用频率

这个需求的使用频率是日/周/月周期吗?

频率一定很低。 几百次大概只有一两次。 频率大约每年一次

两次,这是从一般用户的角度来说,购买频次越高这个功能的使用频率也可能更大。

3. 刚需程度

该需求对用户有多强烈需要?

用户遇到这个问题的话当然是希望能够修改地址,但是没有这个功能好像负面也不是很大,可以客服联系商家修改,或者去送达的地方取一下货,对于大部分用户来说地址不是住的地方就是公司,有的时候换住址或者公司可能出错,但是去取一下也还行。

4. 生态影响

该需求对平台各方产生的影响是怎么样的?

对于购买用户来说其实不会因为这个问题就离开,毕竟和平台带来的便利性比较,这么一两次挫折不算什么。

对于商家来说,如果允许修改就会是个非常大的麻烦。

我们来具体分析一下:

如果允许用户修改会发生什么情况呢?

可能有两种情况,一种是商家发货了,一种是商家没发货。

发货了就不说了,修改也没用,因为货都在路上了,不可能更改地址,快递公司也没有这样的流程。

如果没发货那么可能会出现两种情况,一种是商家还没有备货,一种是已经备货提交快递单给快递公司了。

如果没有备货还好说,如果已经提交了快递单那就很麻烦了,修改数据是简单的,问题就是你需要把这个订单对应的货品找出来然后把快递单换一下,这个找的过程是很耗费商家时间的,因为有可能商家一天发几千件货,花时间更换地址就会导致发货效率降低,如果要保持效率就需要话更多的人工成本,这对商家来说肯定是不希望的,因为钱赚少了。

如果允许修改则商家每天都要处理这个事情,不友好程度就很高了,商家不会马上走但是可能会把重心迁移到其他平台,这样整个淘宝生态就慢慢变差了,这个肯定是淘宝难以承受的。

所以从生态的角度来说这个就是负向价值非常大的一个用户需求。

商业价值:该需求对于业绩的价值是怎么样的?

基本没有商业价值,因为改了之后并不会增加业绩。

产品时机:该需求是否符合产品的规划,当下的环境?这个倒是没所谓。

所以综合起来看这个需求的价值对于淘宝就是负面的,淘宝肯定不会做这个功能。

我在举例说明的时候用的都是定性的说明,如果想要做成定量的分析,那么可以给每一项做一个打分表,譬如1-10分,然后给每一项赋予不同的权重值,譬如都是20%,这个根据需要调整就是了,最后统计综合得分,根据综合得分判断需求价值。

判断需求价值是为了决定做不做的问题,如果需求价值不大甚至需求价值为负那就不用列入计划了。

四、需求优先级的评定

按照我们的经验来说,需求不可能只有一个,它们广泛的来自于领导、用户、业务部门和产品部门自身,所以有十几个或者几十个需求是很正常的,这个时候就涉及到对需求优先级的判定问题,公司的资源总是有限的,所以不可能所有需求都在第一时间投入资源,优先级的判定就是解决资源如何投入的问题。

1. 需求的优先级如何判定呢

对于优先级的判定主要是基于前面的需求价值和需求成本-指的是实现这个需求需要投入的资源,这就是一个衡量性价比的过程。

一般类似会把需求价值和需求成本分成低、中、高三等,交叉之后分为优先级最高、优先级次高、优先级一般和不做四个部分。如下图:

优先级最高一般划为P0和P1,优先级次高划为P2和P3,优先级一般就划为P4。

特别说一下,有些公司把优先级划的特别细,分成好多等级,其实没必要。太细了浪费时间分。

五、需求池管理

需求池的管理是最后一步,也是最重要的一步,把从各方收集来的需求、经过前面的分析之后筛选出来的需求汇集到一起,记录在册方便管理需求和后续的版本规划,也方便追溯产品方向的迭代。

需求池的基础信息主要包含:编号、模块、功能点、需求描述、场景描述、需求类型、优先级、提出人、提出时间、当前状态、备注。

编号:需求的唯一标识,编号的规则可以自行定义,最简单的就是日期+自增数,作用是作为每条需求的唯一编号和快速查询需求。

模块:根据产品模块去划分,作用是将需求统一归类到某个模块下,在进行版本规划时,可以优先从某个模块中筛选,同时便于根据模块查询。

功能点:简单描述需求的功能,也就是要做什么,这样我们快速查看某个需求时,能一眼看明白这个需求是要新增或修改哪个功能。

需求描述:需要描述清楚需求的完整性、一致性,需要精准的描述。如果产品经理在后续想不清楚这个需求到底要做什么,可以通过需求详细描述来回想或了解。

场景描述:了解用户在什么场景下产生的需求,在给开发转述为什么要增加这个需求时,可以清晰的说明是因为哪些原因,更能说服开发愿意做这个需求。

优先级:从P0-P4,优先级依次下降,优先级可以帮助产品经理在做版本规划时判断应该先做哪些需求。

开发量:需求的开发工作量,可以通过这个信息规划开发每个版本的工作内容,也方便我们了解每个需求的开发难度。

提出人:原需求的提出人,便于日后有疑问可追溯。

提出时间:需求的提出时间,方便我们了解是什么时间提出的需求,同时可以利用提出时间来规划需求的紧急程度。

产品对接人:具体是谁来负责对接和后续的产品设计,这个的话一开始没有可以空着。

状态:这个指的是需求的生命周期,待处理、设计中、开发中、已发布、暂缓(标注原因);主要作用是可以对需求的流转状态进行跟踪,可以了解需求在不同阶段的状态,发现问题及时调整。

备注:一些额外信息的记录。

需求类型主要包含:

新增功能:目前平台没有实现的功能;功能迭代:对目前平台已实现的功能进行优化;用户体验:例如页面按钮摆放的问题,发送消息时发送按钮放在右侧,可以按照用户的使用习惯设计;UI优化:如整体产品色调的调整等,这个需要根据平台调性去处理。

六、最后

需求分析其实不复杂,但是想要把握的准其实还是需要一些功力的,大家在做具体的需求方案之前不妨想一想这个需求是不是值得做。

公司资源有限,你的时间也有限,总要投入到那些能够产生更大价值的需求里面去。

而选择无疑是这个时代最重要的能力,那么在选择之前的分析就无疑是基石,多练练这个技能,或许不止对工作有帮助。

如果你选择做产品经理,那么祝你好运。

本文由 @代号hhdsb 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自 pexels,基于 CC0 协议

扫描二维码推送至手机访问。

版权声明:本文由花开半夏のブログ发布,如需转载请注明出处。

本文链接:https://www.zhangshilong.cn/work/25365.html

分享给朋友:

发表评论

访客

看不清,换一张

◎欢迎参与讨论,请在这里发表您的看法和观点。