产品经理要经常处理的工作之一，那一定是需求分析了。
如果这种情况持续发生，那这产品经理的小小岗位，怕是迟早会被公司优化领盒饭去了~
当我经过1200+业务需求落地的花式吊打后，发现产品经理要做好需求分析，其实核心就两点：识别评估需求价值、规范需求分析流程。
需求价值评估一般有两种方式：需求即时评估、需求定期评估。
你也可以定期对需求池统一进行价值评估，频率可以是几天、一周、甚至个把月，怎么开心怎么来，这主要取决于需求量大小。
我的习惯是这两种方式结合使用，复杂需求等到抽空统一处理，而一些简单需求在接到的那一刻，就完成了初步价值判断。
这样做的好处是，日积月累下你对需求池整体价值的把握了然于胸。
那如何才能判断一个需求的价值高低呢？
你可以从“战略契合、市场潜力、商业价值、符合目标、覆盖人群、使用频率、研发成本”等7个维度进行评估：
在日常工作中，接到新需求不一定都要考虑这么多因素，你可根据实际情况，进行删减部分。
一些小功能需求，稍微考虑“覆盖人群、使用频率、研发成本”也够了。
完成了这个步骤后，你对需求池内容也有了大致印象，接下来就是挑出近期要落地的需求，按价值高低逐一进行需求分析了。
我在需求分析时，一般会进行这8个步骤：需求背景、目标受众、数据分析、业务规则、功能场景、版本目标、功能说明、版本规划。
可以说，一个需求经过这个框架思考后，后面的产品文档撰写就顺利多了。
进行需求分析的最重要一个步骤，就是了解需求背景。
并对其完成“人群特征、消费习惯、需求痛点”等方面的深入了解。
模版参考：
关联方涉及：A、B、C
A：人群特征、消费习惯、需求痛点
B：人群特征、消费习惯、需求痛点
C：人群特征、消费习惯、需求痛点
数据分析的目的，主要是通过数据反馈，快速了解需求的发生频率和影响范围。
目标是对需求落地有个大致预期和价值判断，方便产品经理完成后续的版本排期工作。
业务规则，是基于公司的目标或利益，定义的工作标准或流程。
例如京东的送货普遍次日达、自营七天无理由退货。
还有拼多多最近热议的仅退款服务，这些都可以算作业务规则。
我们在进行需求分析时，务必要和需求方沟通清楚，并弄懂业务规则的各种细节。
我的习惯是，单独创建一个表格，管理历史业务规则的细节内容，遇到业务问题查起来就方便多了。
用户场景，是产品经理根据用户在特定的环境、动机、需求下，模拟想象出用户行为的一种思考方式。
比如针对不同的吃饭需求，一般有这几个场景
我们可以通过这种方式，大致遍历出某个需求的多个用户场景，以此作为方案设计的参考依据。
当我做完前面几个需求分析步骤后，一般在脑子里就会形成方案的大致思路了。
将方案思路进行延伸、抽象化思考，可以推导出更通用、普适的方案目标。
这个目标一般用一句话来概括，例如“基于需求方的多变运营活动需求，通过活动、任务、抽奖、奖品、账户等配置模块，实现任意营销活动功能”。
功能说明一般是方案目标的补充，大致概括下方案涉及的功能模块有哪些，以及它们的作用。
完成了功能模块的梳理，你还要根据功能特性和资源情况，平衡拆分好迭代版本。
顺便说下，如果你只是对一些简单需求进行分析，那么以上的需求分析流程，可以简化为“需求背景、方案目标、功能说明”这三步。