需求管理是一个产品中非常重要的环节，它直接关系到产品最终交付的成果和质量。产品经理在面对用户的时候，还面对着一群人：技术/开发。如何在接触用户需求到技术实现过程中做好需求分析，提高产品需求的交付质量？本文将从5个阶段理解需求，细化需求分析全过程。

对于产品经理来说，需求来源可以分为两种，被动和主动。被动需求来自于不同用户角色，可能来自于公司的业务部门、产品、测试、公司老板、直属上司，和产品的使用者（Key_User）。在被动接收的需求里，有时候用户提出的需求很荒谬；有时候提出的需求很具体，具体到做一个什么样的界面，加一个什么功能按钮，实现什么逻辑；有时候却很模糊，用户完全无法表达清楚自己面对的困难在哪里，自己想要什么。主动需求则来自于产品经理通过自身对产品的理解、竞品分析、市场分析、产品运营报告等途径整理的需求。

面对如此杂乱的需求，如何有逻辑、有顺序、完整性的梳理出需求？

1. 需求梳理

1.1 搭建自己的需求框架

将杂乱无章的需求，作为一个个待解决的问题点，解决需求的过程实际上就是解决用户面临的问题。

需求框架可以是产品最初的概念模型，可以是调研提纲，也可以是一段思路。作用是为了有次序、有逻辑、有条理的将所有需求串联起来。

（1）需求分类

搭建需求框架的第一步是要对收集的需求列表进行分类，我把产品经理收集的用户需求分为两类：业务需求、功能需求。

• 业务需求：由业务提供方或者开展方（产品的使用者）提出的需求，需求点与业务流程、实际操作过程相关。
• 功能需求：由用户提出需要一个什么样的功能，实现什么样的业务逻辑和计算逻辑；或者有用户期望有一个功能，能够完成一件事情，需求点与功能直接相关。

（2）连接需求

按照场景以及作业流程将分类后的需求连接起来。如下图表达的类似结构：

当然，也可以通过思维导图来实现。连接需求时不一定要非常细，可能只是一个需求大类或者大方向，但是最好按照业务的发生顺序进行依次排列。

2. 需求调研

需求框架梳理结束后，产品经理需要深入到需求调研活动中去，重点是了解现状情况。了解有哪些人即哪些角色参与到现有的业务流程中，业务现状是怎样的，哪些线上做，哪些线下做，线上线下是如何衔接的，什么情况什么节点有哪些凭证，哪些业务单据，每一个单一的业务场景对应的操作子流程是怎样的，这些都是需求调研阶段需要了解的内容。

常用的调研方法有以下几种：

（1）问卷调查

笔者认为问卷调查法在信息收集类的调研活动中是最能发挥优势的，可以免去跑现场、找用户等环节，就可以获取大量用户的有效信息。但一般在业务调研活动中，很少用到。

（2）用户访谈

与用户面对面交流，这种交流比较随意轻松，尤其对终端用户的心理压力小，可以简单直接的获取到用户的第一手需求。甚至有些用户会提出作业过程中真正的痛点和问题所在。交流内容会相对比较丰富，也是最耗时的。这种通过交流的调研方式，最主要的是要找到业务相关的关键用户（不一定是某个负责人、主管，但一定是现场的协调和操作者）。

（3）参观

工作中常常会遇到某个领导来莅临指导，某个同行来参观等等。参观也是调研活动中的一种。通过对管理方式、操作流程、作业效率等方面的观察和参观过程中与个别用户的简单交流，熟悉优与劣（参观一定是有参照物的）。

（4）专题会

专题会一般会在遇到重大问题或者方向、范围发生偏移或者不确定的时候，预先安排好会议时间、会议地点、通知所有参会人员参加专题讨论。

2.1 前期调研

第一阶段的调研会集中于对产品的目标、定位、范围的确定，该阶段多以专题会的形式展开调研，最终需要出具概要方案，信息流、资金流、物流之间的层次关系，系统内在活动关系等，每一阶段的产出物整理也属于需求梳理、不断完善需求框架的一部分。

