作者：好夕雷
产品经理要经常处理的工作之一，那一定是需求分析了。
需求分析做得好，产品方案落地效果佳。反之，轻则浪费团队资源时间、重则被业务方开会声讨，甚至私下给老板打你小报告。
如果这种情况持续发生，那这产品经理的小小岗位，怕是迟早会被公司优化领盒饭去了~
当我经过 1200+ 业务需求落地的花式吊打后，发现产品经理要做好需求分析，其实核心就两点：识别评估需求价值、规范需求分析流程。
需求价值的 2 种评估方式
在进行需求分析前，我们一般要先对需求池中的内容，进行相关的价值评估。
需求价值评估一般有两种方式：需求即时评估、需求定期评估。
需求即时评估，指的是每当接到新需求时，就进行需求价值的大致判断，并完成需求池的相关排序和记录。
你也可以定期对需求池统一进行价值评估，频率可以是几天、一周、甚至个把月，怎么开心怎么来，这主要取决于需求量大小。
我的习惯是这两种方式结合使用，复杂需求等到抽空统一处理，而一些简单需求在接到的那一刻，就完成了初步价值判断。
这样做的好处是，日积月累下你对需求池整体价值的把握了然于胸。
识别需求价值的 7 个维度
那如何才能判断一个需求的价值高低呢？
你可以从“战略契合、市场潜力、商业价值、符合目标、覆盖人群、使用频率、研发成本”等 7 个维度进行评估：
-
战略契合：并不是什么需求都必须要做，如果需求与用户画像冲突、年度战略规划不符，即使需求价值再高也不做；
-
市场潜力：相关需求的未来市场有多大？例如 iPhone 面世后，原先全球的手机用户，未来将面临更新换代的需求；
-
商业价值：通过落地需求方案，能直接、间接为公司带来多少增量收入；
-
符合目标：通过产品专业的需求挖掘，确保业务方提出的需求，符合其业务目标的占比有多大；
-
覆盖人群：需要考虑有同样需求的用户，到底是什么量级；
-
使用频率：推测出每个用户在一年中，遇到该需求的频率；
-
学习成本：提供的方案，对用户来说，是否能快速学会和易于上手；
-
研发成本：一个需求开发落地，所需要的工作日时间。
在日常工作中，接到新需求不一定都要考虑这么多因素，你可根据实际情况，进行删减部分。
一些小功能需求，稍微考虑“覆盖人群、使用频率、研发成本”也够了。
完成了这个步骤后，你对需求池内容也有了大致印象，接下来就是挑出近期要落地的需求，按价值高低逐一进行需求分析了。
需求分析 8 步法
我在需求分析时，一般会进行这 8 个步骤：需求背景、目标受众、数据分析、业务规则、功能场景、版本目标、功能说明、版本规划。
可以说，一个需求经过这个框架思考后，后面的产品文档撰写就顺利多了。
需求背景
进行需求分析的最重要一个步骤，就是了解需求背景。
产品经理在描述需求背景时，一般会通过第三方视角（例如某业务角色-销售）分析需求方的相关 3 个要素：现状、问题、期望。
目标受众
目标受众的分析步骤，需要你罗列出需求涉及的相关群体。
并对其完成“人群特征、消费习惯、需求痛点”等方面的深入了解。
模版参考：
关联方涉及：A、B、C – A：人群特征、消费习惯、需求痛点 – B：人群特征、消费习惯、需求痛点 – C：人群特征、消费习惯、需求痛点
数据分析
数据分析的目的，主要是通过数据反馈，快速了解需求的发生频率和影响范围。
我们一般在设计产品方案前，会去拉取相关功能数据，或市面上的行业报告，以此进行需求分析和趋势预测。
目标是对需求落地有个大致预期和价值判断，方便产品经理完成后续的版本排期工作。
业务规则
业务规则，是基于公司的目标或利益，定义的工作标准或流程。
例如京东的送货普遍次日达、自营七天无理由退货。
还有拼多多最近热议的仅退款服务，这些都可以算作业务规则。
我们在进行需求分析时，务必要和需求方沟通清楚，并弄懂业务规则的各种细节。
我的习惯是，单独创建一个表格，管理历史业务规则的细节内容，遇到业务问题查起来就方便多了。
用户场景
用户场景，是产品经理根据用户在特定的环境、动机、需求下，模拟想象出用户行为的一种思考方式。
比如针对不同的吃饭需求，一般有这几个场景
-
为了减肥吃一些清淡食物；
-
工作时图方便我们会叫外卖吃；
-
出国在外，会去品尝当地的特色美食；
-
半夜肚子饿了，跑到楼下吃个烧烤或夜宵；
-
和情侣约会，订个逼格高的西餐厅共进晚餐。
我们可以通过这种方式，大致遍历出某个需求的多个用户场景，以此作为方案设计的参考依据。
方案目标
当我做完前面几个需求分析步骤后，一般在脑子里就会形成方案的大致思路了。
将方案思路进行延伸、抽象化思考，可以推导出更通用、普适的方案目标。
这个目标一般用一句话来概括，例如“基于需求方的多变运营活动需求，通过活动、任务、抽奖、奖品、账户等配置模块，实现任意营销活动功能”。
功能说明
功能说明一般是方案目标的补充，大致概括下方案涉及的功能模块有哪些，以及它们的作用。
例如：活动模块，主要用来配置活动时间、活动内容等信息。
版本规划
完成了功能模块的梳理，你还要根据功能特性和资源情况，平衡拆分好迭代版本。
并思考应该在什么时间、什么节点、什么节奏、用什么方案，完成你的整体规划才合适，而且需要 ROI 收益最高。
顺便分享下，一些关于版本规划的经验：
-
资源超级充裕时：你可以 C 端、后台功能自研；
-
当资源略显不足：C 端进行自研，功能可以通过数据库配置，减少后续迭代维护成本；
-
如资源异常紧张：你还可以借用 A 项目接口，实现 B 项目上线。
-
资源完全不够用：这个时候就要动点脑瓜子，发挥下产品经理的脑洞，直接用现成的开源项目，拼接组装出一套可用的解决方案。
顺便说下，如果你只是对一些简单需求进行分析，那么以上的需求分析流程，可以简化为“需求背景、方案目标、功能说明”这三步。
总结
产品经理做好需求分析，你只需学会这两种方法：识别评估需求价值、规范需求分析流程。
怎么识别需求价值？可以从“战略契合、市场潜力、商业价值、符合目标、覆盖人群、使用频率、研发成本”等 7 个维度分析。
如何规范需求分析流程？你需要做好这 8 步：需求背景、目标受众、数据分析、业务规则、功能场景、版本目标、功能说明、版本规划。
