需求分析对产品发展有多重要就不多说了，直接开门见山吧！

一、需求来源

平时工作中需求来源有很多：用户反馈、同事建议、老板命令、自己头脑风暴、竞品分析、数据分析、技术需求、运营需求、商业需求、跨部门合作等等；对于四面八方而来的需求，不要慌，也不要立即答应做还是不做，先记录到自己的需求池里面，接下来认真分析！

二、需求的提炼

核心：拆分需求

一般我会将进行两步拆分，下面将进行详细介绍：

1. 拆分四个维度：用户、场景、用户现在的问题、用户现在的解决方法

用户维度

可以从两个方面来看待：

1. 谁提的这个需求
2. 这个需求的用户是谁

第一点还是蛮重要的，如果是老板提的需求，自然是需要重视的；如果是用户提的需求，就分析他是不是主流用户，用户价值咋样？从提需求人这个方面可以对需求有个基本认识。

再来看第二点，这是我们需要着重分析的：

1. 这个需求谁会用？
2. 是不是我们的目标用户？
3. 这种用户占我们用户的比例是多少？
4. 用户属性咋样？

能够回答这些问题需求分析就差不多成功一半了！

回答一下第四点用户属性的问题，用户属性不同产品有着不同的定义，不过主要还是看用户的价值，比如花的钱多不多、活不活跃、是不是大V等等。

场景维度

场景是我做产品以来一直觉得很重要的一个要素，因为同一个需求在不同的场景下用户所需要的是完全不同的。

比如场景是一个单身男性周末宅在家，快到中午了，肚子有点饿了，为了填饱肚子，他这个时候会怎么做呢？

点外卖可能就是他目前所想的，这时候他需要的就是美团或者饿了么这种外卖APP！

再比如这个单身男性正在追一个女孩，有一天一起逛街，肚子饿了，你猜这个时候他们会怎么解决他们肚子饿这个需求呢？

所以关键点来了，分析场景维度的时候就需要看：

1. 这个场景是怎样的？
2. 场景是否高频；
3. 是否和我们产品目前提供的场景契合。

针对第一点，场景越真实，需求也就越真实。

针对第二点，场景的高频一定程度上决定了这个需求是否高频，自然也就决定了你的产品数据表现。

第三点需要特别说明一下：有可能这场景和目前产品提供的场景是不契合的，这个时候不要盲目做决定，需要分析这个场景是不是之前考虑漏掉了，而实际又是用户使用产品时存在的（因为不同场景是可以被同一产品/功能满足）；另外一种可能就是用户使用的场景和自己产品目前的场景的确是不一致的，经过分析后觉得有必要提供这个场景就可以做，要么就果断舍弃或者再进一步观察、或者完全就新立项一个项目（如果确实有这个必要的话）。

用户现在的问题

顾名思义就是在当前场景下，用户现在遇到的问题是什么？这个需要多听用户反馈、多看用户的操作，如果不能接触用户的话，就尽量模拟用户的场景，自己去体验、使用，从而找到现在的问题。

用户现在的解决方法

这个也好理解，就是用户为了满足自己的这个需求，他目前是怎样做的？梳理出用户目前的解决方法，包括但不限于用户的操作流程、所用到的功能、产品、 输入的内容。

通过第一步就可以排除一些低频需求和伪需求了，接着再来讲讲需求拆分的第二步。

2. 拆分两个维度：任务、目标

任务维度

1. 用户完成这个需求需要做什么
2. 我们解决这个需求我们需要做什么

第一点就是用户完成这个需求需要在我们的产品里面做什么，大概就是用户的一个基本操作路径，这个时候需要注意任务的多样性。

多样性就是指满足这个需求可能有很多种方式方法，至少应该想出两种，并知晓其优劣。

这时候可以和第一步的用户现在的解决方案做对比，看是否比现在的好、体验是否得到了优化、是否解决了用户现在的问题。

再来看第二点，意思就是我们为了满足这个需求，需要做一个什么功能/页面给用户。

这个时候需要注意的是任务的复杂度（可以简单理解为开发难度、需要的资源、成本，如果技术难度太大或者我们根本没这个资源，那就基本不可能实现，毕竟巧妇难为无米之炊。或者成本太高而回报不足，我们也不可能做太赔本的买卖。

目标维度

人们做事都是需要回报的，商业公司肯定最需要回报，所以这个目标也可以分为两个方面：

1. 用户的目标
2. 我们的目标

第一点很好理解，就是用户为什么要做这件事，做了他能得到什么好处，这是用户使用该产品/功能的驱动力来源。所以这一点我们需要了解清楚，比如用户需要上传照片这个功能，他的目标可能是希望记录自己生活的点滴，驱动力越强，产品/功能被使用的频率也就越高。

第二点我们的目标，就是我们为什么要做这个，做了对我们有什么好处。PRD的第一部分写的就是需求背景与目的；开需求评审会的时候，也是先讲为什么要做这个需求。这个是重中之重，一定要想明白，最好有量化的标准！一家公司如果一直在做没有目标、没有意义的事，结果可想而知！

三、需求的转化

上面的分析只是产品经理分析需求的一个基本过程，最终还是需要将零散的、口水化的、片面的描述转化为产品需求即形成Feature List(需求列表)。需求列表主要内容就是描述具体功能、优先级以及量化标准。

确定需求优先级的方法，有利用KANO模型，需求重要-紧急四象限，看用户的付费意愿什么的。其实个人觉得经过上面需求的提炼，其实优先级的高低、需求的真伪也就大概出来了。

最后说一下这个量化标准，这也是一个很重要的点：意思就是每个需求/功能点都需要给它设定一个上线后的考核标准，上线后相关数据指标要与这个标准对比。比如这次需求是优化下单的关键路径，那么考核标准就可以是下单成功率提升5%，这个考核标准是根据你的需求目的以及现有的数据所定下来的，而不是凭空想象的。

个人觉得一个需求至少满足三点才算合格的需求：

1. 可实现
2. 可描述
3. 可量化

如果一个需求不能实现，那还叫什么需求呢？

如果一个需求作为产品经理自己都没搞明白、弄清楚，怎么让别人认同自己呢？

如果一个需求不可量化或者说不去量化，那怎么知道这次需求做得对不对？好不好呢？怎么根据结果去倒推过程呢？

四、结语

需求分析是作为产品经理最重要的能力之一，希望大家能够准确把握需求，辨别需求真伪，做出正确的抉择。因为一将无能，累死三军啊！

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

题图来自Unsplash，基于CC0协议