2.2 深度调研

经过第一轮的调研，需求框架里无论是前期用户提出的需求（问题点）还是产品经理希望通过调研了解到的部分内容应该已经有了答案。接下来需要对需求进行分解，比如第一阶段需求调研中分析出了采购、销售、物流与库存之间的关系。那么采购有多少种类型，分为多少种情况就需要进行二次调研，将需求从大类划分出若干小类，从业务主流程划分出若干操作子流程。

分解的过程即深度调研的过程，在调研过程中，每一个需求大类中有哪些子流程，流程中参与到哪些角色，每个角色是如何操作的，前置条件是什么都需要在此阶段了解清楚。在需求分解时，最好能够通过用户访谈和专题会结合的方式，讨论后每一次产出物的迭代更新也是需求逐渐清晰、正确的说明。

调研过程中需要遵循一定的次序和逻辑，以免被调研用户发生业务交叉混乱导致调研结果出错的情况（可以再次体会下需求框架的作用）。深度调研结束后可能采集了很多录音、纸上记录了很多内容、脑子里全是调研的问题、用户的回答。将调研的所有素材整理成有用的信息，一共有多少业务流程，对应哪些操作子流程，流程中每一个节点由哪个用户角色操作，在系统操作还是线下操作，在什么系统操作，会生成什么单据，单据怎么流转，最终构建一张完整的需求网络。

3. 需求分析

3.1 优化

B端产品在需求优化环节最难的点是应不应该优化，甚至在产品需求分析工作中完全就没有需求优化环节。从一个咨询顾问的身份去考虑，业务的现状和有序执行并不能说明现有的业务流程就是正确的，不臃肿的。但是优化可能就会涉及到流程改造，业务重组，这时候企业管理的需求是如何进行优化需要考虑的重要因素。

常见的简易优化点：

• 单纯数据处理：特点是工作量大、耗时、易出错、操作单一、可替代性强，像这样的情况线上数据标准化处理的意义非常大。
• 出错高频点：特点是易出错、换人也避免不了。可以通过条码扫描（字符复杂、录入难度大）、自动计算（人工计算，单位换算之类）、智能匹配（限制性强、人工识别困难）等方法。

还有一部分是涉及到操作问题的优化，如操作异常点、操作流程冗余、单据冗余等等问题。

优化以后，涉及到的业务操作需要和对应角色、业务节点负责人进行评审确认。

3.2 重组

经过需求优化后的子流程之间会有共通点、差异点，通过场景、用户角色、操作现状、产品目标四个方面对需求重新整合、最终交付产品操作流程。

比如原材料采购入库和配件采购入库的操作流程一致，操作用户和入库计算逻辑可能不一致，那么在需求重组时，可以合并为一个流程。

4. 边界定义

在产品目标、人力资源条件、行业约束等客观条件下，需求便会有了边界。如：

• 行业边界：由行业规则、法规约束的边界。如财税系统。
• 结构边界：一个产品由若干个子系统组成，每个子系统承担什么角色，完成什么任务，会有一个相应的活动范围。所以产品的结构边界必须要清晰，否则产品结构就会发生混乱，如交易系统与企业人事数据混在一起。
• 功能边界：制定一个原则，一个功能是为解决同一类业务或者同一种问题产生的。同时需要考虑到人力资源、系统资源等问题。

5. 需求转化

需求转化即是从用户需求到产品需求的过程，需要做的工作较多，如优先级的定义、产品版本的切分、产品设计等。

这部分可以利用马斯洛需求层次理论、Kano模型等结合产品目标、需求优先级完成产品版本的切分和产品设计。

最后经过产品核心体系的设计，产品流程、产品框架的设计，最终输出PRD。

以上描述的需求分析的5个阶段，每一个阶段在实际应用中都是一个不断反复的过程，其实，需求分析过程是产品经理对自己的认知不断验证、推翻再验证的过程。

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

题图来自 Unsplash，基于 CC0 协议