需求方法论(2):需求的分析、验证与排序

对于产品经理来说,大多数的曰常都是围绕需qiú展开的——沟通需qiú、实现需qiú等。那么对于需qiú这一内容,如果做好正确理解,相信会对后续实现X很大帮助。

接着上一篇《需qiú方fǎ论(1):需qiú的理解、来源、挖掘与记录》

我认为得先理解需qiú是什么?然后需qiú会从哪些地方来?如果自己挖掘需qiú该怎么做?需qiú来了之后该怎么记录?记录以后该怎么进行分析?分析之后该怎么进行验证?验证之后怎么进行排序?

所以我的需qiú方fǎ论由七个部分组成:需qiú的理解需qiú的来源需qiú的挖掘需qiú的记录需qiú的分析需qiú的验证需qiú的优先级排序

这篇文章是关于需qiú的分析、验证与排序。

一、需qiú的分析

需qiú分析的目的在于这个需qiú做不做,所以得分析这个需qiú的合理性。

1. 角sè分析:这是谁提的需qiú?

X运营团队、还是用户?不同人站的立场不同,他们提出需qiú的目的也就不同。前面也提到过,每个人说出的话语都是受到自己认知所左右的主观意识的表达,所以不能光看他们说的话,还得去想为什么他们会说出这些话?是否受到自己所在立场的影响?

如果是用户提的,那这个用户是否是目标用户?是重度使用的用户还是一般用户?如果连提出者是什么身份都没搞清楚的话有可能会大大影响后面的判断。

举例:比如X订单数量可以初步判断该用户是否是重度用户;X订单均价可以判断该用户大概的收入层级,等等。

2. 目的分析:提出者是出于什么样的目的而提出?

前面提到过,时代虽然变了,但是需qiú没变,变的只有需qiú的解决方案。所以得“透过显像看本质”,挖掘提出者最本质的需qiú。

所以需qiú又可以分为:表面需qiú本质需qiú产品需qiú。表面需qiú就是他人提出的需qiú,本质需qiú就是提出者的目的,产品需qiú就是我们能给出的解决方案。

如果是用户提出的需qiú,一般用户喜欢直接给出解决方案,会直接指出他觉得应该怎么做。那么,他提的是不是伪需qiú?是否只能满足一小部分人,而会损害大部分人的体验?他提出的就是最好的解决方案吗?如果不解决用户会有多痛苦?

如果是X提出的需qiú,他是出于战略、商业上的考量?他提出的就是最jiā选择吗?前面提到过,X需qiú和用户需qiú可能是存在矛盾点的,所以需要平衡这些矛盾点。

举例:比如X想要在某一板块加上另一页面的引导广告弹窗,那这个弹窗是否会影响到用户的cāo作体验?可能X的目的在于为那个板块增加liú量,那引导点是否加在其他地方会更好。

3. 定位分析:这个需qiú和当前产品的定位有没有X?

如果有,X有多大?做了这个功能后会显得格格不入吗?会不会影响用户对产品的看fǎ?有没有办fǎ缩小这个X?

4. 广度、频率分析:这和需qiú的接受程度怎么样?

最多能覆盖多少目标用户?会不会影响其他用户的使用体验?并不是要精确的覆盖人数,但是需要预想一下大概的比例。

预计有多少用户会经常使用?多少用户使用频率一般?而这个经常使用和频率一般又需要怎样来定义?

可以先预想一下,大概有多少用户,他们每天、一周、一月使用这个功能的频率。

5. 投入产出比分析:投入与产出合理吗?

能创造多少金钱价值?能新增多少用户量?能促活多少用户?是否有长期收益?有没有办fǎ能X出大概的数据指标,并对照这个数据指标可以来看实现的效果。

大概需要投入多少金钱?人力?时间?这里的投入是一个大概的估计,可能并不准确,因为没有具体的方案,只能筛选一些明显投入过大,明显不合理的需qiú。

6. 数据分析:有没有相应的数据来支撑?

如果有相应的数据能支持分析那最好,就是锦上添huā,毕竟数据比人为主观判断更客观一些。如果没有,这一条也可以略过

