专业的短链接生成工具
链接域名
短网址有效期
一个需求经过大脑的过程：需求分析评估方法
更新时间：2025-5-6 03:12:36 作者：爱短链
一个需求通过大脑，大脑判断它，整个过程只是一瞬间。
作者将这个过程具体到书面，总结了它，并使用文章中的方法来评估需求，希望能对产品所有者有一定的灵感和帮助。
需求分析是产品设计的前沿过程。
由于产品经理处于沟通的中心，我们需要在很短的时间内评估需求的价值，并给出解决方案。
产品经理脑海中需求的过程是什么？本文将从需求分析、拆卸和优先评价三个维度分享一些方法，希望能给您带来一些灵感。
一、需求分析方法 1. 基本元素分析法 图1-需求的基本元素 从需求的完整性出发，第一种方法是挖掘真正的需求。
一个完整的需求至少需要图1中的四个元素，即： 1.1 需求的背景 需求的背景是指动机，本质上是同理心，它可以帮助我们从业务方的角度理解需求，使用场景和用户心理。
在实际工作中，我们收到的需求往往不清楚、不完整，甚至具有欺骗性。
我们的职责是一个问题对应许多解决方案，找到真正的需求。
1.2 需求的受众 观众需要注意两个问题： 谁是真正的观众； 观众是否具有代表性。
需求来源很多，可能是用户、业务方等。
我们需要区分谁才是真正的受众。
不同的角色在需求中有不同的认知和需求，当信息带来主观判断时，就会被污染。
其次，是覆盖问题。
对于频率不够高或人口不够具代表性的需求，投入产出比将是一个大问号。
区分受众，在评估需求优先级和制定解决方案时，混乱将大大降低。
1.3 需求的目的 需求的目的是指需要做什么。
很多时候，我们收到的需求实际上是业务方过滤后的解决方案。
以口渴为例。
此时，业务方提出的需求是制造饮水机，但饮水机无法解决问题。
如果我们发现背后的动机是口渴，我们可以从补充水分和减少水分流失开始提供解决方案。
1.4 需求的目标 解释汉语词典的目的是期望，目标是结果。
目标更具体，可以用数据指标来衡量，后续也可以指导需求的改进。
需求的本质是创造价值，而创造价值最直接的是开源和节流。
具体到目标，可以量化创造的收入，提高效率，节约资源。
2. 因果关系分析法 当需求有上述四个要素时，下一步是分析逻辑是否足够严格，我们可以在这里使用因果分析。
图2-需求目的推导 图2用因果关系表达:因为用户的某种原因，我想做点什么。
如图3所示： 图3-因果关系类型 穷举结束后，我们开始辩证地辩证因果关系： 原因是真的吗？ 这个原因会导致这个结果吗？ 这个结果还有其他原因吗？ …… 前阵子刚收到一个典型的需求: “因为APP注册页面修改，导致注册数据下降，需要优化APP注册页面。
将这个例子代入上述三个问题： APP注册页面是否修改？答:修改。
APP改版注册页面肯定会导致注册数据下降吗？答:不一定，只能回答。
注册数据下降，优化APP注册页面一定有效吗？答:不一定，只能回答。
有没有其他原因导致注册数据下降？答:渠道推广减少，渠道匹配度低，平台新活动减少。
经过这样的分析，我们会发现需求的逻辑存在问题，业务方将相关关系转化为因果关系，将相关原因转化为直接原因。
对于各种原因造成的结果，数学中会用多元化的回归分析来发现问题。
只关注一点，这种需求经不起推敲。
3. 公式法 在明因果后，我们开始进一步细化。
假设上述注册人数的下降仅受到影响APP如图4所示： 图4-用户路径 方法也很简单，用户每一步都可以按时间顺序绘制。
绘制完成后，我们发现影响注册数据的原因可能是下载前流量减少或后续环节流失率增加。
在这里，我们将抽象需求转换为具体公式，并根据公式优化每个环节的数据指标。
根据图4，我们可以列出以下公式： APP注册人数=手机号注册人数 微信注册人数 微信注册人数=进入注册页面的人数-进入注册页面的人数*跳失率-登录人数-点击手机号登录注册人数- 手机号注册人数=进入注册页面的人数-进入注册页面的人数*跳失率-登录人数-点击微信登录注册人数-进入手机号登录页面人数*跳失率-选择切换登录方式-输入手机号码未获得验证码-输入验证码未登录 对比列出的公式和最近的数据，我们可以发现哪个链接的数据指标下降了，优化数据指标是我们的需求。
二、拆解需求 当我们知道该做什么时，下一步是拆除需求，以建立产品设计框架。
我推荐这个链接UML拆解法。
UML（Unified Modeling Language）中文翻译是一种统一的建模语言，主要用于系统设计。
这是一种很好的解构方法，可以帮助我们在产品设计中更清晰、更全面（对这种方法感兴趣的朋友可以阅读相关书籍，这里只做一个简要的介绍）。
1. 用例图 图5-用例图 用例图（Use Case Diagram）它是一组用例、参与者及其关系的图片。
在这里，左边的参与者（Actor）不仅是真实用户，还有相关系统，可以帮助我们梳理相关业务方，明确系统的边界和功能。
目前，互联网上有一些产品在倒推PRD文章或体验报告的拆卸方法是从页面开始向后推。
我个人认为这种方式会有一些不当的选择，我们应该从用户和系统的层面来设计功能。
2. 时序图 图6-时序图例图 时序图在百度百科全书中的解释是：通过描述对象之间发送信息的时间顺序，显示多个对象之间的动态合作。
它可以表示用例的行为顺序。
当执行用例行为时，每个消息对应于一个类操作或状态机中引起的转换触发事件。
简而言之，时序图是功能与内外系统之间的交互，表示每一步的请求和返回数据的过程。
时序图与产品工作中使用的泳道图非常相似。
理解时序图可以帮助我们理解系统的边界和耦合程度。
如果在产品设计中经常写相同的功能逻辑，可以考虑将其抽象成业务方使用的单独中间平台系统，节约资源，使设计系统更具延展性。
3. 状态机 图7-状态机例图 用例用于枚举功能，时间序列用于理解系统的交互。
在产品设计中，有一种非常常见的设计是状态转换，这是用例图和时间序列图无法覆盖的。
如权限控制、用户交互切换、状态转移等。
更具体的例子可以参考电子商务平台上的前端、中后端交互和订单状态切换。
我们将使用状态机来描述这些场景。
状态机一般指有限状态机，表示有限状态和这些状态之间的转移和动作。
对于复杂的状态，文本描述将相对较弱，此时状态机可以派上用场。
以上三个图像是产品经理需要理解的，这也是技术评估中接触到的知识点。
这里不建议用这种方式写需求文档，而是学习UML解构需求的方法。
在系统设计中，产品经理还需要关注数据库的表结构设计，这将影响后续数据是否可以提取。
三、评估需求优先级 最后一个环节是需求优先级的评估。
我常用的方法是选择影响优先级的因素并设置比例。
优先级加权计算后，分数越高，优先级越高。
公式如下： 优先级=因素1比例*因素1分值 因素2比例*因素2分值 …. 表1-需求评估加权表 影响这张表的主要因素有两个:投入产出比和重要性。
个人认为投入产出比是必须的，重要维度可以根据实际情况增减。
同样，加权中的比例也是如此。
在这三个环节之后，需求分析大致结束了。
在需求分析中，我们不需要坚持特定的方法，适合是最好的。
没想到脑子里快速完成的过程写了这么多，谢谢你看到这里，谢谢。
特别说明：本网站的主要目的是收集与互联网运营相关的干货知识，为运营伙伴提供便利。
本网站收集的公共内容来自互联网或用户的贡献，这并不意味着本网站同意其观点，也不对网站内容的真实性负责。
如有侵权行为，请联系网站管理员删除，。
作者将这个过程具体到书面，总结了它，并使用文章中的方法来评估需求，希望能对产品所有者有一定的灵感和帮助。
需求分析是产品设计的前沿过程。
由于产品经理处于沟通的中心，我们需要在很短的时间内评估需求的价值，并给出解决方案。
产品经理脑海中需求的过程是什么？本文将从需求分析、拆卸和优先评价三个维度分享一些方法，希望能给您带来一些灵感。
一、需求分析方法 1. 基本元素分析法 图1-需求的基本元素 从需求的完整性出发，第一种方法是挖掘真正的需求。
一个完整的需求至少需要图1中的四个元素，即： 1.1 需求的背景 需求的背景是指动机，本质上是同理心，它可以帮助我们从业务方的角度理解需求，使用场景和用户心理。
在实际工作中，我们收到的需求往往不清楚、不完整，甚至具有欺骗性。
我们的职责是一个问题对应许多解决方案，找到真正的需求。
1.2 需求的受众 观众需要注意两个问题： 谁是真正的观众； 观众是否具有代表性。
需求来源很多，可能是用户、业务方等。
我们需要区分谁才是真正的受众。
不同的角色在需求中有不同的认知和需求，当信息带来主观判断时，就会被污染。
其次，是覆盖问题。
对于频率不够高或人口不够具代表性的需求，投入产出比将是一个大问号。
区分受众，在评估需求优先级和制定解决方案时，混乱将大大降低。
1.3 需求的目的 需求的目的是指需要做什么。
很多时候，我们收到的需求实际上是业务方过滤后的解决方案。
以口渴为例。
此时，业务方提出的需求是制造饮水机，但饮水机无法解决问题。
如果我们发现背后的动机是口渴，我们可以从补充水分和减少水分流失开始提供解决方案。
1.4 需求的目标 解释汉语词典的目的是期望，目标是结果。
目标更具体，可以用数据指标来衡量，后续也可以指导需求的改进。
需求的本质是创造价值，而创造价值最直接的是开源和节流。
具体到目标，可以量化创造的收入，提高效率，节约资源。
2. 因果关系分析法 当需求有上述四个要素时，下一步是分析逻辑是否足够严格，我们可以在这里使用因果分析。
图2-需求目的推导 图2用因果关系表达:因为用户的某种原因，我想做点什么。
如图3所示： 图3-因果关系类型 穷举结束后，我们开始辩证地辩证因果关系： 原因是真的吗？ 这个原因会导致这个结果吗？ 这个结果还有其他原因吗？ …… 前阵子刚收到一个典型的需求: “因为APP注册页面修改，导致注册数据下降，需要优化APP注册页面。
将这个例子代入上述三个问题： APP注册页面是否修改？答:修改。
APP改版注册页面肯定会导致注册数据下降吗？答:不一定，只能回答。
注册数据下降，优化APP注册页面一定有效吗？答:不一定，只能回答。
有没有其他原因导致注册数据下降？答:渠道推广减少，渠道匹配度低，平台新活动减少。
经过这样的分析，我们会发现需求的逻辑存在问题，业务方将相关关系转化为因果关系，将相关原因转化为直接原因。
对于各种原因造成的结果，数学中会用多元化的回归分析来发现问题。
只关注一点，这种需求经不起推敲。
3. 公式法 在明因果后，我们开始进一步细化。
假设上述注册人数的下降仅受到影响APP如图4所示： 图4-用户路径 方法也很简单，用户每一步都可以按时间顺序绘制。
绘制完成后，我们发现影响注册数据的原因可能是下载前流量减少或后续环节流失率增加。
在这里，我们将抽象需求转换为具体公式，并根据公式优化每个环节的数据指标。
根据图4，我们可以列出以下公式： APP注册人数=手机号注册人数 微信注册人数 微信注册人数=进入注册页面的人数-进入注册页面的人数*跳失率-登录人数-点击手机号登录注册人数- 手机号注册人数=进入注册页面的人数-进入注册页面的人数*跳失率-登录人数-点击微信登录注册人数-进入手机号登录页面人数*跳失率-选择切换登录方式-输入手机号码未获得验证码-输入验证码未登录 对比列出的公式和最近的数据，我们可以发现哪个链接的数据指标下降了，优化数据指标是我们的需求。
二、拆解需求 当我们知道该做什么时，下一步是拆除需求，以建立产品设计框架。
我推荐这个链接UML拆解法。
UML（Unified Modeling Language）中文翻译是一种统一的建模语言，主要用于系统设计。
这是一种很好的解构方法，可以帮助我们在产品设计中更清晰、更全面（对这种方法感兴趣的朋友可以阅读相关书籍，这里只做一个简要的介绍）。
1. 用例图 图5-用例图 用例图（Use Case Diagram）它是一组用例、参与者及其关系的图片。
在这里，左边的参与者（Actor）不仅是真实用户，还有相关系统，可以帮助我们梳理相关业务方，明确系统的边界和功能。
目前，互联网上有一些产品在倒推PRD文章或体验报告的拆卸方法是从页面开始向后推。
我个人认为这种方式会有一些不当的选择，我们应该从用户和系统的层面来设计功能。
2. 时序图 图6-时序图例图 时序图在百度百科全书中的解释是：通过描述对象之间发送信息的时间顺序，显示多个对象之间的动态合作。
它可以表示用例的行为顺序。
当执行用例行为时，每个消息对应于一个类操作或状态机中引起的转换触发事件。
简而言之，时序图是功能与内外系统之间的交互，表示每一步的请求和返回数据的过程。
时序图与产品工作中使用的泳道图非常相似。
理解时序图可以帮助我们理解系统的边界和耦合程度。
如果在产品设计中经常写相同的功能逻辑，可以考虑将其抽象成业务方使用的单独中间平台系统，节约资源，使设计系统更具延展性。
3. 状态机 图7-状态机例图 用例用于枚举功能，时间序列用于理解系统的交互。
在产品设计中，有一种非常常见的设计是状态转换，这是用例图和时间序列图无法覆盖的。
如权限控制、用户交互切换、状态转移等。
更具体的例子可以参考电子商务平台上的前端、中后端交互和订单状态切换。
我们将使用状态机来描述这些场景。
状态机一般指有限状态机，表示有限状态和这些状态之间的转移和动作。
对于复杂的状态，文本描述将相对较弱，此时状态机可以派上用场。
以上三个图像是产品经理需要理解的，这也是技术评估中接触到的知识点。
这里不建议用这种方式写需求文档，而是学习UML解构需求的方法。
在系统设计中，产品经理还需要关注数据库的表结构设计，这将影响后续数据是否可以提取。
三、评估需求优先级 最后一个环节是需求优先级的评估。
我常用的方法是选择影响优先级的因素并设置比例。
优先级加权计算后，分数越高，优先级越高。
公式如下： 优先级=因素1比例*因素1分值 因素2比例*因素2分值 …. 表1-需求评估加权表 影响这张表的主要因素有两个:投入产出比和重要性。
个人认为投入产出比是必须的，重要维度可以根据实际情况增减。
同样，加权中的比例也是如此。
在这三个环节之后，需求分析大致结束了。
在需求分析中，我们不需要坚持特定的方法，适合是最好的。
没想到脑子里快速完成的过程写了这么多，谢谢你看到这里，谢谢。
特别说明：本网站的主要目的是收集与互联网运营相关的干货知识，为运营伙伴提供便利。
本网站收集的公共内容来自互联网或用户的贡献，这并不意味着本网站同意其观点，也不对网站内容的真实性负责。
如有侵权行为，请联系网站管理员删除，。
