如何做需求分析，方法论 实践举例！

前几天有个粉丝聊天，问了一个关于数据类的需求分析方法，说他工作中遇到的，如何给一个供求关系的数据提需求的指标定义，我简单回答了下，比如要明确需求，要有指标维度，要有量度数据等。

同时，我也想了下，作为产品经理，需求分析是一个最基本的工作，但这个工作，其实蛮多人会遇到问题，尤其是一些比较复杂的需求，或者深层次的，没有接触过的领域，不知道该怎么去分析。

所以，我们今天讲下「产品经理方法论」系列的第二节，如何做需求分析，我们拆分几个方面，方法论和实践举例相结合，尽量让大家更好地理解。

01 需求分析的认知

我们首先讲下需求分析的认知，一些比较基本的内容。

1）什么是需求分析？

需求分析就是你面对的那一些需求或者问题，通过自己的一些分析，得到这个需求或者问题最底层的逻辑，进而输出一些结果。

从产品经理的角度来看，需求分析是一个至关重要的工作环节，它涉及到对市场和用户需求的深入调研、理解、分析和提炼，以找出真正有价值的产品需求，为后续的产品设计、开发、测试等提供明确的方向和输入。

说白了，就是用户提出需求，你需要将其转化为系统语言，怎么转化，这个过程就是需求分析。

2）需求分析的原则有哪些？

我挺喜欢的一句话，透过现象看本质，我觉得这个对于需求分析是真的很形象的概括。需求分析其实就是这个，你的用户对于需求的理解是片面的，或者说表面，你需要做的就是根据他的需求，去分析出背后隐藏的逻辑。

我们再细讲一下几个原则。

• 以用户为中心：要以你的用户为中心，这是最核心的，所有的需求分析都要这样，因为你的用户才是你产品的使用者，对于你的产品才有最真实的话语权，你的产品要实现的目的也是服务于用户。
• 实事求是：要客观、准确，不能过度解读，也不能太过于主观，是什么就是什么。
• 要有整体思维：做需求分析不能只看这一个需求，要结合关联内容，有整体思维，很多需求是牵一发而动全身的，所以要多考虑下。
• 符合市场趋势：尤其是商业化项目，需求是需要符合市场趋势，遵循市场规律的，你不能逆趋势而行，那就是无用需求。
• 技术可实现性：一定要考虑技术可实现性，在上一篇方法论我们聊过，需求不应该是天马行空的，要基于技术能实现，这个是很基本的。
• 考虑成本：任何涉及到钱的都是大事，我们分析需求，是要考虑成本的，不能用户给你提个需求，我们得花很多资源和时间去实现，但是价值又很低，这个就很不划算。
• 尊重用户：如果是定制化需求，用户付费的，那就是另外一个思维，尽量去满足用户，谁会跟钱过不去。

3）需求分析的内容有哪些？

我们可以去分析的内容：

• 用户需求：这个是说得最多的，就是你的用户反馈的需求，可能是公司的，可能是外界收集的，比如说做用户访谈、调查，对用户使用的场景进行整理，从而建立从用户角度出发的需求。
• 产品需求：定义为产品需求，就是产品本身存在的需求，由IT团队，或者公司层面战略规划主动发起的，这个反映了组织机构对系统、产品高层次的目标要求。
• 功能需求：其实前面两个也算是功能需求，这个就是系统必须完成的那些事，即为了向它的用户提供有用的功能，产品必须执行的动作，比如说权限管理，系统设置等。
• 非功能需求：比如性能、响应时间、可靠性、容错性、扩展性等，这个属于功能之外的需求。
• 界面需求：这个就是比较细的内容了，界面的设计，色彩搭配，布局等，或者说用户视觉需求。
• 数据需求：比如说数据获取，数据存储，数据分析等，尤其是在AI时代，数据需求会变得更多，更加复杂，同时也会更加智能化。

02 需求分析的步骤

我们讲下比较通用的步骤。

1）收集需求

首先第一步就是要去收集需求，需求的来源可能是用户，可能是IT团队，不管怎样，先拿到需求。