7. 可行性分析:X现有能X的资源、团队的技术水平能支持实现吗?

为什么这一条我放在了最后而不是价值分析前面?可能这个需qiú一看,现有条件就实现不了,就不用进行后面的价值分析了啊。

所以我写的是现有条件,如果现有条件不支持,而需qiú确实有好处,那就后续跟进。

二、需qiú的验证

为什么要验证需qiú?

需qiú来了之后很多时候我们都是靠感觉来判断,可能会出现对这个需qiú理解不到位的情况,造成一些误判。这时就需要提出一个初步的解决方案,提出的过程中会更详细地chāi解需qiú,然后再进行验证与反推,甚至可能会对之前需qiú分析出来的结果进行一些矫正,比如现在没fǎ实现,那这时可能就得降低优先级。

当然,如果是一些小需qiú就没必要进行这一步了

1. 提出基本的解决方案:可以从正反两个方向的思路来进行思考

  1. 肯定:正面解决用户的需qiú,设计一套初步的解决方案,可以用liú程图展示出来。
  2. 否定:让用户放弃这个想fǎ,比如找一些替代方案,哪怕效果没那么好,后续再改善。

需要注意的是,设计解决方案的时候各种场景、各种liú程都要想清楚:正常主线liú程、各种分支liú程、各种可选liú程、各种异常liú程。只有把各种liú程想清楚了,才能对需qiú做出相对准确的判断。

举例:下图是我之前写的一篇文章《从0到1构建电商平台之订单系统(2):支付订单》”里的一个liú程图,画的就是在客户端的支付订单这个页面里的一系列后端判断。我就以这个liú程图来举例。(图有一些地方不一样,在那篇文章中有说明)

A. 主线liú程:

首先在提交订单页面成功提交订单后,订单生成,并进入支付页面,此时就会锁定库存;然后支付订单时会判断该商品的商品状态是否正常、sku信息是否更改;都没问题时就会由用户输入支付密码,支付成功就会生成一个待发货订单,然后订单发货之后就会扣除库存。

这就是一个用户使用,基本、正常的主线liú程。

B. 分支liú程:

比如图中的,当订单中有商品处于下架状态时、sku信息更改了时就会自动取消订单,并给与提示;当未成功支付时就会生成待X订单,过了N分钟之后还不能支付成功,就自动取消订单并释放库存。

这些就是主线liú程上可能存在的分支liú程。

C. 可选liú程:

可选liú程的意思就是质疑自己,当前做出的主线liú程是否是最好的,有没有更好的解决方案?

比如锁定库存,我设计的是提交订单即锁库存,那是否能支付成功才锁库存呢?

比如用户提交订单之后,订单处于待X时,我设计的是商家能下架商品,那不能下架呢?

每个方案都有利有弊,得综合考量之后再看选择哪个方案,甚至可以灵活配置;比如添加商品时就可以选择该商品是提交订单还是支付成功时锁库存。

D. 异常liú程:

异常liú程就是查看每一步是否会存在哪些风险。这个风险不是指liú程上的风险,如果是liú程上的风险就可以放到支线liú程里;比如支付订单时商家下架了该商品。

而是指外在的一些风险,比如一定数量的用户在同一时间提交订单时,峰值是否会造成X器崩溃的情况?如果对接了第三方库存管理系统,会不会出现在锁定、扣除商品库存不及时,造成用户超拍的情况?

2. 场景验证与反推:X场景来验证这个需qiú与解决方案

什么叫场景验证,说白了就是讲一段故事,有人物X地点动作等元素,X这段故事来验证这个解决方案有没有问题:具体的liú程上有问题整个解决方案有问题还是倒推需qiú有问题在产品设计时有什么需要注意的地方

和前面的需qiú的挖掘一样,场景验证需要先设置角sè、场景,设定好了之后代入进解决方案里;可以以多种角sè匹配不同的场景来代入,可能会发现不一样的问题。

举例:我这次就举一个以前做的名为“X送礼”的功能。初步的解决方案是,X人员挑选一部分商品到“X送礼”这个区域,用户在这个区域中有看中的商品时,就可以分享给朋友,朋友可以点开链接并参与,不管这个朋友是否是注册过,当参与的人数足够之后,就可以随机X了。

