引言

在当今这个信息化飞速发展的时代，各行各业都在追求更高效、更精准的服务模式。在这个背景下，需求跟踪作为项目管理和服务优化的核心环节，其重要性日益凸显。本文将深入探讨需求跟踪的深入分析及其在实际工作中的应用，帮助读者更好地把握需求管理的精髓。

一、需求跟踪的定义

需求跟踪是一种确保项目开发过程中所有需求都被充分理解和实现的方法。它涉及创建和维护需求之间的联系，以便每个需求都可以追溯到它的来源，以及它可以如何影响其他需求和项目的交付物。

需求跟踪矩阵通常用于此目的，这是一种表格或图表，显示了从早期需求文档到最终产品各个阶段的所有需求及其状态。通过需求跟踪，项目团队能够验证是否所有的需求都已经满足，并且可以展示需求是如何在产品中被实现的。这有助于确保项目目标的一致性，提高产品质量，并及时发现和解决问题。

跟踪提供了从产品需求起源到满足产品需求的可交付成果整个过程中对产品需求进行跟踪的能力。

二、需求跟踪矩阵

需求跟踪矩阵有助于确保所有需求都被考虑到，并且在整个项目生命周期中保持一致性。

2.1 需求跟踪矩阵包含的内容

需求跟踪矩阵是一个重要的工具，用于确保所有项目需求都被考虑到，并且在整个产品开发生命周期中得到满足。这个矩阵将帮助我们追踪需求是如何从高层次的商业目标和项目目标细化到具体的功能和设计要求，再到实现和测试阶段的。

以下是需求跟踪矩阵中包含的内容：

1. 商业需求：包括商业问题、计划和目标，这是整个项目的起点，定义了为什么我们需要这个产品以及我们希望通过产品实现什么。
2. 项目目标：这些是具体、可衡量的目标，它们直接支持商业需求。
3. 项目范围/工作分解结构(WBS)可交付成果：这定义了项目的主要组成部分和里程碑，以及每个部分的具体交付物。
4. 产品设计组件：包括界面设计、用户体验、信息架构等，这些都是为了满足项目目标而设计的。
5. 产品开发组件：涉及到技术规格、功能列表、系统架构等，这些都是为了实现设计要求而开发的。
6. 测试策略和测试场景：这些是用来验证产品是否满足需求的方法和步骤。
7. 高层次到更为具体的需求：随着项目的进展，需求会逐渐细化，从抽象的概念到具体的实现细节。
8. 具体到更高层次的需求：有时也需要确保具体的功能和设计决策与整体目标一致。
9. 不同类型相互关联的功能需求：确保所有的功能需求都与其他相关需求相协调，没有遗漏或冲突。

2.2 跟踪矩阵层级

类似大纲方式从高层级开始渐进明细。跟踪矩阵确保了从高层级到具体实现的连贯性和一致性。

需求跟踪矩阵层级通常按照以下方式进行组织：

1. 商业需求：这是最顶层的需求，通常是商业目标或愿景，例如“提高市场份额”或“增加客户满意度”。
2. 项目目标：这些需求是对商业需求的细化，可能是项目目标或业务需求，如“开发一个新的移动应用”或“优化网站性能”。
3. 功能需求：这些是在项目目标基础上进一步细化的需求，可能包括用户故事、任务或特性，如“用户可以通过Facebook账号登录”。
4. 非功能需求：这些需求关注的是系统的质量属性，如性能、安全性或可靠性。
5. 技术需求：这些需求定义了实现功能需求所需的技术规格和标准。
6. 设计需求：这些需求描述了产品的外观和感觉，包括用户界面和用户体验。
7. 测试需求：这些需求定义了如何验证产品是否满足其他所有需求。
8. 交付物：这是项目团队需要创建的实际产出，如设计文档、代码或测试报告。
9. 任务：这是执行交付物所需的行动步骤，可能包括设计、编码或测试任务。
10. 里程碑：这些是项目的关键时间点，标志着重要阶段的完成。

2.3 需求属性

• 需求编号
• 需求的简短文字描述
• 目标
  • 商业需求
  • 商业目的和目标
  • 项目目标
• 产品开发阶段
  • 设计
  • 构建
  • 测试
  • 实施
  • 验证
• WBS
• 状态。例如已激活、已批准、已延期
• 列入的理由
• 优先级
• 负责人
• 来源（需求来自何方）
• 版本
• 完成日期
• 干系人满意度
• 稳定性
• 复杂性
• 验收标准

2.4 参考表格

请注意，这个表格是一个参考模板，可以根据实际情况填充和修改具体内容。

需求属性	需求编号	描述	目标	产品开发阶段	WBS	状态	列入理由	优先级	负责人	来源	版本	完成日期	干系人满意度	稳定性	复杂性	验收标准
描述	唯一标识符	对需求的简短文字描述	商业需求 商业目的和目标 项目目标	设计 构建 测试 实施 验证	工作分解结构中的位置	已激活** 已批准 **已延期	包含该需求的原因	已激活 已批准 已延期	负责该需求的人	需求的来源	需求的版本历史	预期的完成日期	干系人对该需求的满意程度	需求的稳定性	实现需求的难度	确认需求完成的标准

