分析报告指出，多达76%的项目失败是因为差劲的需求管理，这个是项目失败的最主要原因，比落后的技术、进度失控或者混乱的变更管理还要关键。很多项目往往在开始的时候已经决定了失败，谜底就在谜面上，开始就注定的失败，你后面多努力都很难，注定背锅！
很多PMO和项目经理却没有把需求管理重视起来，甚至认为这只是产品经理的事情，自己只做交付即可，俗话说：好的开始是成功的一半，一开始就没有管理好，注定为后续埋下了很多坑。
项目的全生命周期绝对不是到了需求给你才是项目管理的开始，而是从项目的开始有意向和萌芽开始的，越往前参与越深，你的价值就越大。
今天就分享给大家一个需求管理全过程流程图及详解，供大家参考！****
|-------------|----------------|------------------------------------------------------------------|
| 需求管理全过程管理详解--PMO前沿 |||
| 阶段 | 检查项目 | 详细描述 |
| 需求输入 | 1. 来源可靠性 | 需求是否来自客户、市场调研、业务部门或其他正规渠道，是否有足够的依据和可靠性。 |
| 需求输入 | 2. 充分和准确性 | 需求是否描述清楚，是否完整覆盖了所有有价值的需求信息，如需求的功能、性能、安全等等，是否准确无误。 |
| 需求输入 | 3. 可行性和可实现性 | 需求是否能够实现，是否需要进一步的研究和分析，是否具有实现的可行性。 |
| 需求输入 | 4. 普适性和标准合规性 | 需求是否符合相关标准和规范，是否是产品和服务可扩展的。 |
| 需求输入 | 5. 目标性和实用性 | 需求是否符合产品和业务目标，是否具有实际价值和可用性。 |
| 需求输入 | 6. 可跟踪性和可管理性 | 需求是否能够被有效地跟踪和管理，是否有足够的指标和标准来进行跟踪。 |
| 需求输入 | 7. 优先级和紧急程度 | 需求是否具有优先级和紧急程度，是否需要进行排序和重点关注。 |
| 需求输入 | 8. 规范性和记录整理 | 需求输入是否符合产品需求管理规范，是否有足够的模板和记录档案来支持验证和管理，以及整理形成完整的记录。 |
| 需求检查 | 1. 需求战略一致性 | 提出的需求是否符合产品定位和战略规划。 |
| 需求检查 | 2. 需求体验性 | 需求是否可能造成客户/用户体验下降。 |
| 需求检查 | 3. 需求冲突性 | 需求实现是否会对现有功能造成冲突。 |
| 需求检查 | 4. 需求重复性 | 需求是否与已有需求存在重复或相似之处。 |
| 需求检查 | 5. 规范性 | 需求数据格式、定义是否规范正确。 |
| 需求检查 | 6. 需求可拆分性 | 需求是否可被拆分为多个子需求。 |
| 需求检查 | 7. 需求合规性 | 需求在法律合规性方面是否有风险。 |
| 需求分析 | 1. 功能性和性能要求 | 对需求描述中所涉及的各项功能和性能要求进行详细的分析，以确立具体的实现方案。 |
| 需求分析 | 2. 用户和场景分析 | 对所需求相关的用户类型、使用场景、需求来源和喜好进行分析，以便对需求进行更精准的定义和拆解。 |
| 需求分析 | 3. 技术可行性和设计可行性 | 对所需求的技术方案进行分析评估，以确定实现方案和设计方案是否可行、是否符合产品的技术设定和架构。 |
| 需求分析 | 4. 通用性和扩展性 | 对所需求涉及的通用性和扩展性进行分析，以便在设计阶段考虑扩展性的需求，以及如何保证通用性的需求。 |
| 需求分析 | 5. 成本和人力资源评估 | 对所需求的实现所需的成本和资源进行评估，以便制定实际可行的计划和方案，并在产品设计、研发和运营中合理地考虑成本和人力资源的管理。 |
| 需求分析 | 6. 风险评估 | 对所需求涉及的技术方案、人员、时间、预算等不确定因素进行评估，以及对实现和商业风险进行分析，以便制定相应的应对方案。 |
| 需求分析 | 7. 需求标签和分类 | 对需求进行标注和分类，以方便在后续的计划和实施过程中进行跟踪和管理。 |
| 需求分析 | 8. 与其他需求间的关系 | 对需求与其他需求之间的关系进行分析和评估，以确保需求的整体一致性和高度聚合性。 |
| 需求评审 | 1. 完整性和一致性 | 需求描述是否完整覆盖了所有有价值的需求信息，是否与其他相关需求相互一致。 |
| 需求评审 | 2. 清晰度和明确性 | 需求的描述是否明确，是否不含任何二义性，是否需要进一步详细说明。 |
| 需求评审 | 3. 准确性和规范性 | 需求描述是否准确无误，符合产品和服务的相关标准和规范，是否符合产品需求管理规范。 |
| 需求评审 | 4. 可行性和风险评估 | 需求是否可行，是否需要进一步的研究和分析，是否具有一定的风险，如技术实现难度等。 |
| 需求评审 | 5. 实用性和用户价值 | 需求是否具有实际价值和可用性，是否满足了用户的需求，是否符合市场需求的变化。 |
| 需求评审 | 6. 优先级和紧急程度 | 需求是否具有合理的优先级和紧急程度，是否需要进行排序和重点关注。 |
| 需求评审 | 7. 可跟踪性和可管理性 | 需求是否能够被有效地跟踪和管理，是否有足够的指标和标准来进行跟踪。 |
| 需求评审 | 8. 记录整理和筛选 | 需求检查过后需要将有效、可行的的需求整理成清单的形式进行筛选，形成可实施的计划。 |
| 争议处理 | 1. 争议来源和背景 | 要了解争议的来源和背景，例如对于核心业务功能、创新点、战略目标等是否存在争议。 |
| 争议处理 | 2. 争议关键点和主张 | 确定争议所涉及的具体点和与会者的主张，了解争议的差异和背后的原因。 |
| 争议处理 | 3. 文档和证据准备 | 要准备相应的文档和证据，以便明确提出主张和支持理由，并为工作会议做好充分的准备。 |
| 争议处理 | 4. 参与者和决策机构 | 要确定有关参与者和决策机构，以确保争议的处理和决策过程具有合法性和风险控制。 |
| 争议处理 | 5. 引导和推动协商 | 通过合理的引导、协商和讨论，使争议变为真正的合作机会，并能够就具体方案达成一致的认识。 |
| 争议处理 | 6. 技术实现和成本评估 | 对所涉及的技术方案进行技术评估和成本评估，以确保争议最终决策所选方案的可行性和可持续性。 |
| 争议处理 | 7. 风险评估和规划 | 对所涉及的风险进行评估和规划，以确保争议所选方案的风险控制、防范和预防。 |
| 争议处理 | 8. 需求确认和管理 | 最终确认和管理所选方案中所涉及的需求和责任，确定实现和管理的重点和关键时间点，并进行相应的规划和跟踪。 |
| 计划排期 | 1. 需求优先级 | 评估需求的优先级，并根据其优先级确定具体实施的时间表和截止日期。 |
| 计划排期 | 2. 项目资源 | 评估项目所需的各种资源，包括人员、设备和材料等，并确定它们在什么时间可用。 |
| 计划排期 | 3. 风险评估 | 识别可能延迟或妨碍实现项目目标的风险和障碍，并采取相应措施进行控制和规避。 |
| 计划排期 | 4. 进度追踪和管理 | 设置项目进度和里程碑，并确保它们与实际进展保持一致。及时跟踪进度，并在需要时进行重新调整。 |
| 计划排期 | 5. 依赖关系 | 确定项目中不同需求和任务之间的依赖关系，确保它们之间的关系合理、有效和稳定。 |
| 计划排期 | 6. 可行性和可持续性 | 评估项目实施的可行性和可持续性，并根据所需的资源和时间表制定相应的可持续性方案。 |
| 计划排期 | 7. 人员管理和分配 | 根据项目需求和资源评估确定所需的人员，并进行合理分配和管理。 |
| 计划排期 | 8. 成本和预算 | 评估项目实施所需的成本和预算，并确保其在界面内得到合理的支持。进行项目开销的跟踪、报告和管理。 |
| 需求反馈和复盘 | 1. 用户反馈 | 收集用户的反馈和建议，对用户的需求进行重点分析和处理，以便调整产品设计和功能。 |
| 需求反馈和复盘 | 2. 处理优先级 | 根据收集到的反馈和建议，评估其对产品的影响和重要性，确定所需的优先处理级别。 |
| 需求反馈和复盘 | 3. 设计调整 | 基于用户反馈和建议进行设计调整，改善产品功能、界面和用户体验，以及识别和修复缺陷和漏洞。 |
| 需求反馈和复盘 | 4. 需求复盘 | 在开发和实施阶段，对需求的实现情况进行定期复盘，以确保产品需求与用户需求的一致性和产品质量。 |
| 需求反馈和复盘 | 5. 意见收集 | 搜集相关人员的意见和建议，以便改进需求管理和产品开发的流程和方法。 |
| 需求反馈和复盘 | 6. 项目更新 | 对产品需求和项目进展的更新和公告，以便相关人员了解产品状态和开发进度。 |
| 需求反馈和复盘 | 7. 测试和验证 | 对需求的实现进行测试和验证，评估其对产品质量和用户体验的影响。 |
| 需求反馈和复盘 | 8. 问题解决 | 跟踪和解决在需求实现过程中的问题、错误和差错，以便改进产品质量和需求管理的流程和方法。 |