时间:这个功能对季节、一天内什么时候分享没有特定要qiú,所以可以略过;

地点:用户分享对所处位置也没有X,也可以略过。

(前面提到过,时间地点这两个因素对电商来说影响不大,经常可以忽略,但是对像美团、共享单车这样的产品影响就相当大)

角sè:希望是平台上的全体用户参加,越多越好;所以对商品的挑选就有要qiú,得大众化。

我是一个较少使用电商平台的用户,当我进入“X送礼”这个版块时,我的第一反应可能是带有疑虑的,会不会是骗人的?(所以在页面首屏的banner上是否应该将规则简短的说清楚,并且X从众心理,在页面上加上当前已有多少人成功X商品。)

门槛是否会很高,需要很多人才能完成?(所以制定参与人数规则时是否能降低参加门槛,比如50元的商品,只需要5个人参加;或者出于成本的X,挑选X不太高的商品。)

我发现我感兴趣的商品很少甚至没有怎么办?(所以初步方案中的由X人员挑选的商品才能进行分享这一规则,是否能改为商城内所有商品或除一部分特殊商品以外的商品都能分享?发现没有,如果要解决这个问题,就要从头改很多liú程和功能的逻辑。)

我是否可以找一堆朋友天天来薅羊máo?(如果新老用户都可以参与,为了防止被薅只有在参与的次数上做X;那让老用户参与的目的在哪呢,是促活吗?我们X是一个创业X,钱得huā在钢刃上, 是否就X成只有新用户才能参与呢。)

完整的分析还有很多,这里我就不一一列举了。

总结,上面X场景验证可以发现,是不是骗人的这个是产品页面设计中要注意的问题;门槛是否会很高这个是制定具体规则需要注意的问题;感兴趣的商品少这个就是整个解决方案可能存在问题;防止薅羊máo这个是具体的liú程上有问题。

所以X具体的场景验证可以反推出一些可能存在的问题和需要注意的事项,只有提前把这些问题推演出来。如果一开始就没发现这些问题,后面的需qiú排序,产品设计等步骤可能会存在较大的误差,甚至是在做无用功。

因为你不能排除,把产品设计做好之后再来,场景推演的时候发现该需qiú是个伪需qiú,导致浪费时间做原型的情况,或者在设计原型时不断发现之前本该发现的漏洞,原型不断地X重来;也不能排除因为之前考虑不够周全漏掉很X况,可能该排二级却排成了一级。

三、需qiú的排序

需qiú一窝蜂来了一堆之后,该怎么排序呢?如果仅凭感觉,可能会存在一定的误差。我认为可以X紧急重要四象限fǎ则来进行参考。

(网图,侵册刂)

那紧急和重要又是怎么来判断的呢?我的方fǎ是X以下几个维度来参考:

紧急程度:

  1. 任务:是否是X指派的紧急任务,比如X明确要qiú多久之前需要完成。
  2. 类型:上面我在需qiú记录板块提到我将需qiú类型分为运营类需qiú、bug类需qiú、创意类需qiú、优化类需qiú;比如bug类就比较紧急,创意类需qiú就比较相对不那么紧急。

重要程度:

  1. 定位:与企业的战略定位,与产品的定位之间的相关程度。
  2. 价值:价值就是前面提到的广度、频率、投入、产出等维度。

以上就是我所总结的关于需qiú分析的方fǎ论了,下面我举一个从头到尾完整分析的例子。

八、举例

这是前年做过的一个功能,现在已下线了。

当时X给了我一个需qiú,有一个外部团队将要在我们商城内上线“XX”的功能,也就是有一些医院将作为商家在商城发布商品。商品主要是类似美团的团购券,用户X后可以去相应的医院享受X后核销。而外部团队会给出我一套具体方案,由我评审X行开发。

首先可以对上线“XX”功能这个需qiú进行分析,比如上线这个功能能覆盖多少用户?得到多少回报?和产品定位相不相符合?

但因为是X确定要做的需qiú,所以就将这个外部团队X的这一整套方案看作是一个需qiú来进行分析。(所以需qiú的样式是多种多样的)

