针对如何做需求分析，是产品经理等岗位避不开的一个课题，下面我们从这四个维度来解答：
一、为什么要做需求分析
二、需求分析的时机
三、需求分析的步骤
四、需求分析的工具
一、为什么要做需求分析
先说两个场景让大家感受一下。
场景一：一家通讯服务公司，最近有用户反馈，电话座机听筒电缆太短了，应该延长到10米！！！于是秉承用户至上的原则，我们把所有的电话线做成10米的。但是发现后面又有用户说还是太短了，需要100米的。
场景二：一家做电商平台的公司，最近领导打算针对平台做一些营销工具方便运营进行运营推广。接到需求后，直接就参照现在市面上的营销工具做了优惠券方案。提交领导后，被领导批他要的不是优惠券，而是做一些促销活动，要我们推倒重做。
通过上面两个场景，我们不难发现，在接到需求之后，没有去了解需求的背景，深挖需求原因，就很容易导致做出来的方案是不符合公司的要求，导致大量的人力、时间、资源的浪费，甚至会导致老板怀疑你的工作能力。
接下来，我们对场景一的需求做一个简单分析：
通过上图可以得出一个结论：需求分析的本质就是将用户反馈的原始需求，转化为产品需求，进而推导为产品方案。如下图所示：
二、需求分析的时机
那么在工作中，产品经理一般是在什么时候进行需求分析呢？我们再来看两个场景。
场景一：你刚入职了一家做物流的公司，该公司主要是承接其他公司的运输业务。不久你接到了来自于业务方的需求，业务方告诉你，目前有些司机没有办法按时到达装卸货的地址，想通过产品层面进行优化。
你会发现在收集需求时，如果只是把前面的一句话需求记录到需求池里，会有很多疑问点。
比如：目前业务是怎样的？司机是如何分配的？司机为何会出现迟到的情况？迟到对客户会造成什么影响？而业务方既然是采用跟你面对面的沟通方式在提出需求，其实就可以及时去了解需求的一些背景。
从某种程度上来说，在这里收集需求的同时，也已经涉及到了一部分需求分析的工作。
场景二：你们公司设计了一款App，其中有一个入口是用户反馈，用户可以通过该功能反馈在产品使用当中的Bug、使用情况等，反馈后的内容可以在后台的用户反馈列表当中进行查看。
作为产品经理则需要定期（比如每周或者每月）去用户反馈列表当中查看，并将用户的相关需求记录到需求池里面，由于需求可能会很多，所以一般保持每周或每月的进度，以产品经理团队内部讨论的方式，对需求池当中的需求进行分析和处理。
需求分析的时机：
收集需求时：作为产品经理则需要定期（比如每周或者每月）去用户反馈列表当中查看，并将用户的相关需求记录到需求池里面。
收集需求后：将需求方的原始需求记录到需求池之后，后续对需求池当中的需求进行分析。
三、需求分析的步骤
主要由四个步骤组成：
①需求澄清
②需求甄别（也叫判断真伪需求）
③需求优先级
④确认需求方案
1、需求澄清
先说需求澄清，在工作当中，很多情况下产品经理所收集到的原始需求，可能相对很完善，但也有很多情况下，我们收到的需求都是不太明确的。
所以，在对需求进行分析时，需要先明确各个需求的背景是什么，这里给大家介绍一个方法论：3W1H。
3W：WHY、WHO、WHAT
1H：HOW
接下来，通过一个场景来做一次需求澄清：
一家做在线英语培训的公司，公司有很多外籍教师，学员大都为中国学生。目前公司的产品经理在每周对需求池当中的原始需求进行整理分析时，发现之前有个叫Zoe的外籍老师上周提出了如下需求：“希望可以在上课时，在网页版的直播间里可以打字进行答疑，并且在直播课里最好提供举手、邀请某人语音的功能。”
WHY：Zoe为什么想要在直播间打字？Zoe为什么需要邀请某人语音的功能？
WHO：Zoe
WHAT：授课的时候需要让学员回答问题
HOW：目前不确定，但是Zoe给出了期望方案
以上内容就是需求澄清的方法论和案例了，接下来我们聊一下需求甄别。
2、需求甄别
现实工作中，各种人员都会跟产品经理提各种需求，有些需求值得做，但是有些需求是不值得做的。在开始进行产品方案设计之前，需要先确定需求到底值不值得做。
来看三个对应的场景，加深对于这三个特性的判断：
场景一：一家做在线英语培训的公司，公司有很多外籍教师，学员大都为中国学生。目前公司的产品经理在每周对需求池当中的原始需求进行整理分析时，发现之前有个叫Zoe的外籍老师上周提出了如下需求：
“希望可以在上课时在网页版的直播间里可以打字，进行答疑，并且在直播课里最好提供举手、邀请某人语音的功能。”
经过调研发现除了这个老师之外，没有其他老师有这种需求，并且很多老师觉得没必要。
调研之后发现这个需求不太符合普遍性，因此判断为伪需求。
场景二：公司使用微信进行工作交流，由于公司在全国有多个分公司，在进行工作对接的时候经常需要传输文件，但是在使用过程中发现了两个这样的问题，①有些工作文件因为较大，无法发送，②有些文件因为暂时用不上，就没去下载，等到要用的时候发现文件已经过期，因此给微信产品经理提出了两个需求：
“①希望微信支持大文件传输；②希望微信文件永不过期。”
调研之后发现这个需求不太符合痛点性，因此判断为伪需求。
场景三：一家IT培训公司的老师，在教学过程中使用TAPD让学员提交每日作业，在批改作业的时候发现一个问题，学员的作业无法批量下载，于是给TAPD的产品经理提出了建议：
“希望TAPD支持文件批量下载。”
调研之后发现这个需求不太符合高频性，这个场景可能不太好理解，这里说高频性是指站在公司的维度去看的，TAPD这款软件本身就是研发给有项目管理需求的公司使用的，不是专门研发给培训公司使用的，TAPD所在公司调研了很多客户发现除了这家培训公司其他公司几乎没有批量下载的需求，因此判断为伪需求。
除了普遍性、痛点性、高频性以外，在工作中还有两个点也是产品经理必须考虑的两个点，只不过思考的维度较高，可能有些产品经理容易遗忘。
产品经理在判断需求真伪的时候也需要站在公司的维度上考虑下成本能否覆盖，也需要站在项目组的维度上考虑上技术上能否实现。
需求甄别完成之后，剩余的需求都是产品经理要做的需求了，那这么多需求产品经理应该先做哪个需求呢？下面我们聊需求优先级的排序。
3、需求优先级
这里给大家介绍两个方法论：四象限法则、P序列。
四象限法则：根据重要和紧急程度划分为四个维度，如下图所示：
P序列：按照优先级划分P0>P1>P2>P3>...>Pn，如下图所示：在工作中产品经理经常会碰到多个需求，没办法绝对判断出哪个需求是P1、哪个需求是P2的顺序。这种情况下，建议按照经验执行就好，不要那么纠结，反而浪费时间。
4、确认需求方案
确认需求方案，其实就是根据前面在需求分析的过程中，所提炼出的目的及流程，针对性的去设计出满足需求的产品方案。包括但不限于：产品业务流程、产品的功能、页面承载的信息、甚至用户使用的场景等等。
在确认具体方案之前，需要先对需求进行更加详细的分析，才能更好的得出方案，我们结合场景看下，可以如何进行分析。
还是拿前面说过的一个场景：一家做在线英语培训的公司，公司有很多外籍教师，学员大都为中国学生。目前公司的产品经理在每周对需求池当中的原始需求进行整理分析时，发现之前有个叫Zoe的外籍老师上周提出了如下需求：
“希望可以在上课时在网页版的直播间里可以打字，进行答疑，并且在直播课里最好提供举手、邀请某人语音的功能。”
我先给大伙说一个方法论：角色-场景-目的
角色：Zoe（外籍老师）、直播间学员（中国学员）
场景如下图所示：
目的：
经过以上的分析，我们最终会发现，在基于用户原始需求分析出最终的需求，实际上是：
1.目前直播间没有聊天功能，但很多学员都在听课过程中有些不明白的问题，于是希望有可以及时提出问题的地方，老师也可以方便回答。
2.外籍教师在直播间上课过程当中，涉及到想要点学生发言，但老师由于不认识中文，所以没法直接在直播间点名，所以他自己想出的方案是，在直播间让学生能直接举手并邀请对应的人进行问题的回答。
我们汇总一下需求场景和需求目的，如下图所示：
接下来我们基于场景和目的梳理一下业务流程，如下图所示：
推导一下不同场景下可能会产生的功能：
聊到这里，我们可以发现针对原始需求，已经讨论出了多个方案，那最终产品要使用哪套方案去执行呢？有没有一个判断依据呢？
有的！在这里提供一个参考思路：
四、需求分析的工具
我们在前面对需求进行了大量的分析，在过程当中一般会考虑好几种方案，但最终去设计的时候一般只会按照其中一种去执行，怎么去让团队或者需求方也明确结果呢？通常会产出下图所示的需求分析记录表：
既然是表格，能用到的工具还是比较多的：
高频使用工具：Excel
项目管理工具：禅道、TAPD、Tower……
总结一下需求分析的两个高频使用的方法论：
①需求澄清用：3W1H
②需求分析用：角色-场景-目的-方案
最后送给大家一句话：工具毕竟就只是工具，用啥工具不重要，重要的是你会使用方法论进行需求分析！
看完如果对你有用，请点赞、收藏 +关注！
正在持续更新干货中~
