对产品经理来说，大多数日常是以需求为中心展开的——交流需求、需求的实现等。 那么，关于需求这个内容，我相信如果正确理解的话，对之后的实现会有很大的帮助。

下一个《需求方法论（1）：需求的理解、来源、挖掘与记录》

你认为首先必须了解需求是什么吗？ 而且需求来自哪里？ 如何自己挖掘需求？ 需求来了该怎么记录呢？ 记录接下来该怎么分析呢？ 分析之后，该怎么验证呢？ 验证后如何排序？

所以我的需求方法论由七个部分组成。 了解需求、挖掘需求、记录需求、分析需求、验证需求、排定需求优先级。

本文是关于需求分析、验证和排序的。

一、需求的分析

需求分析的目的是这个需求做还是不做，所以必须分析这个需求的合理性。

1. 角色分析：这是谁提的需求？

领导者、运营团队还是用户？ 根据人所处的立场不同，他们提出需求的目的也不同。 正如前面所说，每个人说的话都是被自己的认知所左右的主观意识的表现，所以不要只看他们说的话，而要思考他们为什么要说这些话。 你受到自己立场的影响吗？

如果用户提到，则该用户是目标用户吗？ 你是重要用户还是普通用户？ 如果连提交人是什么都不知道的话，有可能会极大地影响以后的判断。

例如，通过订单数量，可以初步判断该用户是否为重度用户的订单平均价格，从而判断该用户的大致收入水平等。

正如

2. 目的分析：提出者是出于什么样的目的而提出？

前所述，时代变了，但需求没有变，变的只有需求的解决方案。 所以通过“通过显影看本质”，挖掘提交人最本质的需要。

所以需求还可以分为表面需求、本质需求、产品需求。 表面需求是别人提出的需求，本质需求是提交人的目的，产品需求是我们能提出的解决方案。

如果是用户提出的需求，普通用户喜欢直接提出解决方案，直接指出应该怎么办。 那么，他说的是虚拟需求吗？ 只有一小部分人满意，损害大多数人的体验吗？ 他提出的是最好的解决方案吗？ 不解决用户会有多痛苦？

如果是来自领导的需要，他有战略和商业上的考虑吗？ 他提出的是最好的选择吗？ 如上所述，公司的需求和用户的需求可能存在矛盾点，因此需要平衡这些矛盾点。

例如，如果阅读器试图在一个板块上安装另一个页面的导航广告弹匣，该弹匣会影响用户的操作体验吗？ 领导的目的可能是增加那个板块的流量，但是那个引导点是否添加到其他地方比较好。

如果有

3. 定位分析：这个需求和当前产品的定位有没有冲突？

，冲突会有多大？ 做这个功能看起来不相容吗？ 不会影响用户对产品的看法吗？ 有缩小这个冲突的方法吗？

4. 广度、频率分析：这和需求的接受程度怎么样？

最多可以覆盖多少目标用户？ 不会影响其他用户的使用体验吗？ 虽然并不是准确地涵盖人数，但有必要预想大概的比例。

有多少用户经常使用？ 有多少用户正在被普遍使用？ 这个经常被使用，频率一般需要怎么定义？

首先，请尝试预测每天、一周、一月使用该功能的频率。

5. 投入产出比分析：投入与产出合理吗？

能创造多少金钱价值？ 可以添加多少用户？ 可以激活多少用户？ 有长期利益吗？ 有预测大致的数据指标，对照该数据指标看看实现效果的方法吗？

需要投入多少钱？ 人力？ 时间？ 这里的投入只是粗略的估算，可能不准确。 由于没有具体的方案，显然投入太大，只能筛选出明显不合理的需求。

如果有能支持

6. 数据分析：有没有相应的数据来支撑？

分析的数据，那是最好的。 就是锦上添花。 毕竟，数据比人为的主观判断更客观。 如果没有的话，这个可以无视

7. 可行性分析：公司现有能提供的资源、团队的技术水平能支持实现吗？

为什么这一瓶放在最后而不是价值分析之前？ 从这个需求来看，因为现有的条件不能实现，所以可能没有必要进行今后的价值分析。

所以我在写现有的条件。 如果不支持现有条件，且需求确实有优势，则跟进。

二、需求的验证

为什么要验证需求？

需求来了以后我们往往凭感觉判断，有时不能理解这个需求，有可能导致误判。 此时，有必要提出初步的解决方案。 在提交的过程中更详细地分解需求，然后进行验证和反推。 此外，还可能对以前的需求分析结果进行一些修正。 例如，如果现在不能实现，可能必须降低优先顺序。

当然，如果是小需求，就没必要做这一步。

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

