一个需求经过大脑，大脑对其作出判断，整个过程不过一瞬。笔者将这个过程具象到书面，对其进行了总结，借用文中的方法对需求进行评估，希望对产品人有一定的启发和帮助。

需求分析，是产品设计的前置过程。

由于产品经理身处于沟通的中心，我们需要在很短的时间内评估需求的价值，并给出解决方案。

一个需求会在产品经理的脑海里经过什么过程呢？本文将从需求的分析、拆解以及优先级评估这三个维度分享一些方法，希望能够给大家带来一些启发。

一、需求分析的方法

1. 基础元素分析法

图1-需求的基础元素

第一个方法从需求的完整度出发，目标是挖掘真正需求。

一个完整的需求至少需要包含图1中的4个元素，分别是：

1.1 需求的背景

需求的背景指的是动机，这一项实质上是换位思考，它能够帮助我们从业务方的角度，从使用场景、用户心理去理解需求。

在实际工作中，我们所接收到的“需求”常常是表述不清晰的、不完整的，甚至是具有欺骗性的。

一个问题会对应许多的解决方案，找到真正的需求，也正是我们的职责。

1.2 需求的受众

需求的受众需要注意的问题有两点：

1. 谁是真正的受众；
2. 受众人群是否具有代表性。

需求的来源很多，可能是用户、业务方等。我们需要分清楚谁才是真正的受众。

在一个需求里不同的角色认知和诉求是不同的，当信息带上了主观判断也就被污染了。

其次，则是覆盖度的问题。对于频次不够高或者人群不够有代表性的需求，投入产出比会是一个大大的问号。辨清受众，在评估需求的优先级和制定解决方案时，迷惑性会大大降低。

1.3 需求的目的

需求的目的指需要做什么，很多时候我们接到的“需求”其实是业务方过滤后的“解决方案”。

以“口渴”为例，此时业务方提出的需求是要制作一台饮水机，然而饮水机并不能解决问题。如果我们挖掘到背后的动机是“口渴”，那么我们可以从补充水分和减少水分的流失来着手提供解决方案。

1.4 需求的目标

在汉语辞典里的解释，目的是期望，而目标是成果。

目标更为具象，并且能够用数据指标来衡量，后续也能够指导需求的改进。

需求的本质是为了创造价值，而创造价值最直白的则是开源和节流。具象到目标，可以用创造的收益，提升的效率以及节省的资源等方面进行量化。

2. 因果关系分析法

当需求具有上述的4个要素，下一步则是分析逻辑是否足够严密，在这里我们可以使用因果关系分析法。

图2-需求目的的推导

图2用因果关系表述：“因为某用户的某个原因，所以希望做某事。”

通过穷举法获得更多的因果关系类型，如图3所示：

图3-因果关系类型

穷举完毕后，我们开始对因果关系进行辩证：

• 原因是否真实？
• 这个原因一定会引起这个结果吗？
• 这个结果，是否还有其他的原因导致？
• ……

前阵子恰好收到一个典型的“需求”：

“因为APP注册页面改版了，导致注册数据下降，所以要优化APP注册页面。”

将这个例子代入上述的3个问题：

1. APP注册页面是否改版？答：改版了。
2. APP注册页面改版一定会导致注册数据下降吗？答：不一定，只能回答有可能。
3. 注册数据下降，优化APP注册页面一定有作用吗？答：不一定，只能回答有可能。
4. 注册数据下降有没有别的原因导致？答：渠道推广减少、投放的渠道匹配度不高、平台老带新活动减少等。

经过这样的分析，我们会发现这个需求的逻辑存在问题，业务方将相关关系转换为了因果关系，将关联原因转换为了直接原因。

对于多种原因导致的结果，数学中会使用多元回归分析来发现问题。只着眼于一点，这样的需求就非常经不起推敲了。

3. 公式法

明辨了因果之后，我们开始进一步细化。

假设上文所述的注册人数下降仅受APP改版影响，可以绘制出用户在下载后注册和登录的访问路径，如图4所示：

图4-用户路径

方法也非常简单，通过时间顺序绘制用户每一步的操作即可。绘制完毕后我们发现，影响注册数据原因可能是因为下载之前的流量降低，或者是后续环节的流失率增加。