三、需求跟踪的收益

需求跟踪对于确保项目成功至关重要。

3.1 确保商业价值最大化

• 详细阐述商业需求：通过跟踪需求，可以确保所有需求都与商业目标紧密相连，并且详细到足以指导产品开发。
• 避免需求遗漏：跟踪机制可以帮助发现任何可能遗漏的需求，确保没有重要的功能或特性被忽略。
• 明确项目目标：清晰的需求跟踪有助于保持项目目标的一致性和明确性，确保团队朝着正确的方向努力。

3.2 满足客户期望

• 客户需求对齐：跟踪需求可以帮助确保产品开发的方向符合客户的期望和需求。
• 及时反馈循环：通过跟踪客户反馈，可以更快地识别和解决问题，提高客户满意度。

3.3 范围管理

• 控制范围蔓延：明确的需求边界有助于防止项目范围无限制扩展，确保项目不会偏离原定目标。
• 资源优化：确保资源被合理分配给那些真正增加商业价值的需求上。
• 风险管理：通过跟踪需求的状态和影响，可以更好地预测和管理潜在的风险。

3.4 决策支持

• 数据驱动决策：需求跟踪提供的数据可以帮助做出基于事实的决策，而不是仅仅依赖直觉。
• 透明度：整个团队对需求的状态和进展都有清晰的认识，有助于团队成员之间的沟通和协调。

3.5 提高效率和效果

• 减少重复工作：通过跟踪需求的实现情况，可以避免重复开发已经存在的功能。
• 质量保证：需求跟踪有助于确保产品按照既定的质量标准和验收标准进行开发。

3.6 文档化和沟通

• 文档一致性：需求跟踪有助于保持文档的最新状态，确保所有团队成员都有最新的信息。
• 沟通工具：作为沟通的基础，确保所有干系人都对需求有共同的理解。

3.7 变更管理

• 变更控制：当需求发生变化时，需求跟踪可以帮助管理这些变更，确保变更被适当记录和评估。
• 历史记录：需求的历史记录有助于理解其演变过程，以及为何会有这样的变化。

3.8 测量和改进

• 性能测量：可以通过需求跟踪来衡量产品的性能，确定是否达到了预期的结果。
• 持续改进：基于需求跟踪的数据，可以不断改进产品和流程。

四、关系和依赖性

需求跟踪关系和依赖性是确保项目顺利进行的关键因素，因为它们揭示了需求之间的联系和相互作用。

4.1 子集

• 这指的是一个需求是由另一个更大需求（父需求）派生出来的。
  例如，如果一个大的功能需求可以被细分为几个较小的功能点，那么这些小的功能点就是大功能需求的子集。这种关系表明，实现大功能的前提是先实现所有的子功能。

4.2 实施依赖性

• 这涉及到技术上的先后顺序，即某些需求必须在其他需求之后才能实施。
  例如，一个新功能可能依赖于后端服务的更新，因此必须等到后端服务更新完成后才能开始开发。

4.3 收益或价值依赖性

• 这通常关联到商业价值，意味着一个需求的成功实现依赖于另一个需求的实现。
  例如，一个营销活动的成功可能依赖于产品中的某个特定功能，而该功能还未完全开发出来。

在管理这些关系和依赖性时，重要的是要确保所有相关的团队成员都了解它们，并在计划和执行过程中考虑到这些因素。这样可以避免资源浪费和时间延误。

五、批准（已评审）需求

在项目管理和产品开发中，确保需求得到适当的批准是一个关键环节，它涉及到一系列的过程和角色。

5.1 工作授权系统

• 这是一个正式的流程，用于授权项目工作继续进行。它包括了一系列步骤，如提交、审查、批准和记录需求。这个系统确保只有经过适当审查和批准的需求才会进入开发阶段。

5.2 批准级别

5.2.1 对比批准和签字确认

在项目中，"批准"和"签字确认"通常是同义词，但它们也可以有所区别。“批准"通常指的是正式接受或同意某项工作，而"签字确认”
可能只是表明某人已经查看过文档或信息。

5.2.2 对比审议者和批准者

议者通常是那些提供意见和建议的人，他们可能不具有最终决定权。批准者则有权力做出决定并授权行动。

5.2.3 对比批准授权和问责

批准授权是指给予某人批准需求的权利，而问责则是指对结果负责。通常，批准者也需要对其批准的决策负责。

5.2.4 需求否决

如果一个需求被认为不符合项目目标或不可行，它可能会被否决。这时，需要重新评估需求或寻找替代方案。

5.2.5 变更控制委员会（CCB）

• CCB是一个小组，负责审查和批准项目变更。它的存在是为了确保所有变更都经过适当的评估和批准流程。

5.2.6 专家判断

在某些情况下，可能需要专家的意见来决定是否批准一个需求。这通常涉及技术专家或领域专家的输入，以确保决策是基于专业知识和最佳实践。

