编辑导语：做产品离不开对需求的分析整理，当我们面对海量的需求该如何面对，如何处理，如何提炼出真需求来作为做产品的核心链。这篇文章从需求分析的定义出发，用四步法来教大家搞定需求分析关键节点。一起来看看吧。
这个需求做还是不做？这是产品经理日常需要做的选择。
每天都有需求从不同的地方来，甚至都无法知道什么时候会来，但是你知道需求一定会来。
那怎么判断需求是不是值得做？这就要做需求分析了，可见需求分析也是一门基本功。
我们今天就聊一聊需求分析，希望对大家有所启发。
需求分析也称为软件需求分析、系统需求分析或需求分析工程等，是开发人员经过深入细致的调研和分析，准确理解用户和项目的功能、性能、可靠性等具体要求，将用户非形式的需求表述转化为完整的需求定义，从而确定系统必须做什么的过程(百度百科）。
关于需求分析的说明最重要的就是前文的最后一段“将用户非形式的需求表述转化为完整的需求定义，从而确定系统必须做什么的过程。”
这段话说明了几个情况：
- 一是需求通常来源于用户；
- 二是用户在表达需求的时候是根据自己的习惯表述的，是不完整甚至是隐含的，需要产品经理进行深入分析和定义；
- 三是在用户表达了需求以后，从系统层面需要给出具体的方案，帮助用户解决需求问题。
当然需求虽然是来源于用户，但有可能不是直接来源于用户，可能是经过业务部门转述过来的，也可能是数据分析得来的。
实际上日常产品经理在正式开始做需求方案之前都会做需求分析，所以算是一个常规技能。
接下来我们具体讲一下需求分析的三个步骤，只有完成全部三个步骤才算一次需求分析完整的结束了。
第一步先做需求真实性的判断，如果是一个不真实的需求其实就没有必要做后续的分析。
一个需求是否真实通常可以通过回答以下四个问题来判断：
- 用户是谁？
- 需求场景是怎么样的？
- 用户遇到的问题是什么？
- 用户想要解决的实际需求是什么？
以上四个问题对应了用户、场景、挑战和目的，能够回答以上四个问题是判断需求真实性的前提，即如果无法表述前面的问题就可以判定这不是一个真实需求。
我们举个例子做一些说明：
知乎上有个问题是这样的，淘宝下订单后为什么不可以更改送货地址？
我们按照前面的问题框架回答一下：
- 用户是谁？淘宝上购买商品的用户。
- 需求场景是怎么样的？送货地址填错了或者选错了。
- 用户遇到的问题是什么？淘宝无法修改送货地址。
- 用户想要解决的实际需求是什么？让购买的商品送到正确的地址。
非常清晰，所以对于地址填错了的淘宝用户来说需要修改送货地址是一个真实的需求。
我们再举一个例子：
手工耿曾经做过一个物品，用处是在地震发生时能够保证这个碗不被打翻，能够继续吃泡面。
我们还是按照前面的问题框架回答一下：
- 用户是谁？肚子饿了，想吃泡面的人。
- 需求场景是怎么样的？在地震发生时正在吃泡面。
- 用户遇到的问题是什么？地震发生了需要躲避危险。
- 用户想要解决的实际需求是什么？保证自己的生命安全。
大家注意到没有，在地震中用户的最优先的需求是保证自己的安全，如果是地震发生，大地还在晃动，谁还有心思吃泡面。
所以用户和场景都对，吃泡面这个需求虽然存在但是不是第一需求，第一需求是安全，那么所谓的凯发平台的解决方案当然不对。
注意：我在这里说的是需求的真实性，而不是判断需求的真伪，我看了一下市面上很多写用户需求分析的文章，都在说伪需求的问题，他们中的绝大部分都把需求的理解不对或者需求的价值也归在伪需求里面，我认为这是非常不对的。
有名的一个例子是大家想要一匹更快的马的需求，福特把他解读为需要更快的速度就做出了福特汽车。
注意这个例子，福特变更了解读的角度，更接近需求的本质，所以福特胜利了，但是这并不能说想要一匹更快的马是一个伪需求，想要一匹更快的马也是一个真实的需求，如果把这个时间拉到工业革命以前，当时的技术水平根本无法造出汽车，那你说这是不是一个真需求？
所以不要把不同的问题混为一谈，都把它们归类成伪需求，这是非常荒谬的做法。
需求真实性判断完成之后就需要去判断需求的价值。需求价值的大小由以下几个维度来确定：
- 用户广度：该需求的受众面有多大？
- 使用频率：该需求的使用频率是以日/周/月为周期？
- 刚需程度：该需求对用户有多强烈需要？
- 生态影响：对平台其他参与方的影响。
- 产品时机：该需求是否符合产品的规划，当下的环境？
我们还是以前面那个淘宝的例子来说明——淘宝下订单后为什么不可以更改送货地址？
1. 用户广度
该需求的受众面有多大？
具体数据我肯定不知道，但是应该还是蛮多人遇到过这个问题，假设为10%吧。
2. 使用频率
该需求的使用频率是以日/周/月为周期？
频率肯定很低，大概上百次里面才会有那么一两次，从频率上来说大概一年也就一两次，这是从一般用户的角度来说，购买频次越高这个功能的使用频率也可能更大。
3. 刚需程度
该需求对用户有多强烈需要？
用户遇到这个问题的话当然是希望能够修改地址，但是没有这个功能好像负面也不是很大，可以客服联系商家修改，或者去送达的地方取一下货，对于大部分用户来说地址不是住的地方就是公司，有的时候换住址或者公司可能出错，但是去取一下也还行。
4. 生态影响
该需求对平台各方产生的影响是怎么样的？
对于购买用户来说其实不会因为这个问题就离开，毕竟和平台带来的便利性比较，这么一两次挫折不算什么。
对于商家来说，如果允许修改就会是个非常大的麻烦。
我们来具体分析一下：
如果允许用户修改会发生什么情况呢？
可能有两种情况，一种是商家发货了，一种是商家没发货。
发货了就不说了，修改也没用，因为货都在路上了，不可能更改地址，快递公司也没有这样的流程。
如果没发货那么可能会出现两种情况，一种是商家还没有备货，一种是已经备货提交快递单给快递公司了。
如果没有备货还好说，如果已经提交了快递单那就很麻烦了，修改数据是简单的，问题就是你需要把这个订单对应的货品找出来然后把快递单换一下，这个找的过程是很耗费商家时间的，因为有可能商家一天发几千件货，花时间更换地址就会导致发货效率降低，如果要保持效率就需要话更多的人工成本，这对商家来说肯定是不希望的，因为钱赚少了。
如果允许修改则商家每天都要处理这个事情，不友好程度就很高了，商家不会马上走但是可能会把重心迁移到其他平台，这样整个淘宝生态就慢慢变差了，这个肯定是淘宝难以承受的。
所以从生态的角度来说这个就是负向价值非常大的一个用户需求。
商业价值：该需求对于业绩的价值是怎么样的？
基本没有商业价值，因为改了之后并不会增加业绩。
产品时机：该需求是否符合产品的规划，当下的环境？这个倒是没所谓。
所以综合起来看这个需求的价值对于淘宝就是负面的，淘宝肯定不会做这个功能。
我在举例说明的时候用的都是定性的说明，如果想要做成定量的分析，那么可以给每一项做一个打分表，譬如1-10分，然后给每一项赋予不同的权重值，譬如都是20%，这个根据需要调整就是了，最后统计综合得分，根据综合得分判断需求价值。
判断需求价值是为了决定做不做的问题，如果需求价值不大甚至需求价值为负那就不用列入计划了。
按照我们的经验来说，需求不可能只有一个，它们广泛的来自于领导、用户、业务部门和产品部门自身，所以有十几个或者几十个需求是很正常的，这个时候就涉及到对需求优先级的判定问题，公司的资源总是有限的，所以不可能所有需求都在第一时间投入资源，优先级的判定就是解决资源如何投入的问题。
1. 需求的优先级如何判定呢
对于优先级的判定主要是基于前面的需求价值和需求成本-指的是实现这个需求需要投入的资源，这就是一个衡量性价比的过程。
一般类似会把需求价值和需求成本分成低、中、高三等，交叉之后分为优先级最高、优先级次高、优先级一般和不做四个部分。如下图：
优先级最高一般划为p0和p1，优先级次高划为p2和p3，优先级一般就划为p4。
特别说一下，有些公司把优先级划的特别细，分成好多等级，其实没必要。太细了浪费时间分。
需求池的管理是最后一步，也是最重要的一步，把从各方收集来的需求、经过前面的分析之后筛选出来的需求汇集到一起，记录在册方便管理需求和后续的版本规划，也方便追溯产品方向的迭代。
需求池的基础信息主要包含：编号、模块、功能点、需求描述、场景描述、需求类型、优先级、提出人、提出时间、当前状态、备注。
编号：需求的唯一标识，编号的规则可以自行定义，最简单的就是日期 自增数，作用是作为每条需求的唯一编号和快速查询需求。
模块：根据产品模块去划分，作用是将需求统一归类到某个模块下，在进行版本规划时，可以优先从某个模块中筛选，同时便于根据模块查询。
功能点：简单描述需求的功能，也就是要做什么，这样我们快速查看某个需求时，能一眼看明白这个需求是要新增或修改哪个功能。
需求描述：需要描述清楚需求的完整性、一致性，需要精准的描述。如果产品经理在后续想不清楚这个需求到底要做什么，可以通过需求详细描述来回想或了解。
场景描述：了解用户在什么场景下产生的需求，在给开发转述为什么要增加这个需求时，可以清晰的说明是因为哪些原因，更能说服开发愿意做这个需求。
优先级：从p0-p4，优先级依次下降，优先级可以帮助产品经理在做版本规划时判断应该先做哪些需求。
开发量：需求的开发工作量，可以通过这个信息规划开发每个版本的工作内容，也方便我们了解每个需求的开发难度。
提出人：原需求的提出人，便于日后有疑问可追溯。
提出时间：需求的提出时间，方便我们了解是什么时间提出的需求，同时可以利用提出时间来规划需求的紧急程度。
产品对接人：具体是谁来负责对接和后续的产品设计，这个的话一开始没有可以空着。
状态：这个指的是需求的生命周期，待处理、设计中、开发中、已发布、暂缓（标注原因）；主要作用是可以对需求的流转状态进行跟踪，可以了解需求在不同阶段的状态，发现问题及时调整。
备注：一些额外信息的记录。
需求类型主要包含：
- 新增功能：目前平台没有实现的功能；
- 功能迭代：对目前平台已实现的功能进行优化；
- 用户体验：例如页面按钮摆放的问题，发送消息时发送按钮放在右侧，可以按照用户的使用习惯设计；
- ui优化：如整体产品色调的调整等，这个需要根据平台调性去处理。
需求分析其实不复杂，但是想要把握的准其实还是需要一些功力的，大家在做具体的需求方案之前不妨想一想这个需求是不是值得做。
公司资源有限，你的时间也有限，总要投入到那些能够产生更大价值的需求里面去。
而选择无疑是这个时代最重要的能力，那么在选择之前的分析就无疑是基石，多练练这个技能，或许不止对工作有帮助。
如果你选择做产品经理，那么祝你好运。
