需求分析是产品经理最重要的工作之一了，这篇文章，作者从一个案例出发，为我们分享了他自己需求分析的整个过程，供大家参考。

需求分析与用户调研是紧密不分家的，往往需求分析会被穿插到用户调研的过程中或调研结束回到自己工位仔细思量。

这个时候我习惯反问自己：

• “这次调研是否找对了核心业务人员/部门？”
• “实际业务场景是否梳理完全且真的如此？”
• “用户的关注点与顾虑是否都确定了？”
• “预期方案方向是否真的可以解决客户问题？”

一、确定目标

确定项目每次迭代的目标，拿共享单车调度举例，如多运营模式统一为同一种模式进行管理，降低管理成本。

二、识别目标用户

确定主要的关系人。通常包括项目的发起部门、受益部门、实际操作部门、后续影响部门等。套用到上面例子中涉及的部门分别是：发起部门为管理层，对业务整体运营策略的规划；受益部门为研发与运营部门，模式合并后，研发同学不需维护多套系统，运营同学在服务客户的策略上不需拆分多种，客户运维人员工作提效；实际操作部门为运营同学、客户的运维人员，对相关规则的配置/日常维护等；后续影响部门为财务同学，需对新规则影响到的账单进行核算等。

三、分析思路

我一般习惯从大到小、从抽象到具体进行分析，确定方向后对需求进行价值评估→方案选定→优先级排期。

案例：共享单车调度系统

公司的运营模式发展是在变化的，从起初直营模式为重心，逐渐演变为代理模式重点发展，由于历史原因，现存在2套系统在维护这两种模式，后期需要统一管理两种模式，将原有2套系统合并为1套进行管理。客户会从直营模式中转换到代理模式。经调研发现，中间存在很多逻辑不一致等问题，不能简单进行功能合并。

调研到的问题主要涉及以下几个方面：

1）两模式的调度规则与实现方式不同

2）两模式的数据指标口径、时效性不同

3）下游执行层功能与调度系统规则不同

价值体现：

1）规则统一并兼容后，直营转代理的客户还能继续沿用已熟悉的规则，不会因系统的转变而流失，提供更好的服务，提高客户使用意愿

2）根据当前市场情况，优化指标逻辑，提升准确性，为两模式客户对业务决策提供有效支撑

3）公司内部各关联业务系统规则/结果一致，防止给客户造成数据不准确的误解，提升客户对系统的信任程度

4）两套系统合并为一套，降低研发维护成本，提高公司运转效率

方案分析：

过程中我会重点关注历史逻辑与新逻辑的兼容情况，避免遗漏存量用户的逻辑。

优先级：

我常用的需求优先级排序方法是四象限法（基于需求本身重要情况出发）或KANO模式（基于客户满意度出发）

此案例我结合了运营部门反馈的客户急迫情况，用了四象限法进行分析，将需求分为：

重要紧急、重要不紧急、不重要紧急、不重要不紧急

大致分布如下图：

分析后，我们将需求拆分了几个版本进行迭代

P0：两模式的调度规则与实现方式不同

P1：两模式的数据指标口径、时效性不同

P1：下游执行层功能与调度系统规则不同

P2：其他

四、场景梳理

结合业务流程，层层梳理业务场景，避免遗漏。

我在收集需求时，通常会基于核心业务流程使用需求场景清单的方式进行梳理。

还是拿共享单车调度举例，以下为简版的调度主流程：

基于以上流程图，细化的场景清单举例如下：

以上表格根据实际情况还可以有一些字段的新增，比如可加入价值、方案等，我一般调研的过程中就会尽可能把实际场景与角色往表格里填，后续根据业务流程再进行补充，防止当时的一些要点遗漏。

五、规划排期

需求方向、优先级、初步方案基本确定后，即可进行版本拆分，着手于第一个版本进行方案（原型）设计。

以上是我平时工作中常用的需求分析过程，期待和大家一起交流。