一、需求管理现状

项目需求跟踪管理是一个IT项目建设生命周期中的一个重要开端，也是IT项目建设成功的基石。过往开发失败的IT项目中，80%是由于需求不明确或需求变更没有控制好而造成的。因此一个项目成功的关键因素之一，就是对需求过程进行跟踪与落地。

如今尽管有关软件开发的知识和经验不断丰富，可利用的工具也不断增多，但仍然有相当比例的软件项目失败，原因常常是因为在开始时没有正确地确定和定义需求，或者随着项目的展开没有正确地跟踪需求，对获取到的需求没有进行有效的分析，或者获取到的需求本身就是不准确的。

Visual RM企业级需求管理工具正是解决客户这种需求，构建业务到IT的桥梁，帮助客户业务目标快速实现。需求跟踪管理是关乎IT项目开发成败的重要因素。现在的IT项目中返工开销几乎占了总开发的一半，而导致返工的主要原因是需求分析不明确。从而引发项目开发中的一系列更改。这些更改可能导致浪费大量的资源、IT项目无法按时完成等严重问题。

需求管理框架

Visual RM企业级需求管理工具在需求管理过程中逐步建立”目标－＞业务功能－＞应用系统－＞系统功能”的跟踪关系，让关注需求的每一个涉众理解需求的来龙去脉，实现对需求的跟踪，更好的理解需求。

需求提出到落地跟踪

二、需求提出到落地跟踪的理解

1、你真的了解需求管理吗

需求管理的实质是跟踪并记录用户的需求，并将相关的信息传递给开发团队并保证最终产品与用户需求一致。一个合格的需求规格说明书应该能完整和动态的反映用户的真实需求，但是，由于需求规格说明书这个载体过于沉重，维护代价较高，除非是产品的需求是静态的否则依赖需求规格说明来完成需求管理的模式是注定要失败的。

2、让需求管理有迹可查

大部分公司并不会容许开发人员自由的开发产品，也不赞成产品经理拍拍脑袋就让开发人员实现，希望一切都有记录与可追踪，因此，一般都希望将需求记录下来。这么做还有一个原因，一个不熟悉产品的人可以通过查看这些记录迅速的了解产品的脉络和掌握情况。

3、敏捷模式与传统模式的比较

在传统软件开发模式下，需求是一次性获取，后续几乎不再更新，因此传统模式下业界开发者不得不编写需求规格说明书来假装记录固化的需求。但大多数情况下用户的需求是无法固化的，他们会一次次的提出需求变更，开发团队也就一次次的改写需求规格上，最终开发团队放弃需求规格，使之成为垃圾文件。

需求管理实际上嵌入到敏捷开发的每个地方，从产品负责人给出产品功能列表（product backlog，PB）到开发人员列出本周期开发计划(sprint backlog，SB)都是需求管理的重要组成部分。敏捷需求管理注重项目成员的协作，注重顾客的参与和成员对于项目变化的快速反应。

传统和敏捷开发比较

三、需求落地跟踪遇到的问题解读

1、时间计划

项目实施中，项目经理用甘特图去把控产品的开发负责人、开发周期、工作描述，其中如果遇到版本迭代，参与人数或变动比较频繁的话，多采用visual RM去管理项目的情况。通过甘特图，项目经理可以清清楚楚的看到每一个阶段会有哪些任务，每个任务会消耗的时间或精力，这个就是时间计划。

作为一个项目经理来说，随时随地的知晓自己需求的进度，并且能够及时检验，是对需求负责的一个态度；并且在需求评审落地过程中，如果是大的需求，可能会遗忘一些产品逻辑或细节字段。在使用visual RM工具中，需要注意各个项目任务的前后流程、人员关系，清楚知道时间节点或有评估时间节点。

2、跟踪需求

有的团队可能会是以项目经理或者BOSS直接去跟进需求进度，时刻关注当时的产品是否符合预期或满足其需求。

因为每个团队的项目管理、团队大小不同，其每个团队反馈问题或同步问题的方式或流程也不同。

在创业公司，或许开发就坐PM旁边，任何问题或情况都能马上知晓。但在一定规模的团队或企业中，往往开发人员对一些需求出现了问题，没有进行处理或未完成，PM根据时间节点才能进行追踪到相应环节出现问题的人或部门。

需求跟踪

3、需求落地

需求开发过程中，往往会出现一些需求评审没有出现的问题或技术没办法估计的问题。好的情况是，这个需求经过评审得到开发人员的认可，可以去做，但是需要推迟；不好的情况是，开发人员根本不认可，不去执行！项目经理则说，需求评审时候不提出来，怎么到了执行阶段才提出来。

但是，这个就是执行与会议的区别，每个产品经理都心知肚明。好的产品经理能够在评审中找到关键的难点进行详细评审，没有经验的产品经理往往会以偏概全，不知道最大的坑是在开发过程中。

四、需求跟踪与落地应用解决方案

在某种程度上，需求跟踪提供了一个表明与合同或说明一致的方法。更进一步，需求跟踪可以改善产品质量，降低维护成本，而且很容易实现复用。

1、需求定义与开发活动任务相结合

在用户需求已经确认后，将用户需求进行条目化，把每一条需求形成需求开发任务，借助软件项目管理平台，将其直接推送给需求分析人员，而需求分析人员的分析结果可以通过该平台导出成为格式化的需求规格说明。一旦需求规格说明编写任务完成，管理平台直接推送需求评审任务给相关人员。后续的设计、编码、测试等任务都以类似的方式融入流程。

需求跟踪痕迹记录

2、自动建立需求跟踪矩阵

当进行设计、测试任务时，设计人员/测试人员还应将设计结果、测试用例、测试结果等与需求建立起关联关系，或者是一对一、一对多，又或者是多对一。这样工具就能自动建立起需求跟踪矩阵。

建立需求-设计-开发-测试之间的跟踪关系，进行覆盖和一致性检查，跟踪每项需求都能正确实现。

需求条目覆盖跟踪矩阵

3、需求跟踪融入需求变更实施活动

组织应当在软件开发流程中建立起明确的需求变更流程，并且该流程也已通过IT工具得以固化。

这样，当有需求变更发生时，软件项目管理平台将发起变更流程，由开发人员查看平台建立的需求跟踪矩阵，找到受影响的模块，生成变更影响分析报告，经确认后，发布对受影响的模块进行变更、验证的任务。