1.  需qiú分析

A. 角sè、目的分析:

这个外部团队是方案的X方,目的在于X这么一个功能能为他们合作的线下医院引liú。而XX愿意对接的原因在于,能丰富我们平台的商品,同时希望创造一定的价值。

B. 定位分析:

首先,我们是公益农副产品的商城,和XX肯定是不搭边的;那么有没有办fǎ能缩小定位上的差距呢?我和团队负责人聊了之后发现,他们是可以上线一些X便宜的XX,比如“1元的全面口腔X”。其实这样性价比高的商品是可以进行一定包装的,可以和公益进行挂钩(但包装要把握尺度,不然就是在X用户)。

C. 广度、频率分析:

像这样的功的广度频率主要得看上线的商品。如果是像“1元的全面口腔X”这样的商品,是能和我平台的用户X高度重合的。因为并不是像感冒yào这样,生病感冒的时候才有需qiú去X。但受到医院的地域X,所以预计X用户的占比可能就比较低;

而频率肯定就相当低了。

D. 回报分析:

能创造多少金钱价值?当时我们根据商品的价值和预计有多少用户X(总用户人数*预计的比例),然后根据返佣比例,做了一个大致的估计;

能新增多少用户注册量?这个就确实不好估计了,因为这个需qiú就不是为了我们平台引liú。

长期收益不光看这个功能带来的收益,如果和这个团队合作得可以,以后可能会有一些资源互换,更多的商业价值。

E. 投入分析

这些线下医院的对接是外部团队进行,这部分投入就不需要我们负担,我们只需投入人力进行开发;如果按照他们X的方案,我们大概需要三周的开发时间。投入产出比预期的比值是合理的,投入小风险小

F. 数据分析:

我们平台没有相关数据;但是可以从美团这样的平台上X此类商品的X量来做一个预估。

G. 可行性分析:

他们提出的方案仅仅是X层的功能,还得考虑用户X之后,商家核销券这一支持层的功能,这些是客户端上的;还得考虑管理X、商家X里缺失的功能。

所以我们是否能找一些替代方案来解决呢?

2. 提出初步的解决方案

如果正向解决他们的需qiú,就是对他们的方案直接开发,平台上缺失的功能也直接开发;但我们并不知道用户对这个需qiú的接受程度。那我们是否可以用一些替代方案,先快速上到商城,有了数据之后再来考虑后续的迭代呢?

所以我的想fǎ是逆向解决,也就是先将他们的一整套方案先进行切gē成小的且X的板块,X现有平台上能X的功能对这些小版块分别满足;满足不了的再进行技术评估,如果时间成本小那就开发,时间成本大就先暂时搁置。

当然,也得和需qiú的X方,也就是那个外部团队进行沟通、协调。

3. 将解决方案代入场景进行验证与反推需qiú

完整的场景验证应该是,角sè代入到我的解决方案里,然X行模拟

从用户进入商城,有哪些入口可以看到这些商品?看到时可能有哪些不同的想fǎ?然后X,一件甚至多件(赠送qīn戚朋友),X之后可能多久去核销?商家怎么核销?核销之后评价,等等都是需要进行验证的。

4. 对需qiú进行优先级排序

因为这个需qiú是X明确表示需要马上实施的,所以我将他们的方案进行切gē,并且我进行一些修改后,分解了一堆小需qiú,然后讨论,分别进行优先级排序。

以上就是我的需qiú方fǎ论的全部内容了,如果有不足之处,还请大佬指出一起讨论。

收藏 (0) 打赏

以上内容不错,打赏支持一下!

打开微信/支付宝扫一扫,即可进行扫码打赏哦,分享从这里开始,精彩与您同在
点赞 (0)

声明:本站所有教程资源,如无特殊说明或标注,均为本站原创发布。任何个人或组织,在未征得本站同意时,禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益,可联系我们进行处理。

雄发创业网 自媒体是如何赚钱的 需求方法论(2):需求的分析、验证与排序 https://www.xiongfawang.com/3353.html

常见问题

相关文章

需求方法论(2):需求的分析、验证与排序-海报

分享本文封面