对于产品经理来说，大多数的日常都是围绕需求展开的——沟通需求、实现需求等。那么对于需求这一内容，如果做好正确理解，相信会对后续实现提供很大帮助。
接着上一篇《需求方法论（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. 将解决方案代入场景进行验证与反推需求
完整的场景验证应该是，角色代入到我的解决方案里，然后进行模拟
从用户进入商城，有哪些入口可以看到这些商品？看到时可能有哪些不同的想法？然后购买，一件甚至多件（赠送亲戚朋友），购买之后可能多久去核销？商家怎么核销？核销之后评价，等等都是需要进行验证的。
4. 对需求进行优先级排序
因为这个需求是公司明确表示需要马上实施的，所以我将他们的方案进行切割，并且我进行一些修改后，分解了一堆小需求，然后讨论，分别进行优先级排序。
以上就是我的需求方法论的全部内容了，如果有不足之处，还请大佬指出一起讨论。
本文由 @橘钻 原创发布于人人都是产品经理，未经作者许可，禁止转载。
题图来自Unsplash，基于CC0协议。