谈需求管理——连载四

通过前面的三篇文章，基本上已经对需求的建立进行了阐述。至此，应该说已经得到了需要管理的内容——系统需求。但在继续之前还想再谈一个问题：请尊重用户需求。

需求的分析方法不重要，需求到底产生什么样的成果也不重要，需求验证的方法更不重要，重要的是用户的真实想法是否得到了体现，需求工程师是否真的把用户的需求真正的放在心里，站在用户角度想着替用户解决问题。万事开头难，这个阶段可以说就是项目的“头”，如果你不尊重用户的需求，后面的工作无论做的如何精细、如何的高质量都是无用的。道理很简单，大家都理解，但是否都可以做到不敢保证。至少在笔者经历的项目中这种问题不止一次发生。所以，在此提个醒。

需求输出完成后，需要建立一套方法来对需求进行有效管理。通常的方法是建立需求矩阵。通过对需求矩阵的管理实现需求跟踪管理。需求矩阵是一个比较好理解的东西，简单的讲，需求矩阵就是将已获取的需求进行分解，然后进行后续任务的跟踪，所有跟踪情况都记录在这个需求矩阵表中。既然是用于跟踪，那么理论上需求矩阵可用于项目中的任何阶段过程，从用户需求到系统需求的跟踪，从系统需求到实现，从需求到测试等等，针对任何一个阶段都可引入需求矩阵进行管理，只不过所有内容都是依据统一标准：需求（真正的统一标准是用户需求，只不过用户需求无法量化，且假设用户需求转化为系统需求是正确的，所以都是依据最终的系统需求，但如果发现系统需求发生错误后，还是会根据系统需求追溯到用户需求进行验证）。

需求矩阵另一个重要的作用是对变更的控制。任何的变更都必须体现在需求矩阵中，便于变更后的跟踪管理。项目的变更是会由多种因素造成的，在任何阶段都可能产生变更，一旦变更许可，就需要考虑变更的管理，通过需求矩阵可以很容易的观察出每次变更的影响范围，有必要的情况下，需要对影响用户需求的内容进行用户评估，评估这种变更是否可以接受。

需求矩阵建立完毕后，需求的第一个阶段（需求建立）就算完成了。剩下的就是对需求的跟踪管理了，依据的就是需求矩阵及建立的需求成果基线。对于需求的管理应该是要做到可跟踪、可追溯，无论是需求实现、变更还是其他，都应该做到以上两点。关于项目过程中如何管理这些需求的变更不在此进行详谈了，还是需要依据不用项目来进行，但无论如何需求的跟踪和追溯是考核过程需求管理的重要指标。

最后需要对需求管理做一个小结：

1.                   请一定要尊重用户需求，不要把自己的思维强加在用户身上；

2.                   需求建立是一个将用户需求转化为系统需求的过程，所以这个时候往往过程比结果更重要；

3.                   需求过程中的任何结论都是要有实际业务做支撑的，或者说都是要有业务基础的，对于业务系统而言，任何功能都是要明确解决一个问题，如果没有解决问题，也就没有存在的必要；

4.                   需求建立完成仅仅是开了一个头，对于需求管理本身才刚刚开始，万事开头难，做好了需求建立的工作只是打了一个好的基础，但并不意味着就可以高枕无忧了。

5.                   需求管理是一个贯穿项目过程始终的内容，所以，任何内容都需全盘考虑，既可以满足需求建立的质量要求，但也要充分考虑后期需求管理及维护的工作量，不要为后期带来过重的工作负担，否则会影响项目。

好了，就这么多了，坦率的讲，此文后面的质量已经开始下降了，好像是在完成任务似的，看来连载还真不是一件容易的事情啊，不过后期会重新对这些内容进行完善的。