作为产品经理的基本功，需求分析的技能是每个产品经理都必须要掌握的。本文系统梳理了需求分析的方法和流程，并给出了模型等参考，供各位参考。
需求分析是指，产品经理从用户/业务的需求出发，通过分析，确定用户/业务的目的和目标，明确需求或问题的最底层逻辑，将用户/业务需求转化为产品需求，输出解决方案。
简单理解就是判断一个需求为什么做，要解决什么问题，值不值得做，要做成什么样子，要怎么来做才能实现产品目标以及价值最大化。
在做需求分析时，我们需要透过现象看本质，理解用户的真实目的，提出产品的解决方案。
在进入正题之前，先介绍一下常见的需求来源，也就是需求通常是从哪里来的：
……
当然，这都是比较理想的情况，现实中的需求往往是这么来滴：
……
所以，很多时候产品经理会身不由己，要去应付别人提的五花八门的需求，总的来说，需求来源可分为
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的顺序。
这种情况下，建议按照经验执行就好，不要那么纠结，反而浪费时间。
基于以上分析，输出分析结果，需求分析的输出结果是一个文档，该文档描述了项目的目标、功能、约束、用户群体、操作流程等关键信息。
需求分析中的5W2H分析法是一种实用的思考方法，可以帮助我们全面、系统地理解和分析问题。这种分析方法主要包括七个方面：
HMW，全称“How Might We”，即“我们可以怎样”，其中：
How Might We（简称HWM）分析法是一种创新思维工具，通常用于设计思维或用户研究中，帮助团队从用户的角度出发，重新定义问题并探索可能的解决方案。这种方法鼓励团队从用户的角度出发，思考如何满足他们的需求和期望。
可以改变我们固有的思维逻辑方式，防止自己圈定在一个圈层或者方向中，开拓自己的思维层面，不受单种方式的拘束，使得我们在同个问题上可以发散性地对多个方向进行剖析，确保创新者正在使用最佳的措辞提出正确的问题。
HWM分析法的核心步骤包括：
马斯洛需求层次理论是关于需求结构的理论，包括人类需求的五级模型，通常被描绘成金字塔内的等级，从低到高分为五个层次：生理需求、安全需求、社交需求、尊重需求和自我实现需求
这五个层次的需求像阶梯一样从低到高逐级上升，但这种顺序并不是固定不变的。当低层次的需求得到满足后，人们会追求更高层次的需求。同时，不同个体的需求层次也会有所差异，同一时期内可能存在多种层次的需求。
KANO模型是一个用于分析用户需求的工具，由日本学者狩野纪昭(Noriaki Kano)在1984年提出。该模型旨在将用户需求进行分类和优先排序，以帮助企业更好地满足用户需求，提高产品或服务的满意度。
Y模型是一种需求分析方法，主要用于将用户需求转化为产品功能，并深入挖掘需求的本质。
用户故事地图是一个视觉化的工具，它帮助团队更好地理解用户的需求和期望。
这个地图是围绕用户的活动、任务和故事构建的，为团队提供了一个清晰、有组织的视图，以确保产品能够满足用户的核心需求。
第一步，进行产品定义。我们要确定我们的用户是谁？解决什么问题？用户目标是什么？产品目标是什么？通过这些问题，可以基本框定整体的范围。
第二步，梳理骨干故事。梳理故事要确定好一级故事、二级故事，保证故事的完整性，同时要广度优先，而非深度。最后的效果就是看到故事群。
第三步，拆分故事。在刚刚梳理的每一个二级故事下面做停留，去拆分二级故事获取更多细节内容。围绕这个故事写更多细节。
第四步，沟通确认。这一步是将前面丰满而又臃肿的故事，通过对标标题、充分讨论，把公认的留下来，无用的剔除掉，同时区分要做的故事细节的优先级。
在实际应用中，用户故事地图的作用主要体现在以下几个方面：
用户故事地图通常包括角色、活动、任务和故事等元素。每个角色都有一系列相关的活动，每个活动又包含多个任务，而每个任务背后都有一个或多个用户故事。
这些故事描绘了用户想要实现的目标以及他们为何需要实现这些目标。
需求分析前，先去了解这个需求的背景，多做点准备工作，这样才能和用户更好地交流。
注意一些询问的技巧，要用用户能听懂的语言，也要听他们的业务语言，切忌用系统语言或者技术语言去沟通。
要学会引导，让用户不单单停留在需求表面，要让他们讲出背后的逻辑，到底想要的内容是什么。
不要事先对需求进行假设，先代入，你的后续聆听、分析，都会受到影响，要持开放态度。
可以借助一些可视化工具进行需求分析，比如图表、流程图等，这样你分析的结果会更直观，更容易让你的用户和IT团队的小伙伴理解。
一定要有优先级排序，要学会合理使用资源，控制资源。
需求变更一定要有事先的说明，尤其是商业化项目，定制化需求，涉及到收费的，提前说好，最好是合同写清楚，要求变更的后续内容，影响，都得同步到相关人员。
需求分析的结果要邮件同步，相关人员确认，避免后续一些不必要的官司。
作者：诺儿笔记本，公众号：诺儿笔记本
本文由 @诺儿笔记本 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。