2）转化需求语言

拿到需求后，就要先将需求转化为系统语言，就是我们按照系统的逻辑去对应的，比如用户的需求想要一个展示销售数据的界面，那你就要想到系统，哪个系统，哪些数据，怎样分析，得到怎样的结果，怎样展示结果等。

3）判断需求真伪

转化为我们熟悉的语言后，就要看看这个需求的“真伪”，这个指的是需求是不是要做的，比如这个需求做了会影响整个系统逻辑，比如不切实际等等，这些都是伪需求。

或者说用户实际想要的内容并不是他说的，这个本质的需求也做不了，这都是要判断的。

4）需求归类

如果这个需求判断可以，能接收，那就要正式往下走了。

先将需求归类，是新增菜单，优化菜单，还是一些bug处理，用户体验提升等，不同的归类会产生不同的影响，对应的难度、工时哪些都不一样。

5）价值评估

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

价值可以按下面几个评估：

• 实际产生收益
• 功能使用频次
• 数据重要性
• 是否影响流程、工作
• 降本增效情况
• 需求紧急程度
• 市场趋势
• …

6）难度评估

这个要结合其他岗位，尤其是技术实现难度，多跟技术去聊下，你看起来很简单的，在技术实现上可能会很复杂。

7）工时评估

或者叫成本评估，工时要综合评估，产品、设计、前后端技术、测试等，都要加上，一般几个岗位的工时比例，产品：设计：前后端技术：测试 = 1：1：（2～3）：1，也就是技术的工时应该是其他的2～3倍，当然，也要看具体需求。

8）输出优先级

根据前面的价值和成本评估，我们可以生成一个四象限，可以看到左上角的应该优先级最高，就是价值越高、成本越低的，付出更少的资源成本可以实现更高价值的需求，这个就是最优先的，相反，右下角的就是最低的了。

9）输出分析结果

把前面的分析结果输出就好了，邮件同步给相关人员，需求的提出方，IT团队的同事们，跟大家确认下。

10）结果评审

这个评审其实有些像版本迭代的流程了，到需求方案评审环节，这个需求分析结果的评审，放这里也行，不提也可以，就是针对上面的结果，找一些关联人员进行评审确认，确认无误了，再进行后续的需求开发。

03 需求分析的方法论&实践举例

这一章是重中之重了，划重点，我们讲几个需求分析的方法论，再辅助一些工作的实践举例，以便于大家更好地理解。

1）“5W2H”分析法

这个很常用，“5W”就是Who、When、Where、Why、What，“2H”就是How、How much。

很好理解，遇到一个需求，按这个分析，就是什么人什么时间在什么地点为什么要做什么，做这些要怎么做，花费多少。

• Who：需求的提出人是谁，自己，还是用户，或者这个需求的受众方是哪些，谁在使用。
• When：什么时候提出的，想要什么时间完成，这个期望值是什么。或者说是在哪个时间场景下，比如双十一之前，这就不一样。
• Where：在什么场景下产生的，环境，背景，我们的产品所处的环境，提出人的用户所处的环境等。
• Why：为什么要提这个需求，背后的逻辑是什么。
• What：这个需求是要实现什么，用户遇到了什么问题，痛点是什么。
• How：用户希望我们怎么办，我们分析后这个需求应该怎么做等。How much：要实现这个需求，我们要投入的成本是多少，比如人力、时间等。

实践举例：

预测地铁口某一个小吃摊一天的营业额。

我们按“5W2H”分析法来分析看看。

• Who：这里就是消费者，地铁口 小吃摊，消费群体是哪一类人。
• When：什么时候，得拆分时间段，比如工作日、周末，比如早、中、晚，不同的时间段消费不一样的，尤其是吃的。
• Where：什么地方，地铁口，一般地铁站在哪，工作区域还是生活区域，哪个城市，毕竟不同的地方消费。
• Why：为什么会来吃，这就要再看看这里是不是景区了，还是因为饿了才吃，侧面可以反映消费群体和地点。
• What：这个需求是什么，就是销售额，怎么计算，单价*销量，根据前面那一些内容，可以预测出小吃摊，单价不会太高，销量也是看哪些场景。
• How much：这里我们的成本就是一个人去现场分时间段预测下，第二个就是这个本身的计算，单价*销量。How：怎么去预测，按时间区分，工作日、周末，按每天的时间段区分，每个时间段统计部分预测人群，计算一些转化率，再结合单价，就可以预测结果了。

