本文主要讲述了产品经理如何做好需求分析，包括两个核心要点：识别评估需求价值和规范需求分析流程，以及具体实施的八个步骤。

产品经理要经常处理的工作之一，那一定是需求分析了。

需求分析做得好，产品方案落地效果佳。反之，轻则浪费团队资源时间、重则被业务方开会声讨，甚至私下给老板打你小报告。

如果这种情况持续发生，那这产品经理的小小岗位，怕是迟早会被公司优化领盒饭去了~

当我经过 1200+ 业务需求落地的花式吊打后，发现产品经理要做好需求分析，其实核心就两点：识别评估需求价值、规范需求分析流程。

一、需求价值的 2 种评估方式

在进行需求分析前，我们一般要先对需求池中的内容，进行相关的价值评估。

需求价值评估一般有两种方式：需求即时评估、需求定期评估。

需求即时评估，指的是每当接到新需求时，就进行需求价值的大致判断，并完成需求池的相关排序和记录。

你也可以定期对需求池统一进行价值评估，频率可以是几天、一周、甚至个把月，怎么开心怎么来，这主要取决于需求量大小。

我的习惯是这两种方式结合使用，复杂需求等到抽空统一处理，而一些简单需求在接到的那一刻，就完成了初步价值判断。

这样做的好处是，日积月累下你对需求池整体价值的把握了然于胸。

二、识别需求价值的 7 个维度

那如何才能判断一个需求的价值高低呢？

你可以从“战略契合、市场潜力、商业价值、符合目标、覆盖人群、使用频率、研发成本”等 7 个维度进行评估：

• 战略契合：并不是什么需求都必须要做，如果需求与用户画像冲突、年度战略规划不符，即使需求价值再高也不做；
• 市场潜力：相关需求的未来市场有多大？例如 iPhone 面世后，原先全球的手机用户，未来将面临更新换代的需求；
• 商业价值：通过落地需求方案，能直接、间接为公司带来多少增量收入；
• 符合目标：通过产品专业的需求挖掘，确保业务方提出的需求，符合其业务目标的占比有多大；
• 覆盖人群：需要考虑有同样需求的用户，到底是什么量级；
• 使用频率：推测出每个用户在一年中，遇到该需求的频率；
• 学习成本：提供的方案，对用户来说，是否能快速学会和易于上手；
• 研发成本：一个需求开发落地，所需要的工作日时间。

在日常工作中，接到新需求不一定都要考虑这么多因素，你可根据实际情况，进行删减部分。  

一些小功能需求，稍微考虑“覆盖人群、使用频率、研发成本”也够了。

完成了这个步骤后，你对需求池内容也有了大致印象，接下来就是挑出近期要落地的需求，按价值高低逐一进行需求分析了。

三、需求分析 8 步法

我在需求分析时，一般会进行这 8 个步骤：需求背景、目标受众、数据分析、业务规则、功能场景、版本目标、功能说明、版本规划。

可以说，一个需求经过这个框架思考后，后面的产品文档撰写就顺利多了。

1. 需求背景

进行需求分析的最重要一个步骤，就是了解需求背景。

产品经理在描述需求背景时，一般会通过第三方视角（例如某业务角色-销售）分析需求方的相关 3 个要素：现状、问题、期望。

• 现状：说明需求方的业务现状和需求起源是什么；
• 问题：弄清楚他们当前遇到的问题或难点；
• 期望：假设条件、资源都满足的情况下，需求方期望达到的理想状态是怎样的。

2. 目标受众

目标受众的分析步骤，需要你罗列出需求涉及的相关群体。

并对其完成“人群特征、消费习惯、需求痛点”等方面的深入了解。

模版参考：

关联方涉及：A、B、C

A：人群特征、消费习惯、需求痛点

B：人群特征、消费习惯、需求痛点

C：人群特征、消费习惯、需求痛点

3. 数据分析

数据分析的目的，主要是通过数据反馈，快速了解需求的发生频率和影响范围。

我们一般在设计产品方案前，会去拉取相关功能数据，或市面上的行业报告，以此进行需求分析和趋势预测。

目标是对需求落地有个大致预期和价值判断，方便产品经理完成后续的版本排期工作。

4. 业务规则

业务规则，是基于公司的目标或利益，定义的工作标准或流程。

例如京东的送货普遍次日达、自营七天无理由退货。

还有拼多多最近热议的仅退款服务，这些都可以算作业务规则。

我们在进行需求分析时，务必要和需求方沟通清楚，并弄懂业务规则的各种细节。

我的习惯是，单独创建一个表格，管理历史业务规则的细节内容，遇到业务问题查起来就方便多了。

5. 用户场景

用户场景，是产品经理根据用户在特定的环境、动机、需求下，模拟想象出用户行为的一种思考方式。

比如针对不同的吃饭需求，一般有这几个场景

• 为了减肥吃一些清淡食物；
• 工作时图方便我们会叫外卖吃；
• 出国在外，会去品尝当地的特色美食；
• 半夜肚子饿了，跑到楼下吃个烧烤或夜宵；
• 和情侣约会，订个逼格高的西餐厅共进晚餐。

我们可以通过这种方式，大致遍历出某个需求的多个用户场景，以此作为方案设计的参考依据。

6. 方案目标

当我做完前面几个需求分析步骤后，一般在脑子里就会形成方案的大致思路了。

将方案思路进行延伸、抽象化思考，可以推导出更通用、普适的方案目标。

这个目标一般用一句话来概括，例如“基于需求方的多变运营活动需求，通过活动、任务、抽奖、奖品、账户等配置模块，实现任意营销活动功能”。

7. 功能说明

功能说明一般是方案目标的补充，大致概括下方案涉及的功能模块有哪些，以及它们的作用。

例如：活动模块，主要用来配置活动时间、活动内容等信息。

8. 版本规划

完成了功能模块的梳理，你还要根据功能特性和资源情况，平衡拆分好迭代版本。

并思考应该在什么时间、什么节点、什么节奏、用什么方案，完成你的整体规划才合适，而且需要 ROI 收益最高。

顺便分享下，一些关于版本规划的经验：

• 资源超级充裕时：你可以 C 端、后台功能自研；
• 当资源略显不足：C 端进行自研，功能可以通过数据库配置，减少后续迭代维护成本；
• 如资源异常紧张：你还可以借用 A 项目接口，实现 B 项目上线。
• 资源完全不够用：这个时候就要动点脑瓜子，发挥下产品经理的脑洞，直接用现成的开源项目，拼接组装出一套可用的解决方案。

顺便说下，如果你只是对一些简单需求进行分析，那么以上的需求分析流程，可以简化为“需求背景、方案目标、功能说明”这三步。