点击蓝字，关注我们
关注【诺儿笔记本】公众号，后台回复【产品电子书】，即可获取产品经理必看书籍
目录
一、关于需求分析
1、什么是需求分析
需求分析是指，产品经理从用户/业务的需求出发，通过分析，确定用户/业务的目的和目标，明确需求或问题的最底层逻辑，将用户/业务需求转化为产品需求，输出解决方案。
简单理解就是判断一个需求为什么做，要解决什么问题，值不值得做，要做成什么样子，要怎么来做才能实现产品目标以及价值最大化。
在做需求分析时，我们需要透过现象看本质，理解用户的真实目的，提出产品的解决方案。
2、需求分析的原则
以用户为中心：要以你的用户为中心，这是最核心的，所有的需求分析都要这样，因为你的用户才是你产品的使用者，对于你的产品才有最真实的话语权，你的产品要实现的目的也是服务于用户。
实事求是：要客观、准确，不能过度解读，也不能太过于主观，是什么就是什么。
要有整体思维：做需求分析不能只看这一个需求，要结合关联内容，有整体思维，很多需求是牵一发而动全身的，所以要多考虑下。
符合市场趋势：尤其是商业化项目，需求是需要符合市场趋势，遵循市场规律的，你不能逆趋势而行，那就是无用需求。
技术可实现性：一定要考虑技术可实现性，在上一篇方法论我们聊过，需求不应该是天马行空的，要基于技术能实现，这个是很基本的。
考虑成本：任何涉及到钱的都是大事，我们分析需求，是要考虑成本的，不能用户给你提个需求，我们得花很多资源和时间去实现，但是价值又很低，这个就很不划算。
尊重用户：如果是定制化需求，用户付费的，那就是另外一个思维，尽量去满足用户，谁会跟钱过不去。
3、需求分析的内容有哪些
用户需求：这个是说得最多的，就是你的用户反馈的需求，可能是公司的，可能是外界收集的，比如说做用户访谈、调查，对用户使用的场景进行整理，从而建立从用户角度出发的需求。
产品需求：定义为产品需求，就是产品本身存在的需求，由IT团队，或者公司层面战略规划主动发起的，这个反映了组织机构对系统、产品高层次的目标要求。
功能需求：其实前面两个也算是功能需求，这个就是系统必须完成的那些事，即为了向它的用户提供有用的功能，产品必须执行的动作，比如说权限管理，系统设置等。
非功能需求：比如性能、响应时间、可靠性、容错性、扩展性等，这个属于功能之外的需求。
界面需求：这个就是比较细的内容了，界面的设计，色彩搭配，布局等，或者说用户视觉需求。
数据需求：比如说数据获取，数据存储，数据分析等，尤其是在AI时代，数据需求会变得更多，更加复杂，同时也会更加智能化。
兼容性需求：兼容性需求包括软件与操作系统、硬件平台、其他软件等的兼容性问题。需要确保软件能够在目标环境中正常运行，并且不会与其他软件发生冲突。
安全性需求：这些需求关注的是软件在长时间运行或面临各种异常情况时，能否保持稳定、可用和安全。需要考虑到各种可能的故障和攻击场景，并制定相应的应对策略。
性能需求：性能需求关注的是软件在运行时需要满足的各项性能指标，如响应时间、吞吐量、并发用户数等。这些指标直接影响用户的使用体验，因此需要进行详细的评估和定义。
二、需求分析的步骤
1、收集需求
在进入正题之前，先介绍一下常见的需求来源，也就是需求通常是从哪里来的：
通过问卷、访谈等用户调研和分析得出
通过深入的行业调研和分析得出
通过现有的数据分析得出
通过竞品调研（或类似功能调研）得出
……
当然，这都是比较理想的情况，现实中的需求往往是这么来滴：
老板提了一个想法
合作部门的某位同事抛了一个需求
某个客户提了一点意见
产品经理发现现有系统需要优化的需求
……
所以，很多时候产品经理会身不由己，要去应付别人提的五花八门的需求，总的来说，需求来源可分为
（1）用户需求
这些需求通常通过用户调研、用户测试、用户反馈等方式获得。用户需求关注的是用户的使用体验，包括产品的易用性、可靠性、安全性以及能否满足用户的特定需求。
（2）业务需求
业务需求是企业或组织对产品或项目的期望和要求，通常与企业的战略目标、业务流程、经济效益等紧密相关，由来源于企业内部。业务需求可能包括提高市场份额、降低成本、增加收入、提高运营效率等。这些需求体现了企业对产品或项目的商业价值和回报的期望。
（3）市场需求
市场需求反映了市场的整体需求水平和潜在机会，对于产品或项目的定位和市场策略至关重要。通过市场研究和分析，可以了解市场的需求和竞争态势，为产品或项目的开发提供指导。
（4）技术需求
这些需求可能包括特定的技术标准、技术架构、系统集成等。技术需求关注的是产品或项目的技术可行性和实现难度，对于项目的成功实施和交付具有重要影响。同时，新技术的出现和应用也可能带来新的技术需求，推动产品或项目的创新和发展。
2、需求整理
我们在收集了一堆需求后，如何从一大堆需求里挑出该做的需求呢？
（1）基于业务场景进行整理
B端产品就关键就在于解决业务场景中遇到的问题。那么，我们可以基于真实的业务场景流程，梳理我们所收集的需求。
比如我设计的产品为企业数据安全，那么其针对的最典型的场景就是数据泄密。基于数据泄密的场景，我们可以梳理出在【泄密监控】-【关键数据外发】-【泄密检测】-【泄密告警】-【泄密举证】-【线下处置反馈】-【持续泄密监控】这一泄密流程中所需要的一切功能和需求点，进而整理出该做的需求。
（2）基于决策链进行整理
B端产品的决策链冗长而又复杂。我们在整理需求时，也可以从Key Person的角度出发，去整理一些针对决策链中关键人物的需求。比如企业数据安全产品，这款产品在企业中涉及到的关键人物如下图：
基于这些关键的决策人物，我们就可以去整理产品的需求，例如：针对CTO，我们的产品所使用的技术一定要够前沿，如使用神经网络分析等等；针对IT运维主管，产品的部署和实施要尽可能简单，最好能旁路部署等等。
（3）基于紧急程度进行整理
这里可以采用大名鼎鼎的四象限法则进行整理，举例如下：
（4）基于整体性进行整理
基于整体性进行整理的意思是，我们在整理需求的时候，既要能够看到产品的细节，也要能够看到产品的宏观。
你可以想象成随时放大/缩小一款产品，这样就不会被局限在某个小细节或者小需求中，能够更全面地去考虑多个需求之间的关联性。
3、分析需求
用户需求只是用户自以为的需求，不够专业，而且有时用户说的并非心中所想，也可能不会表达内心真实需求。
分析需求，就是分析出，哪些用户（who），在哪种场景（where）下，出于什么目的（what），有这样的需求。
搞清楚这些，才能知道这个需求到底是否值得做，优先级是怎么样的，后续应该怎么设计方案（how），除了需要挖掘用户动机寻找真实需求，还需要考虑：
-
该用户是否为目标用户：如果不是产品针对的目标用户，其建议或需求的参考价值可能没那么大。
-
该需求是否符合产品定位：该需求的满足可能会影响产品的核心服务，破坏用户体验。
-
该需求是否能实现：评估这个需求需要多少开发资源或运营能力，价值有多大？
（1）辨别真伪
狭义上的伪需求是指不存在的需求，也就是错把用户诉求当成是需求来解决。
而广义上的伪需求则是没必要去解决的需求，比如不存在普遍性的需求；已有解决方案的需求；以及用户不愿意解决的需求。
在实际应用中，我们可以以逻辑思维寻找归纳、演绎的漏洞
归纳法：从个别经验归纳普遍规律
演绎法：从普遍性结论，推导出个别性结论
（2）价值评估
价值评估是个很重要的环节了，不管是内部需求，还是商业化项目，既然要接，一定是有价值的，要不然投入那么资源和时间处理，就是浪费。价值可以按下面几个评估：
实际产生收益
覆盖面判断：功能使用频次、用户群体、能否规模化等
数据重要性
是否影响流程、工作
降本增效情况
需求紧急程度
市场趋势
…
（3）优先级评估
每家公司的资源都是有限的，需求实现的成本也需要可控，所以作为一个产品经理，学会管理需求，排定需求优先级，也是一个非常重要的能力。
确定需求优先级是个非常重要的环节，它最终决定了产品会提供哪些功能，产品会长成什么样，优秀的产品经理应该在确定需求优先级上有自己清晰的思路。
判断产品需求优先级的主要依据是产品需求的产出投入比，即产品需求的产出价值与投入成本之间的比例。产出投入比越高，代表产品需求的效益越大，产品需求越值得我们开发；反之，产出投入比越低，代表产品需求的效益越小，产品需求越不值得我们投入资源。
产出价值的评估是确认用户使用该功能可以获得什么利益，该功能满足了用户什么需求，有多少用户有这个需求，用户期望产品满足这个需求的迫切程度；
投入成本是指实现产品需求需要投入多少成本，包括开发的人力成本、固定的硬件投入以及日常的运营成本等。
除了产出投入比以外，产品需求优先级的判断还需要重点考虑需求的紧急程度。
我们会经常遇到一些从投入产出比来看不重要的需求，但是因为领导原因或市场变化而很紧急，这时候就需要授予该需求较高的优先级。
对于需求排序，我们可以用到两个方法：四象限法则，P序列
四象限法则：根据重要和紧急程度划分为四个维度，如下图所示：
P序列：按照优先级划分P0>P1>P2>P3>…>Pn，如下图所示：在工作中产品经理经常会碰到多个需求，没办法绝对判断出哪个需求是P1、哪个需求是P2的顺序。
这种情况下，建议按照经验执行就好，不要那么纠结，反而浪费时间。
4、输出分析结果
基于以上分析，输出分析结果，需求分析的输出结果是一个文档，该文档描述了项目的目标、功能、约束、用户群体、操作流程等关键信息。
三、需求分析的方法
1、5w2h分析法
需求分析中的5W2H分析法是一种实用的思考方法，可以帮助我们全面、系统地理解和分析问题。这种分析方法主要包括七个方面：
What——是什么：明确需要解决的问题或实现的目标是什么。这涉及到对问题的定义和范围的界定，是需求分析的起点。
Why——为什么：探究问题产生的背景和原因。通过深入了解问题的根源，我们可以更准确地把握需求，提出更有效的解决方案。
Who——是谁：确定问题的涉及者是谁，包括受影响的群体、利益相关者等。这有助于我们更好地理解他们的需求和期望，从而制定出更符合实际情况的解决方案。
When——什么时候：分析问题发生的时间节点和时序关系。这有助于我们把握问题的紧迫性，合理安排解决方案的实施时间。
Where——在哪里：确定问题发生的地点或范围。了解问题的空间分布和影响因素，有助于我们提出更具针对性的解决方案。
How——怎么做：思考解决问题的具体方法和途径。这包括制定详细的实施计划、采取适当的措施等，以确保解决方案的有效性和可行性。
How much——多少：评估解决问题的成本、效益和资源需求。这有助于我们在制定解决方案时充分考虑经济性和可持续性，确保投入与产出的平衡。
2、HWM分析法
HMW，全称“How Might We”，即“我们可以怎样”，其中：
How：表示我们假设问题是可以解决的，只是我们尚不知道如何解决
Might：暗示现在讨论的想法不用太完美，支出大概有哪些方向即可，问题有无数的解法，我们可以有很宽广的创造空间
We：强调团队的重要性，不是单一成员的努力就可以解决问题，是需要整个团队的力量才可以解决这个问题
How Might We（简称HWM）分析法是一种创新思维工具，通常用于设计思维或用户研究中，帮助团队从用户的角度出发，重新定义问题并探索可能的解决方案。这种方法鼓励团队从用户的角度出发，思考如何满足他们的需求和期望。
可以改变我们固有的思维逻辑方式，防止自己圈定在一个圈层或者方向中，开拓自己的思维层面，不受单种方式的拘束，使得我们在同个问题上可以发散性地对多个方向进行剖析，确保创新者正在使用最佳的措辞提出正确的问题。
HWM分析法的核心步骤包括：
深入了解用户：通过用户访谈、观察、问卷等方式，深入了解用户的需求、痛点和期望。
定义问题：根据收集到的用户信息，将问题或挑战转化为更具体和用户导向的表述。拆解问题的方向：
否定（逆向思维）：如何想办法让用户放弃这个想法
积极（发挥积极影响）：如何让用户提升自己来解决这个问题
转移（移除消极影响/换其他方案）：如何让其他人解决问题，继而解决这个用户的问题
脑洞大开：发散思维，从需求或环境中创造类似的体验，或改变现状……
分解：将大问题拆分成很多小问题
生成HWM问题：基于定义的问题，创建一系列以“How Might We”开头的开放性问题。这些问题旨在激发团队的创新思维，探索可能的解决方案。
讨论与头脑风暴：团队成员针对这些HWM问题进行讨论和头脑风暴，产生各种可能的解决方案或想法。
筛选与优化：评估并筛选出最具潜力和可行性的想法，进一步优化和完善这些解决方案。
3、马斯洛需求层次理论
马斯洛需求层次理论是关于需求结构的理论，包括人类需求的五级模型，通常被描绘成金字塔内的等级，从低到高分为五个层次：生理需求、安全需求、社交需求、尊重需求和自我实现需求
这五个层次的需求像阶梯一样从低到高逐级上升，但这种顺序并不是固定不变的。当低层次的需求得到满足后，人们会追求更高层次的需求。同时，不同个体的需求层次也会有所差异，同一时期内可能存在多种层次的需求。
生理需求：这是人类最基本的需求，包括食物、水、空气、睡眠等。这些需求是满足人体基本生理机能所必需的，如果这些需求得不到满足，人类的生存就会受到威胁。
安全需求：当生理需求得到满足后，人们会追求安全感，以保障生命、财产和健康的安全。这种需求表现为对稳定、秩序和免除恐惧、威胁与痛苦的需求。
社交需求：当生理和安全需求得到满足后，人们会开始追求社交归属感，希望与他人建立关系，如亲情、友情和爱情等。如果社交需求得不到满足，人们可能会感到孤独和失落。
尊重需求：人们都希望自己的能力和成就得到社会的认可和尊重。这种需求分为内部尊重和外部尊重两部分，内部尊重是指个人希望自己在各种情境中有实力、能胜任、充满信心、能独立自主；外部尊重是指个人希望有地位、有威信，受到他人的尊重和高度评价。
自我实现需求：这是最高层次的需求，人们希望发挥自己的潜能，实现自己的理想和目标，追求个人成长和自我价值的实现。如果这一层次的需求得不到满足，人们可能会感到空虚和失落。
4、KANO模型
KANO模型是一个用于分析用户需求的工具，由日本学者狩野纪昭(Noriaki Kano)在1984年提出。该模型旨在将用户需求进行分类和优先排序，以帮助企业更好地满足用户需求，提高产品或服务的满意度。
基本（必备）型需求：顾客对企业提供的产品／服务因素的基本要求。当需求没有实现时，客户很不满意；当需求实现时，客户会觉得理应如此。
期望（意愿）型需求：顾客的满意状况与需求的满足程度成比例关系的需求。当需求没有实现时，客户很不满意；当需求实现时，客户满意。
魅力因素：用户意想不到的，如果不提供此需求，用户满意度不会降低，但当提供此需求，用户满意度会有很大提升。
无差异因素：无论提供或不提供此需求，用户满意度都不会有改变，用户根本不在意。
反向因素：用户根本都没有此需求，提供后用户满意度反而会下降。
5、Y模型
Y模型是一种需求分析方法，主要用于将用户需求转化为产品功能，并深入挖掘需求的本质。
用户需求：在具体业务场景下用户提出的需求，这是用户给出的解决方案。但要注意，这还只是表象，需要进一步挖掘背后的目标和动机。
产品需求：在用户需求的基础上，通过不断地问“为什么”，挖掘出用户的产品需求。这一步需要结合场景思考用户需求，带入用户的角色，同时要考虑用户目标和产品目标，确定合理的解决方案。
马斯洛需求：在产品需求的基础上，深入挖掘需求的第三种深度，即马斯洛需求，或称为需求的本质。这是从人性角度出发的需求分析。
产品功能：根据用户需求深度剖析得出的解决方案，是实施人员能看懂的描述。
6、用户故事地图
用户故事地图是一个视觉化的工具，它帮助团队更好地理解用户的需求和期望。
这个地图是围绕用户的活动、任务和故事构建的，为团队提供了一个清晰、有组织的视图，以确保产品能够满足用户的核心需求。
第一步，进行产品定义。我们要确定我们的用户是谁？解决什么问题？用户目标是什么？产品目标是什么？通过这些问题，可以基本框定整体的范围。
第二步，梳理骨干故事。梳理故事要确定好一级故事、二级故事，保证故事的完整性，同时要广度优先，而非深度。最后的效果就是看到故事群。
第三步，拆分故事。在刚刚梳理的每一个二级故事下面做停留，去拆分二级故事获取更多细节内容。围绕这个故事写更多细节。
第四步，沟通确认。这一步是将前面丰满而又臃肿的故事，通过对标标题、充分讨论，把公认的留下来，无用的剔除掉，同时区分要做的故事细节的优先级。
在实际应用中，用户故事地图的作用主要体现在以下几个方面：
帮助组织确定最佳实践：通过用户故事地图，团队可以清楚地看到用户的实际使用场景和需求，从而决定如何最好地满足这些需求，实现产品的最佳实践。
用故事绘制关键要素：用户故事地图通过描绘用户在使用产品过程中的各种活动和任务，帮助团队识别并理解产品的关键要素，包括功能、性能、交互等。
创建用户路径跟踪器：用户故事地图也是一种用户路径跟踪器，它展示了用户在产品使用过程中的整个流程，从而帮助团队发现可能存在的问题和改进点。
用户故事地图通常包括角色、活动、任务和故事等元素。每个角色都有一系列相关的活动，每个活动又包含多个任务，而每个任务背后都有一个或多个用户故事。
这些故事描绘了用户想要实现的目标以及他们为何需要实现这些目标。
四、需求分析的技巧
需求分析前，先去了解这个需求的背景，多做点准备工作，这样才能和用户更好地交流。
注意一些询问的技巧，要用用户能听懂的语言，也要听他们的业务语言，切忌用系统语言或者技术语言去沟通。
要学会引导，让用户不单单停留在需求表面，要让他们讲出背后的逻辑，到底想要的内容是什么。
不要事先对需求进行假设，先代入，你的后续聆听、分析，都会受到影响，要持开放态度。
可以借助一些可视化工具进行需求分析，比如图表、流程图等，这样你分析的结果会更直观，更容易让你的用户和IT团队的小伙伴理解。
一定要有优先级排序，要学会合理使用资源，控制资源。
需求变更一定要有事先的说明，尤其是商业化项目，定制化需求，涉及到收费的，提前说好，最好是合同写清楚，要求变更的后续内容，影响，都得同步到相关人员。
需求分析的结果要邮件同步，相关人员确认，避免后续一些不必要的官司。
— END —
你“在看”我吗？