在这里我们将抽象的需求转换为具象的公式，根据公式优化每一环节的数据指标。

根据图4，我们可以列出如下的公式：

• APP注册人数=手机号注册人数+微信注册人数
• 微信注册人数=进入注册页面人数-进入注册页面人数*跳失率-登录人数-点击手机号登录注册人数
• 手机号注册人数=进入注册页面人数-进入注册页面人数*跳失率-登录人数-点击微信登录注册人数-进入手机号登录页面人数*跳失率-选择切换登录方式人数-输入手机号未获取验证码人数-输入验证码未登录人数

罗列公式并代入近期的数据进行对比，就能够发现是哪个环节的数据指标下降了，优化那个数据指标也正是我们的需求。

二、需求的拆解

当明确了我们的需求知道要做什么，下一步则是对需求的拆解，从而建立产品设计的框架，这个环节我推荐的是UML拆解法。

UML（Unified Modeling Language）其中文的翻译是统一建模语言，这种方法主要运用于系统设计。这是一种非常好的解构方法，能够帮助我们在产品设计时逻辑更为清晰、全面（对这种方法有兴趣的朋友可以阅读相关的书籍，在这里仅做进行简单介绍）。

1. 用例图

图5-用例图

用例图（Use Case Diagram）是显示一组用例、参与者及它们之间关系的一种图。

在这里，左边的参与者（Actor）不仅是真实的用户，还有关联系统，这个图例能够帮助我们梳理关联的业务方，明晰系统的边界以及应当提供的功能。

目前在网络上有一些倒推某产品PRD的文章或者体验报告，其拆解方式是从页面出发倒推功能。这种方式个人认为会有些取舍不当，我们更应该从用户和系统的层面进行去设计功能。

2. 时序图

图6-时序图例图

时序图在百度百科的解释为：“通过描述对象之间发送消息的时间顺序显示多个对象之间的动态协作。它可以表示用例的行为顺序，当执行一个用例行为时，其中的每条消息对应一个类操作或状态机中引起转换的触发事件。”

简而言之，时序图是功能与内外部系统之间的交互，表示其每一步的请求以及返回数据的过程。

时序图和产品工作中所使用的泳道图非常相近，理解时序图，能够帮助我们理解系统的边界及耦合程度。

如果在产品设计中常常撰写相同的功能逻辑，可以考虑将其抽象成为一个单独的中台系统供业务方使用，节省资源也使设计的系统延展性更强。

3. 状态机

图7-状态机例图

用例用于枚举功能，时序用于理解系统的交互，在产品设计中还有很常见一类设计是状态的转换，这是用例图和时序图所覆盖不了的。如权限的控制、用户交互的切换、状态的转移等。更具体的例子可以参考秒杀活动的前中后前端的交互、电商平台中订单状态的切换。

这些场景我们会使用状态机来描述。

状态机泛指有限状态机，表示有限个状态以及在这些状态之间的转移和动作。对于复杂的状态，文字描写会相对无力，这个时候状态机就能够派上用场了。

以上的三种图像是产品经理需要去理解的，这也是技术评审中所会接触到知识点。在这里并不是建议使用这种方式撰写需求文档，而是学习UML对需求的解构方法。

在系统设计中产品经理还需要关心的，是数据库的表结构设计，它会影响到后续数据是否能够提取。

三、需求优先级的评定

最后一个环节是需求优先级的评定，我常用的方法是选取影响优先级的因素并设定比例，经过加权计算出优先级，分数越高优先级越高。

其公式如下：

优先级=因素1比例*因素1分值+因素2比例*因素2分值+….

表1-需求评估加权表

这张表，影响的因素主要有两项：投入产出比以及重要程度。

投入产出比个人认为是必选的，而重要程度中的维度可以根据实际情况去增加、减少。同理，加权中比例的设置也是如此。

经过了这3个环节，需求分析也大致结束了。在需求分析中，我们不必要拘泥于具体的某个方法，适合才是最好的。

没想到脑海里迅速完结的过程写了这么多，感谢你看到这里，谢谢。

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

题图来自Unsplash，基于 CC0 协议