2）“HWM”分析法

来源：网络

How Might We，我们可以如何，或者说是有什么办法，这个方法强调以问题为中心，主要激发大家的创造力。

很多人会在头脑风暴前使用，其实就是在讨论一些内容的时候，把这些内容对应的场景和方法，对的、错的都想下，肯定、否定两个方向也都看看，比如你的这个方法可以正向解决哪些问题，另一个方法是不能解决哪些问题的，就是要想到所有的场景，进而再逐个击破。

这个步骤：

发现用户的问题。

思考全部场景，想象全部可能。

分析肯定和否定两个方向的方法。

拆解问题，逐个击破。

得到最终结果。

实践举例：

比如如何提高用户对我们产品的满意度？

用这个方法，我们就要多提问，如何提高，那就有两个方向，哪些方法是肯定可以提高的，哪些方法是不可以的，这些都提出来，为什么不可以，不可以的原因是什么。

比如说可能有功能设计，界面设计，或者一些体验的内容。

我们可以通过优化界面设计来提高用户对我们产品的满意度。

可以增加一些提升体验的功能。

可以多发布一些福利措施。

单纯按我们自己的需求来，这个就是不可以的。

多去跟用户沟通，了解他们的需求，及时反馈。

…

通过使用“How Might We”的提问方式，我们可以将注意力集中在寻找解决问题的方法上，并激发创造力和思考，这种方法可以帮助我们更全面地考虑各种可能的解决方案，并针对具体的问题制定相应的策略和措施。

3）马斯洛需求层次理论

马斯洛需求层次理论是人本主义科学的理论之一，由美国心理学家亚伯拉罕·马斯洛在1943年在《人类激励理论》论文中所提出。书中将人类需求像阶梯一样从低到高按层次分为五种，分别是：生理需求、安全需求、社交需求（归属需求）、尊重需求和自我实现需求。

来源：网络

这个分析就比较深层次了，属于产品设计阶段，对于整个产品的需求分析，可以按照这个逻辑去拆解下，尤其是一些新的C端的产品。

实践举例：

比如我们要开发一款社交App，用这个方法分析下需求。

• 生理需求：这款社交应用首先满足了用户的生理需求，比如通过提供简洁易用的界面和流畅的操作体验，让用户在使用过程中感到舒适和愉悦。
• 安全需求：为了满足用户的安全需求，我们要采取多种安全措施，比如数据加密、隐私保护等，让用户感到在使用应用时不用担心个人信息安全受到威胁。
• 社交需求：在社交需求方面，我们得提供一些丰富的社交功能，比如添加好友、创建群聊、分享动态等，让用户可以轻松地与他人互动和交流，满足用户的社交需求。
• 尊重需求：尊重的这个，我们可以设立了一套积分和等级制度，用户可以通过发布高质量内容、获得他人点赞等方式积累积分和提升等级，从而体验到自己的价值和成就感。
• 自我实现需求：就是可配置的个人页面，我们提供这样的功能，用户可以根据自己的喜好和需求来设计和定制个人主页，展示自己的风格和特点，实现自我表达和自我实现的需求。

4）KANO模型

KANO模型是东京理工大学教授狩野纪昭(Noriaki Kano)发明的对用户需求分类和排序的有用工具。它通过分析用户对产品功能的满意程度，对产品功能进行分级，从而确定产品实现过程中的优先级。

来源：网络

可以看上面的图，对应产生了五种需求（一般是四种，这里多了反向需求）：

