专业的短链接生成工具
链接域名
短网址有效期
需求定义不准确，全盘皆输！（B端）
更新时间：2025-5-6 21:48:18 作者：爱短链
严格来说，需求定义不属于需求项目的范畴。
这是产品立项时需要做的事情。
核心工作是建立合理的项目目标和范围…. 严格来说，需求定义不属于需求项目的范畴。
这是产品批准项目时需要做的事情。
核心工作是建立合理的项目目标和范围。
至于项目目标和范围，企业高管通常根据自己的洞察力和经验来确定，有时缺乏集体智慧和科学验证，导致团队实际能力和业务需求偏差，即找不到基本的业务问题或发展机会，项目出现上梁不梁弯曲。
如果方向错误，船舶结构的建设无法承受实际的风暴，那么船只不仅会偏离合理的轨迹，而且会面临风暴，最终做了很多无用的工作。
可以看出，需求定义是一个不容忽视的环节。
需求定义工作需求定义的工作是确定问题或寻找机会。
例如，当一家杂货店发展成一家小型超市，雇佣了几名店员，商品丰富，日交易量增加了几十倍，此时使用EXCLE难以满足数据登记、数据安全性无法保证、业务操作流程无法固定等业务管理需求。
为了解决这个问题，小超市需要一套ERP只有满足企业资源管理的需要，才能使业务有序高效地发展。
也就是说，随着业务量级的增长，企业在资源管理、客户服务等方面会出现业务瓶颈，如资源再利用率低、效率差、流程繁琐无法控制等。
此时，我们需要根据业务发展来确定问题或寻找支持发展战略的机会。
那么我们如何确定问题呢？or机会(目标)？ 一是寻找内部根源，找到项目发起人进行深入沟通；另一种是外部可追溯性。
一些项目的启动可能受到外部环境的影响，如竞争产品同行、新技术趋势等。
此时，我们需要找到参考资料进行研究。
通常，我们根据数据反馈或KPI如何找出问题的根源，准确定义问题，合理解决问题？ 01就问题达成共识1.1准确定义问题。
首先，我们应该清楚地定义这个问题，这涉及到两种技能。
首先，转换思维，即将未知的问题转化为已知的问题。
例如，如果一个朋友欠了钱，不能自己追逐，那么你可以找到他的身份信息来起诉，他不会起诉并不重要，委托一个律师。
通过解决一系列已知的问题来解决根本问题 二是追溯源头。
如果表面问题直接解决，问题往往会被表面问题所掩盖，不仅不能治本，还会带来其他问题。
例如，在一座山上修建了一条长长的汽车隧道。
为防止隧道停电时发生车祸，交通部在隧道入口处写道：进入隧道前请打开前灯！提示语。
然而，不久之后，一些司机抱怨说，由于隧道出口的风景太美，司机经常忘记关灯，导致汽车在返回时断电。
提醒他们出隧道时关掉灯！所以我们解决了问题吗？没有，因为如果司机晚上开车(不同时间)，他会很困惑。
有人说我们可以提醒司机白天进隧道时打开车头灯，出隧道时关掉车头灯；晚上出隧道时不要关掉车头灯！这个方案的缺点是文字太长，司机在高速行驶时没有时间和注意力阅读一段文字。
那么，如何从根本上解决问题呢？在这种情况下，我们对问题的因果关系最终推断为：车没电是因为司机忘记关灯，而忘记关灯是因为缺乏提醒。
那么，解决方案是如何提醒和避免夜行司机的误解呢？答案是提示你的灯亮着吗？这就引导司机关注周围的明暗场景，决定他们的前灯是否应该打开。
这个例子是为了展示我们如何定义和确定基本问题。
1.发现问题的根本原因12.2.1 使用工具分析工具1：鱼骨图分析鱼骨图属于定性分析，有利于我们跟踪问题的根源，使分析人员把问题的原因放在首位，而不是外观，可以让我们概述问题的全景图，也为数据收集和行动提供全面可靠的指导。
具体实施方法如下:1。
独立分析第一步定义的每个问题。
2.群体头脑风暴只找原因而不是解决方案。
3.分类问题，确定问题归属的类型。
例如，常见的人机材料环4。
如果某种原因属于多种类型，并且这种情况多次发生，则可以考虑新的问题类型5。
每个原因都可以考虑what-why-where6.公开讨论所有原因的想法和经验7。
寻找重复性高的原因（即多人提出的）8。
使用检查表收集数据、制作流程图或进行客户调查，9.各种原因的相对强度10。
投票制度达成协议，缩小比较工具的范围2：帕累托图分析鱼骨图更依赖于决策者的经验和洞察力，外部世界是变化的趋势，为了更准确、实时地掌握根本原因，也需要结合帕累托分析。
它的主要功能是利用2/8定律锚定影响问题的最关键和根本原因，优先收集有限的资源。
帕累托分析通常是根据问题发生的原因，从相对频率和大小从高到低排列的直方图，找到解决80%问题的20%原因。
在这里，我们需要收集现有的产品数据和用户反馈进行有针对性的分类统计。
做个比喻，鱼骨图帮助我们找到解决问题的方向靶，而帕累托图则是在目标上环数。
1.2.2 在产品需求定义阶段，确定相关人员和用户之间沟通最多的应该是相应业务的高级人员，方向不能出错。
这是管理层，最后是基层操作人员。
对于产品用户，我们记得对产品的直接用户进行分类，列出各自的特点并进行分析，指导后续的需求分析。
1.2.2 我们可以区分产品的范围和边界来定义解决方案的界限。
支持业务运营的范围是产品涉及的功能和内容，边界是产品和人的责任边界。
在产品划分出子系统后，我们可以在子系统中支持的过程中切边界。
如何确定边界有三个因素需要综合考虑。
首先，我们会考虑资金和资源，也就是说，我们可以做任何我们能做的事情；其次，考虑到性价比和可行性，需求方往往认为所有需求都是最高的优先级，因为他们想在相同的资源投资中获得更高的回报。
在这里，我们需要从可行性和劳动力成本中传达哪些需求应该做，哪些需求不应该做，哪些先做，哪些做，说服需求方。
最后，边界的延伸和创新是罕见的。
最后，边界的延伸和创新相对罕见。
它是基于特定的战略或产品方向做出决策的。
它通常将客户和客户的行为习惯纳入产品的考虑范围，将业务流程延伸到人们身边，提高服务支持的便利性和用户体验。
1.2.4 确定解决方案的约束我们在设计产品时，不能自由发挥，有时基于产品特点、技术要求、外部条件等因素会做一些限制，最好建房子，想建什么样的房子，会受到原材料、基础、土壤、资金、住宅建设政策等条件的限制。
软件产品的约束通常分为技术开发和项目实施两类。
技术开发：技术约束、预期软硬件环境、预期使用环境等。
项目实施：项目预算、行政约束、进度要求、资源支持、环境约束等。
2.1目标需要满足一个好的目标SMART原则是满足五个要素:具体、可测量、可行、相关性和时间限制。
以下表为例。
2.在确定目标后，需求定义的主要任务是围绕范围展开，系统需要做哪些功能服务来支持业务需求。
在文档描述的范围内，我们将产生系统构建图、上下文关系图和需求大纲，简称两图一纲。
2.确定相关人员和用户的目的是指导我们获得具体的执行工作，帮助我们了解这些群体，提高产品的可用性。
通常，我们会收集团体和系统主题的相关经验、技术理解、工作态度、教育程度、语言技能、年龄等，即团体形象建模，其次是他们关注产品或需要实现什么好处。
2.4相关事实和假设是指当前产品存在的问题，如原产品的人机交互极其繁琐，导致效率低下。
假设是指预测未来可能发生的事件，导致产品无法处理，需要列出假设事件，避免现有的解决方案思维不当，导致许多无用的工作。
前面已经说明了需求范围的产出物是两图一纲，而一般逻辑简单的系统可以产生需求大纲。
为了让读者更好地了解如何操作，篇幅会更长，后续作者会详细分享。
项目的目标和范围是指南针，方向错误，所以后续行为不正确，因此，我们应该避免拍头，毕竟，人们总是有认知偏差，根据管理经验洞察力不一定准确，毕竟，系统1有时会蒙蔽我们的眼睛。
文章首发于微信官方账号达云霄，欢迎关注交流。
特别说明：本网站的主要目的是收集与互联网运营相关的干货知识，为运营伙伴提供便利。
本网站收集的公共内容来自互联网或用户的贡献，这并不意味着本网站同意其观点，也不对网站内容的真实性负责。
如有侵权行为，请联系网站管理员删除，。
这是产品立项时需要做的事情。
核心工作是建立合理的项目目标和范围…. 严格来说，需求定义不属于需求项目的范畴。
这是产品批准项目时需要做的事情。
核心工作是建立合理的项目目标和范围。
至于项目目标和范围，企业高管通常根据自己的洞察力和经验来确定，有时缺乏集体智慧和科学验证，导致团队实际能力和业务需求偏差，即找不到基本的业务问题或发展机会，项目出现上梁不梁弯曲。
如果方向错误，船舶结构的建设无法承受实际的风暴，那么船只不仅会偏离合理的轨迹，而且会面临风暴，最终做了很多无用的工作。
可以看出，需求定义是一个不容忽视的环节。
需求定义工作需求定义的工作是确定问题或寻找机会。
例如，当一家杂货店发展成一家小型超市，雇佣了几名店员，商品丰富，日交易量增加了几十倍，此时使用EXCLE难以满足数据登记、数据安全性无法保证、业务操作流程无法固定等业务管理需求。
为了解决这个问题，小超市需要一套ERP只有满足企业资源管理的需要，才能使业务有序高效地发展。
也就是说，随着业务量级的增长，企业在资源管理、客户服务等方面会出现业务瓶颈，如资源再利用率低、效率差、流程繁琐无法控制等。
此时，我们需要根据业务发展来确定问题或寻找支持发展战略的机会。
那么我们如何确定问题呢？or机会(目标)？ 一是寻找内部根源，找到项目发起人进行深入沟通；另一种是外部可追溯性。
一些项目的启动可能受到外部环境的影响，如竞争产品同行、新技术趋势等。
此时，我们需要找到参考资料进行研究。
通常，我们根据数据反馈或KPI如何找出问题的根源，准确定义问题，合理解决问题？ 01就问题达成共识1.1准确定义问题。
首先，我们应该清楚地定义这个问题，这涉及到两种技能。
首先，转换思维，即将未知的问题转化为已知的问题。
例如，如果一个朋友欠了钱，不能自己追逐，那么你可以找到他的身份信息来起诉，他不会起诉并不重要，委托一个律师。
通过解决一系列已知的问题来解决根本问题 二是追溯源头。
如果表面问题直接解决，问题往往会被表面问题所掩盖，不仅不能治本，还会带来其他问题。
例如，在一座山上修建了一条长长的汽车隧道。
为防止隧道停电时发生车祸，交通部在隧道入口处写道：进入隧道前请打开前灯！提示语。
然而，不久之后，一些司机抱怨说，由于隧道出口的风景太美，司机经常忘记关灯，导致汽车在返回时断电。
提醒他们出隧道时关掉灯！所以我们解决了问题吗？没有，因为如果司机晚上开车(不同时间)，他会很困惑。
有人说我们可以提醒司机白天进隧道时打开车头灯，出隧道时关掉车头灯；晚上出隧道时不要关掉车头灯！这个方案的缺点是文字太长，司机在高速行驶时没有时间和注意力阅读一段文字。
那么，如何从根本上解决问题呢？在这种情况下，我们对问题的因果关系最终推断为：车没电是因为司机忘记关灯，而忘记关灯是因为缺乏提醒。
那么，解决方案是如何提醒和避免夜行司机的误解呢？答案是提示你的灯亮着吗？这就引导司机关注周围的明暗场景，决定他们的前灯是否应该打开。
这个例子是为了展示我们如何定义和确定基本问题。
1.发现问题的根本原因12.2.1 使用工具分析工具1：鱼骨图分析鱼骨图属于定性分析，有利于我们跟踪问题的根源，使分析人员把问题的原因放在首位，而不是外观，可以让我们概述问题的全景图，也为数据收集和行动提供全面可靠的指导。
具体实施方法如下:1。
独立分析第一步定义的每个问题。
2.群体头脑风暴只找原因而不是解决方案。
3.分类问题，确定问题归属的类型。
例如，常见的人机材料环4。
如果某种原因属于多种类型，并且这种情况多次发生，则可以考虑新的问题类型5。
每个原因都可以考虑what-why-where6.公开讨论所有原因的想法和经验7。
寻找重复性高的原因（即多人提出的）8。
使用检查表收集数据、制作流程图或进行客户调查，9.各种原因的相对强度10。
投票制度达成协议，缩小比较工具的范围2：帕累托图分析鱼骨图更依赖于决策者的经验和洞察力，外部世界是变化的趋势，为了更准确、实时地掌握根本原因，也需要结合帕累托分析。
它的主要功能是利用2/8定律锚定影响问题的最关键和根本原因，优先收集有限的资源。
帕累托分析通常是根据问题发生的原因，从相对频率和大小从高到低排列的直方图，找到解决80%问题的20%原因。
在这里，我们需要收集现有的产品数据和用户反馈进行有针对性的分类统计。
做个比喻，鱼骨图帮助我们找到解决问题的方向靶，而帕累托图则是在目标上环数。
1.2.2 在产品需求定义阶段，确定相关人员和用户之间沟通最多的应该是相应业务的高级人员，方向不能出错。
这是管理层，最后是基层操作人员。
对于产品用户，我们记得对产品的直接用户进行分类，列出各自的特点并进行分析，指导后续的需求分析。
1.2.2 我们可以区分产品的范围和边界来定义解决方案的界限。
支持业务运营的范围是产品涉及的功能和内容，边界是产品和人的责任边界。
在产品划分出子系统后，我们可以在子系统中支持的过程中切边界。
如何确定边界有三个因素需要综合考虑。
首先，我们会考虑资金和资源，也就是说，我们可以做任何我们能做的事情；其次，考虑到性价比和可行性，需求方往往认为所有需求都是最高的优先级，因为他们想在相同的资源投资中获得更高的回报。
在这里，我们需要从可行性和劳动力成本中传达哪些需求应该做，哪些需求不应该做，哪些先做，哪些做，说服需求方。
最后，边界的延伸和创新是罕见的。
最后，边界的延伸和创新相对罕见。
它是基于特定的战略或产品方向做出决策的。
它通常将客户和客户的行为习惯纳入产品的考虑范围，将业务流程延伸到人们身边，提高服务支持的便利性和用户体验。
1.2.4 确定解决方案的约束我们在设计产品时，不能自由发挥，有时基于产品特点、技术要求、外部条件等因素会做一些限制，最好建房子，想建什么样的房子，会受到原材料、基础、土壤、资金、住宅建设政策等条件的限制。
软件产品的约束通常分为技术开发和项目实施两类。
技术开发：技术约束、预期软硬件环境、预期使用环境等。
项目实施：项目预算、行政约束、进度要求、资源支持、环境约束等。
2.1目标需要满足一个好的目标SMART原则是满足五个要素:具体、可测量、可行、相关性和时间限制。
以下表为例。
2.在确定目标后，需求定义的主要任务是围绕范围展开，系统需要做哪些功能服务来支持业务需求。
在文档描述的范围内，我们将产生系统构建图、上下文关系图和需求大纲，简称两图一纲。
2.确定相关人员和用户的目的是指导我们获得具体的执行工作，帮助我们了解这些群体，提高产品的可用性。
通常，我们会收集团体和系统主题的相关经验、技术理解、工作态度、教育程度、语言技能、年龄等，即团体形象建模，其次是他们关注产品或需要实现什么好处。
2.4相关事实和假设是指当前产品存在的问题，如原产品的人机交互极其繁琐，导致效率低下。
假设是指预测未来可能发生的事件，导致产品无法处理，需要列出假设事件，避免现有的解决方案思维不当，导致许多无用的工作。
前面已经说明了需求范围的产出物是两图一纲，而一般逻辑简单的系统可以产生需求大纲。
为了让读者更好地了解如何操作，篇幅会更长，后续作者会详细分享。
项目的目标和范围是指南针，方向错误，所以后续行为不正确，因此，我们应该避免拍头，毕竟，人们总是有认知偏差，根据管理经验洞察力不一定准确，毕竟，系统1有时会蒙蔽我们的眼睛。
文章首发于微信官方账号达云霄，欢迎关注交流。
特别说明：本网站的主要目的是收集与互联网运营相关的干货知识，为运营伙伴提供便利。
本网站收集的公共内容来自互联网或用户的贡献，这并不意味着本网站同意其观点，也不对网站内容的真实性负责。
如有侵权行为，请联系网站管理员删除，。