肯定：设计可以从正面解决用户需求并以流程图表示的初步解决方案

来。否定：让用户放弃这个想法，比如找一些替代方案，哪怕效果没那么好，后续再改善。

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

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

A. 主线流程：

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

这就是一个用户使用，基本、正常的主线流程。

B. 分支流程：

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

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

C. 可选流程：

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

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

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

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

D. 异常流程：

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

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

2. 场景验证与反推：通过场景来验证这个需求与解决方案

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

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

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

时间：这个功能对季节、一天内什么时候分享没有特定要求，所以可以略过；

地点：用户分享对所处位置也没有限制，也可以略过。

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

角色：希望是平台上的全体用户参加，越多越好；所以对商品的挑选就有要求，得大众化。

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

门槛是否会很高，需要很多人才能完成？（所以制定参与人数规则时是否能降低参加门槛，比如50元的商品，只需要5个人参加；或者出于成本的控制，挑选价格不太高的商品。）

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

我是否可以找一堆朋友天天来薅羊毛？（如果新老用户都可以参与，为了防止被薅只有在参与的次数上做限制；那让老用户参与的目的在哪呢，是促活吗？我们公司是一个创业公司，钱得花在钢刃上， 是否就限制成只有新用户才能参与呢。）

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

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

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

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

三、需求的排序

需求一窝蜂来了一堆之后，该怎么排序呢？如果仅凭感觉，可能会存在一定的误差。我认为可以通过紧急重要四象限法则来进行参考。

（网图，侵删）

那紧急和重要又是怎么来判断的呢？我的方法是通过以下几个维度来参考：

紧急程度：

任务：是否是公司指派的紧急任务，比如领导明确要求多久之前需要完成。类型：上面我在需求记录板块提到我将需求类型分为运营类需求、bug类需求、创意类需求、优化类需求；比如bug类就比较紧急，创意类需求就比较相对不那么紧急。

重要程度：

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

以上就是我所总结的关于需求分析的方法论了，下面我举一个从头到尾完整分析的例子。

八、举例

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

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

首先可以对上线“医疗服务”功能这个需求进行分析，比如上线这个功能能覆盖多少用户？得到多少回报？和产品定位相不相符合？

但因为是公司确定要做的需求，所以就将这个外部团队提供的这一整套方案看作是一个需求来进行分析。（所以需求的样式是多种多样的）

1. 需求分析

A. 角色、目的分析：

这个外部团队是方案的提供方，目的在于通过这么一个功能能为他们合作的线下医院引流。而公司领导愿意对接的原因在于，能丰富我们平台的商品，同时希望创造一定的价值。

B. 定位分析：

首先，我们是公益农副产品的商城，和医疗服务肯定是不搭边的；那么有没有办法能缩小定位上的差距呢？我和团队负责人聊了之后发现，他们是可以上线一些价格便宜的医疗服务，比如“1元的全面口腔检查”。其实这样性价比高的商品是可以进行一定包装的，可以和公益进行挂钩（但包装要把握尺度，不然就是在欺骗用户）。

C. 广度、频率分析：

像这样的功的广度频率主要得看上线的商品。如果是像“1元的全面口腔检查”这样的商品，是能和我平台的用户群体高度重合的。因为并不是像感冒药这样，生病感冒的时候才有需求去购买。但受到医院的地域限制，所以预计购买用户的占比可能就比较低；

而频率肯定就相当低了。

D. 回报分析：

能创造多少金钱价值？当时我们根据商品的价值和预计有多少用户购买（总用户人数*预计的比例），然后根据返佣比例，做了一个大致的估计；

能新增多少用户注册量？这个就确实不好估计了，因为这个需求就不是为了我们平台引流。

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

E. 投入分析：

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

F. 数据分析：

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

G. 可行性分析：

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

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

2. 提出初步的解决方案

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

所以我的想法是逆向解决，也就是先将他们的一整套方案先进行切割成小的且独立的板块，利用现有平台上能提供的功能对这些小版块分别满足；满足不了的再进行技术评估，如果时间成本懦弱的可乐就开发，时间成本大就先暂时搁置。

当然，也得和需求的提供方，也就是那个外部团队进行沟通、协调。

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

完整的场景验证应该是，角色代入到我的解决方案里，然后进行模拟

从用户进入商城，有哪些入口可以看到这些商品？看到时可能有哪些不同的想法？然后购买，一件甚至多件（赠送rydlf），购买之后可能多久去核销？商家怎么核销？核销之后评价，等等都是需要进行验证的。

4. 对需求进行优先级排序

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

以上就是我的需求方法论的全部内容了，如果有不足之处，还请大佬指出一起讨论。

本文由 @橘钻 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。