上一篇文章，我们已经带队需求分析进行了简单的描述，了解了什么是需求分析、需求分析的原则、需求分析的内容以及需求分析的技巧。接下来，我们对需求分析的步骤展开进行描述，透过现象看本质，题解用户𣈗真实目的。

需求分析可以简单理解为判断一个需求为什么做，要解决什么问题，值不值得做，要做成什么样子，要怎么来做才能实现产品目标以及价值最大化。

在做需求分析时，我们需要透过现象看本质，理解用户的真实目的，提出产品的解决方案。

下面，我们将对需求分析的步骤展开进行描述：

一、收集需求

在进入正题之前，先介绍一下常见的需求来源，也就是需求通常是从哪里来的：

• 通过问卷、访谈等用户调研和分析得出
• 通过深入的行业调研和分析得出
• 通过现有的数据分析得出
• 通过竞品调研（或类似功能调研）得出

……

当然，这都是比较理想的情况，现实中的需求往往是这么来滴：

• 老板提了一个想法
• 合作部门的某位同事抛了一个需求
• 某个客户提了一点意见
• 产品经理发现现有系统需要优化的需求

……

所以，很多时候产品经理会身不由己，要去应付别人提的五花八门的需求，总的来说，需求来源可分为

1）用户需求

这些需求通常通过用户调研、用户测试、用户反馈等方式获得。用户需求关注的是用户的使用体验，包括产品的易用性、可靠性、安全性以及能否满足用户的特定需求。

2）业务需求

业务需求是企业或组织对产品或项目的期望和要求，通常与企业的战略目标、业务流程、经济效益等紧密相关，由来源于企业内部。业务需求可能包括提高市场份额、降低成本、增加收入、提高运营效率等。这些需求体现了企业对产品或项目的商业价值和回报的期望。

3）市场需求

市场需求反映了市场的整体需求水平和潜在机会，对于产品或项目的定位和市场策略至关重要。通过市场研究和分析，可以了解市场的需求和竞争态势，为产品或项目的开发提供指导。

4）技术需求

这些需求可能包括特定的技术标准、技术架构、系统集成等。技术需求关注的是产品或项目的技术可行性和实现难度，对于项目的成功实施和交付具有重要影响。同时，新技术的出现和应用也可能带来新的技术需求，推动产品或项目的创新和发展。

二、需求整理

我们在收集了一堆需求后，如何从一大堆需求里挑出该做的需求呢？

1. 基于业务场景进行整理

B端产品就关键就在于解决业务场景中遇到的问题。那么，我们可以基于真实的业务场景流程，梳理我们所收集的需求。

比如我设计的产品为企业数据安全，那么其针对的最典型的场景就是数据泄密。基于数据泄密的场景，我们可以梳理出在【泄密监控】-【关键数据外发】-【泄密检测】-【泄密告警】-【泄密举证】-【线下处置反馈】-【持续泄密监控】这一泄密流程中所需要的一切功能和需求点，进而整理出该做的需求。

2. 基于决策链进行整理

B端产品的决策链冗长而又复杂。我们在整理需求时，也可以从Key Person的角度出发，去整理一些针对决策链中关键人物的需求。比如企业数据安全产品，这款产品在企业中涉及到的关键人物如下图：

基于这些关键的决策人物，我们就可以去整理产品的需求，例如：针对CTO，我们的产品所使用的技术一定要够前沿，如使用神经网络分析等等；针对IT运维主管，产品的部署和实施要尽可能简单，最好能旁路部署等等。

3. 基于紧急程度进行整理

这里可以采用大名鼎鼎的四象限法则进行整理，举例如下：

4. 基于整体性进行整理

基于整体性进行整理的意思是，我们在整理需求的时候，既要能够看到产品的细节，也要能够看到产品的宏观。

你可以想象成随时放大/缩小一款产品，这样就不会被局限在某个小细节或者小需求中，能够更全面地去考虑多个需求之间的关联性。

三、分析需求

用户需求只是用户自以为的需求，不够专业，而且有时用户说的并非心中所想，也可能不会表达内心真实需求。

分析需求，就是分析出，哪些用户（who），在哪种场景（where）下，出于什么目的（what），有这样的需求。

搞清楚这些，才能知道这个需求到底是否值得做，优先级是怎么样的，后续应该怎么设计方案（how），除了需要挖掘用户动机寻找真实需求，还需要考虑：

• 该用户是否为目标用户：如果不是产品针对的目标用户，其建议或需求的参考价值可能没那么大。
• 该需求是否符合产品定位：该需求的满足可能会影响产品的核心服务，破坏用户体验。
• 该需求是否能实现：评估这个需求需要多少开发资源或运营能力，价值有多大？

1）辨别真伪

狭义上的伪需求是指不存在的需求，也就是错把用户诉求当成是需求来解决。

而广义上的伪需求则是没必要去解决的需求，比如不存在普遍性的需求；已有解决方案的需求；以及用户不愿意解决的需求。

在实际应用中，我们可以以逻辑思维寻找归纳、演绎的漏洞

归纳法：从个别经验归纳普遍规律

演绎法：从普遍性结论，推导出个别性结论

2）价值评估

价值评估是个很重要的环节了，不管是内部需求，还是商业化项目，既然要接，一定是有价值的，要不然投入那么资源和时间处理，就是浪费。价值可以按下面几个评估：

• 实际产生收益
• 覆盖面判断：功能使用频次、用户群体、能否规模化等
• 数据重要性
• 是否影响流程、工作
• 降本增效情况
• 需求紧急程度
• 市场趋势

…

3）优先级评估

每家公司的资源都是有限的，需求实现的成本也需要可控，所以作为一个产品经理，学会管理需求，排定需求优先级，也是一个非常重要的能力。

确定需求优先级是个非常重要的环节，它最终决定了产品会提供哪些功能，产品会长成什么样，优秀的产品经理应该在确定需求优先级上有自己清晰的思路。

判断产品需求优先级的主要依据是产品需求的产出投入比，即产品需求的产出价值与投入成本之间的比例。产出投入比越高，代表产品需求的效益越大，产品需求越值得我们开发；反之，产出投入比越低，代表产品需求的效益越小，产品需求越不值得我们投入资源。

产出价值的评估是确认用户使用该功能可以获得什么利益，该功能满足了用户什么需求，有多少用户有这个需求，用户期望产品满足这个需求的迫切程度；

投入成本是指实现产品需求需要投入多少成本，包括开发的人力成本、固定的硬件投入以及日常的运营成本等。

除了产出投入比以外，产品需求优先级的判断还需要重点考虑需求的紧急程度。

我们会经常遇到一些从投入产出比来看不重要的需求，但是因为领导原因或市场变化而很紧急，这时候就需要授予该需求较高的优先级。

对于需求排序，我们可以用到两个方法：四象限法则，P序列

四象限法则：根据重要和紧急程度划分为四个维度，如下图所示：

P序列：按照优先级划分P0>P1>P2>P3>…>Pn，如下图所示：在工作中产品经理经常会碰到多个需求，没办法绝对判断出哪个需求是P1、哪个需求是P2的顺序。

这种情况下，建议按照经验执行就好，不要那么纠结，反而浪费时间。

四、输出分析结果

基于以上分析，输出分析结果，需求分析的输出结果是一个文档，该文档描述了项目的目标、功能、约束、用户群体、操作流程等关键信息。

以上就是需求分析的全部步骤啦！