为了确保这些过程的有效性，通常会有一个详细的批准流程，包括谁有权批准、何时批准以及如何记录批准。这可能涉及到多级审批，以及确保所有相关方都被适当地通知和参与进来

六、基准化已批准（评审）需求

6.1 基准需求的定义

基准需求是由所有获批需求组成的边界，涵盖了项目、项目阶段、迭代、增量、发布或项目任何部分的所有已批准需求。
基准需求确实是项目管理中的一个重要概念。一旦设定，基准需求就成为了后续工作的基础，用于衡量项目进度和变更的影响。以下是关于基准需求的一些关键点：

6.1.1 基准需求的组成

• 基准需求包括所有已被批准的需求，这些需求构成了项目或产品开发的当前目标和范围。

6.1.2 应用场景

• 项目：整个项目的基准需求定义了项目的整体范围。
• 项目阶段：对于分阶段的项目，每个阶段的基准需求定义了该阶段的目标。
• 迭代：在敏捷开发中，每个迭代的基准需求定义了迭代期间要完成的工作。
• 增量：在迭代或增量式开发中，每个增量的基准需求定义了增量应包含的功能。
• 发布：产品的发布基准需求定义了特定发布版本应包含的功能。

6.1.3 基准需求的重要性

• 范围管理：它们提供了项目或产品范围的一个快照，有助于管理范围蔓延。
• 变更控制：任何超出基准需求的新需求都需要经过正式的变更控制流程。
• 进度跟踪：它们为跟踪进度提供了参照点，确保项目按计划进行。
• 沟通工具：基准需求为团队成员、利益相关者和其他相关人员提供了一个共享的理解基础。

6.1.4 基准需求的确定

• 基准需求通常是在项目启动会议或规划会议上确定的，一旦批准，就会成为后续工作的依据。

6.1.5 如何管理基准需求

• 记录和沟通：确保基准需求被详细记录并在所有相关方之间共享。
• 变更请求：任何对基准需求的变更都需要通过正式的变更请求流程。
• 定期审查：随着项目的进展，基准需求应该定期被回顾，以确保它们仍然符合项目目标。

6.2 需求基准、产品范围和项目范围的关系

项目范围和产品范围是密切相关的，但它们关注的焦点略有不同。理解这两者的区别对于有效的项目管理至关重要。
项目范围明确了如何做，而产品范围明确了做什么。需求基准则是这些范围的具体化，它们是项目和产品范围的具体表现形式，定义了项目和产品必须满足的标准和条件。

6.2.1 项目范围

这指的是为交付最终产品、服务或成果所需要完成的所有工作。它包括了项目管理活动、资源、时间表和预算等方面。项目范围定义了项目团队为了实现项目目标必须做的所有事情。

6.2.2 产品范围

产品范围则关注于最终产出本身，即产品、服务或成果所具备的特征和功能。它描述了产品应该如何满足客户的需求和期望。

6.2.3 关系

项目范围和服务范围是相辅相成的。项目范围是为了实现产品范围而存在的。换句话说，项目范围是手段，产品范围是目的。项目团队通过执行项目范围内的工作来创建具有特定产品范围的产品。

6.2.4 需求描述

需求描述了产品、服务或项目成果的特征和功能。它们是详细说明产品范围的工具，帮助确保最终产出满足客户和市场的需要。

6.3 维护产品未完项

维护产品未完成项列表是产品管理中的一个关键任务，它涉及到监控和管理那些尚未解决或尚未完成的需求、功能或其他产品相关的工作。

6.3.1 分类清晰

将未完成项按照类型、优先级和状态进行分类，以便更容易追踪和管理。

6.3.2 优先排序

根据业务价值、紧急程度和影响范围对未完成项进行优先排序，确保团队首先处理最重要的事项。

6.3.3 定期更新和维护

定期更新未完成项的状态，确保信息是最新的，并反映当前的工作重点。

6.3.4 限制在制品（WIP）量

限制同时进行的任务数量，以避免过度承诺和资源分散。

6.3.5 包含背景（上下文）

确保每项未完成的工作都包含了足够的上下文信息，以便团队成员理解其背景和目标。

6.3.6 明确责任

分配责任人，确保每项任务都有明确的责任人和截止日期。

6.3.7 做好变更管理

当需求变更时，及时更新未完成项列表，并通知受影响的利益相关者。

结论

我们可以发现成功的需求跟踪往往具备以下几个特点：

• 一是深入理解客户需求并始终保持与客户的紧密沟通；
• 二是具备预见性和灵活性能够及时调整项目计划和资源配置；
• 三是注重团队建设和沟通协作确保项目团队的高效运转。
  而失败的需求跟踪则往往因为缺乏这些特点而导致项目延误、成本超支和客户满意度下降等问题。

需求跟踪是项目管理中不可或缺的一环它既是一门艺术也是一种实战技能。通过深入理解客户需求、建立完善的需求管理制度、借助专业的工具和技术以及注重团队建设和沟通协作我们可以更好地实现需求跟踪的目标确保项目的成功和客户满意度的提升。