• 必备型需求：对于这个产品来说，一定要去做的功能。
• 期望型需求：用户比较期望的，你做得越好，用户满意度越
• 兴奋型需求：像一些创新的功能，一般不太需要花太多的成本，用户使用起来很有吸引力，但通常不会持续。
• 无差异需求：就是做不做无所谓，没有影响。
• 反向需求：用户本身并没有提出，你还去做了，影响还不好，画蛇添足。

实践举例：

比如我们有个购物网站进行改版。

我们按KANO模型分析下，产生了这几个需求。

• 必备型需求：比如网站的加载速度需要更快，页面需要适配移动端设备，比如要打通WMS，实现订单自配送，要调整支付功能，这些都是这个网站必须要有的。
• 期望型需求：比如一些优惠信息，会员功能，促销功能，页面商品视频介绍，自动搭配等，这些都是用户期望有的，你做得越好，用户越喜欢。
• 兴奋型需求：比如加了一个3D试衣间功能，用户可以在线试穿商品，这个其实用户没有需求的，但是你加了，用户满意度会大幅提升。

5）“非理论”的方法

平时用的一些看起来不那么高大上的方法，我直接拿个例子说下，小伙伴们也可以看看，这个是不是也能归属到上面的哪个方法论里。

搭建一套适合公司的付款报销功能。

需求分析，我细一点讲下：

首先我们要考虑几个点：通用、简单、提醒、审核、支付、移动端。

要确定下流程，付款报销的主体流程，分支流程，涉及到哪些部门审核等。

要涉及多少个菜单，是单菜单处理，添加一直到审核完成，还是区分。

分析功能需要具备哪些字段，注意部门、归属部门、类型、币种、原因等。

注意有些类型的字段是否需要单独找个菜单配置，不要固定住。

审核流是怎样的，对应的提醒是怎样，需要钉钉提醒还是邮件提醒，提醒内容是什么，哪个按钮触发提醒。

审核操作是这样，通过、驳回，是否可以灵活配置审核流，比如根据金额大小区分几级。自主撤回的条件怎样。

是否需要打印功能，打印的页面怎样，字段取值。

为方便，移动端要同时触发，这样可以便于审核。

最后的支付是否是对接到支付Api，比如微信支付、支付宝、网银等。

可以想想，看完这个需求分析，你能做出这套付款报销功能么？

04 有什么小技巧

说了这一些方法，我们再分享几个小技巧。

需求分析前，先去了解这个需求的背景，多做点准备工作，这样才能和用户更好地交流。

注意一些询问的技巧，要用用户能听懂的语言，也要听他们的业务语言，切忌用系统语言或者技术语言去沟通。

要学会引导，让用户不单单停留在需求表面，要让他们讲出背后的逻辑，到底想要的内容是什么。

不要事先对需求进行假设，先代入，你的后续聆听、分析，都会受到影响，要持开放态度。

可以借助一些可视化工具进行需求分析，比如图表、流程图等，这样你分析的结果会更直观，更容易让你的用户和IT团队的小伙伴理解。

一定要有优先级排序，要学会合理使用资源，控制资源。

需求变更一定要有事先的说明，尤其是商业化项目，定制化需求，涉及到收费的，提前说好，最好是合同写清楚，要求变更的后续内容，影响，都得同步到相关人员。

需求分析的结果要邮件同步，相关人员确认，避免后续一些不必要的官司。

05 总结一下

产品经理，最基本的工作就是需求分析了，这也是最核心的，很多人会觉得高级的产品经理应该总揽全局，进行规划，但其实细分工作，还是脱离不了需求分析。

这会涉及到产品经理对于用户、市场和业务的理解能力，以及对于收集到的需求的系统化整理、评估、分析的能力。做需求分析时，我们要遵循原则，使用哪些方法论和技巧，以用户为中心，实事求是，充分准备，以用户的语言去和用户深入交流，了解需求背后的隐藏逻辑，去真正实现用户想要的内容。

总体而言，作为产品经理，需求分析是至关重要的，它不仅为产品的设计和开发提供了明确的方向，也为产品的最终成功和市场接受度奠定了基础。

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！