轻量级过程改进之需求管理

需求管理在于管理产品研发过程中的客户需求，建立项目相关干系人对需求的共同理解，维护需求与所开发产品之间的一致性，并控制需求的变更。需求管理的重要性不言而喻，在前面讲到的项目启动、项目计划以及接下去要讲的项目监控这几个改进域中，客户需求都是我们开发工作的输入和基础，研发团队存在的意义也是围绕着客户的需求，以满足客户需求、提高客户满意度为工作的目标，项目管理团队更是如此。本文主要阐述在项目需求管理过程中涉及的主要规程、可能存在的问题、分析这些问题并提出相应的改进措施。

一．需求管理的规程

关于需求管理，首先要明确它与“需求开发”之间的区别和联系。虽然很多场景下需求管理和需求开发可能由同一个人或同一个角色来实施，这种现象在小型团队尤为明显，但需求管理和需求开发是两个完成不同的改进域，在综述中我们就提到需求管理是属于项目管理类改进域，而需求开发则属于产品管理；在项目计划中我们也崇尚信息传递的不对称，由项目线来进行需求管理，而由研发线对项目需求进行过滤之后再进行需求开发也是这种思想的体现。在轻量级过程改进系列的上下文中，项目经理负责需求管理，管理的是用户需求；而产品经理负责需求开发，开发的是产品需求，两者所面临的问题以及改进的方法也是不同的，但正是通过需求管理和需求开发，来自客户的信息通过用户需求来到项目线，再通过产品需求转移到研发线，并通过需求跟踪形成了如下的端到端的闭环:

注意，了解CMMI-DEV模型的朋友可能会发现上面这段描述和这张图与CMMI中的RD、REQM两个过程域中的描述有较大出入：在CMMI中需求调研、需求确认以及用户需求和产品需求的概念都是针对需求开发这个过程域，但这只是说明了需求管理和需求开发应该做些什么事情，而没有说明由谁来做。本文基于下图所示的项目线与产品线的关系，立足于站在项目经理和产品经理的角度上看待需求管理和需求开发这两件事情：

如上图所示，个人认为由项目经理负责对外的面向客户的诸如需求调研、需求确认等工作；由产品经理来负责对内的面向产品的需求开发工作是合理和高效的。这里面实际上只是一些名词的解释和工作的划分问题，是对CMMI模型的一次裁剪，裁剪的依据是团队的组织结构以及具体项目的实施过程。

本文关注需求管理工作，需求管理是一项持续性工作，通常包括的规程有：

1. 需求调研

目的：通过与客户进行直接接触获取来自客户的原始需求，并根据项目实施过程的需要在项目研发启动之后确定该项目中的各项系统需求和客户要求
主要角色：项目经理主导，销售前期可能参与
主要步骤：作为项目实施中的一环，项目经理根据组织级别《调研方案》中的各项调研内容与客户进行沟通并形成项目级别的《调研记录》。调研方案中的部分内容可能已经由销售人员在项目启动之前进行整理并体现在《项目交接单》中，项目经理需要根据销售人员的反馈完善《调研记录》。项目经理就《调研记录》形成初始化的《用户需求说明书》

2. 需求确认

目的：需求确认的目的在于维护用户和研发团队对用户需求的统一认识，确保在系统交付给用户时，用户和项目经理能够对用户需求的范围和完成情况达成一致，避免用户的个人主观意愿和理解对项目的结果造成影响。
主要角色：项目经理主导
主要步骤：项目经理根据《需求确认单》与用户就已调研完成的用户需求进行确认，《需求确认单》是一种Checklist，供用户和项目经理在用户需求上达成一致。

3. 需求跟踪

目的：需求跟踪的目的在于根据用户需求，建立和维护用户需求->产品需求->开发测试结果->用户需求之间的一致性，确保产品依据用户需求进行开发。
主要角色：项目经理主导
主要步骤：需求跟踪的途径是建立和维护一份《需求跟踪表》，通常测试人员是产品需求的最终确认者，所以项目经理需要根据测试人员的反馈，并根据产品需求和用户需求之间的对应关系维护《需求跟踪表》中的需求跟踪矩阵。通常产品需求是对用户需求的一种细化，所以需求跟踪矩阵是用户需求和产品需求之间的映射关系。关于产品需求我们将在“需求开发”中进行展开。

4. 需求变更控制

目的：需求变更控制的目的在于避免范围蔓延和潜变，即控制需求文档的变更，防止发生范围混乱而导致的用户需求确认无法正常进行。需求变更作为项目管理的常见场景，需要通过需求变更管理流程修改原用户需求中的内容，从而产生新的用户需求并付诸于开发。
主要角色：项目经理主导，根据需要销售也可能需要介入
主要步骤：通常需求变更的提出人是用户，项目经理需要根据用户提出的需求变更进行判断和过滤，如果此次变更涉及范围较大，则需要销售人员事先和客户进行沟通和协调并达成在项目合同上的一致；如果变更较小，则项目经理和客户就新的用户需求达成一致之后即可。需求变更的结果是形成新的用户需求，上述的需求调研、需求跟踪和需求确认都可能需要同步更新。需求变更控制的依据是《用户需求说明书》。

二．需求管理中的问题

需求管理是项目范围管理的核心，通常用户需求与项目计划组成项目管理三角形中最重要的范围和时间管理这两个维度。在系统研发过程中，需求作为研发工作的源头发挥其重要作用，很多研发过程中的问题都是由于需求不明确或需求管理不当所造成，需求管理中典型的问题有：

1. 需求调研不充分

需求调研也是一项流程性工作，在每个项目启动之后、研发工作开展之前需要确保进行需求调研。在实际操作过程中，作为用户需求来源的一部分，项目经理团队都认为需求调研是一项必要的工作，但往往缺乏足够的重视和投入导致调研不充分，从而为后续的研发工作埋下隐患。需求调研不充分体现在缺少标准化的调研方案，缺少有效的调研信息保存和传递机制等。

2. 没有区分用户需求和产品需求

需求管理如同项目计划一样，需要在项目线和产品线之间形成信息过滤，过滤的结果就是形成面向用户的用户需求和面向产品的产品需求。如果没有区分用户需求和产品需求，把用户需求直接抛给研发团队、或者把产品需求直接交与用户确认都是不合适的。同时，根据本文第一部分提到的产品线与项目线的关系，用户需求和产品需求的混淆会导致无法确立正确的产品线。

3. 无法建立需求跟踪机制

用户需求和产品需求进行区分之后，势必要建立完善的需求跟踪机制维护用户需求和产品需求之间的双向跟踪关系，从而确保用户需求信息和产品需求信息都能得到跟踪和反馈。缺少需求跟踪机制会导致需求信息失去透明性，并引起由于信息传递过程所导致的不必要沟通成本和不理想的沟通效果。

4. 缺乏需求确认规范

需求确认面向客户，需要建立正式统一的工作规范。项目管理中涉及客户参与的部分都是应该形成规范的，需求确认作为用户需求管理的组成部分，需要在客户和研发团队之间达成一致。如果缺乏需求确认规范，需求的范围和完成情况无法得到客户的认可，导致客户对系统交付不满意无疑会影响到整个研发团队的工作。

5. 需求变更缺乏统一流程

需求变更不可避免，也并不可怕，需要考虑的是一旦产生需求变更，如何通过一个统一流程来应对需求变更，从而使客户、项目经理、研发团队都能对该需求变更达成统一认识并形成新的项目范围，确保后续需求跟踪和系统验收的正确执行。如果各个项目没有形成统一的需求变更控制流程，则来自各方的需求变更势必导致项目线的各自为政以及产品线的工作混乱。

三．需求管理的过程改进

如果一旦形成工作模式，需求管理相比项目计划会简单一点，对需求管理过程改进的切入点包括：

1. 关注需求生命周期

需求本身是有其生命周期的，但根据不同的项目线和产品线的关系，可能会形成不同的表现形式。根据已有产品线功能作为一个起点，通过需求调研进一步明确用户需求，完成需求确认并进行用户需求和产品需求的转化，进行需求跟踪是本文中提到的需求生命周期。关注需求生命周期是进行过程改进和裁剪的基础，如果团队的需求生命周期表现形式有所不同，自然其管理方式也应该有所不同。

2. 关注需求信息传递

个人认为信息透明是研发管理的核心，需求管理也不例外。很多项目上的问题和研发过程中的问题都是和信息传递的效果有直接关系。如何使用一定的沟通媒介和模式确保信息透明同样是需求管理工作所需要关注的一个方面，通过使用电子化、高效的信息管理系统是需求管理的一个有效切入点。

3. 关注客户参与

需求管理具有对内、对外两面性，其中对外的需求调研、需求确认都与基于客户管理，毕竟我们的系统最终是要交付和客户的。如何让客户能够尽量多的参与到需求管理的过程中，确保客户支持并积极配合需求调研等活动，需要项目经理和销售人员确保客户参与到需求管理过程中来，尽量保持客户的思路与我们保持一致。

4. 关注流程规范化

需求管理与后续的需求开发不同，需求管理会更多的偏重于流程性工作，需求调研、需求变更、需求确认等都需要流程的支持和约束，不建议各个项目有自己的工作方式，而应该强调统一和规范。流程的规范化需要过程资产建设作为支持，也需要管理理念的转变和加强。

针对上述切入点，我们梳理需求管理过程改进的模式和实践包括：

1. 建立用户需求和产品需求同步机制

用户需求面向客户和项目，但用户需求即是产品需求的输入也是产品需求的输出。结合本文中提到的项目线/产品线关系，产品线需要项目线作为输入，反过来产品线也为新的项目提供系统功能的基本范围，两者之间需要建立同步机制才能确保需求管理的高效性和时效性，建立产品核心工作小组和产品平台通常是一项好的实践。产品核心工作小组负责产品需求的设计和开发并根据产品平台版本发布系统的产品需求，项目线根据产品需求和项目具体要求形成用户需求；另一方面，项目线收集项目需求并提交给产品核心开发小组确保其能够根据产品平台的建设需要进行需求的梳理和过滤。用户需求和产品需求同步机制能很大限度协助和完善需求管理工作。需求开发和产品平台属于产品管理范畴，关于产品管理我们将在后续系列文章中进行阐述。

2. 使用电子化信息管理平台

确保使用电子化信息管理平台进行需求的跟踪。需求跟踪的表现形式可以是一张简单的需求跟踪表，但需求跟踪表中的内容来自于研发团队日常的研发成果，如果没有高效和透明的信息化管理工具，则统计这些研发成果将是一件成本很高的工作。目前业界主流的项目管理工具都一定程度上支持需求的管理和跟踪功能，这里个人推荐Redmine作为团队的电子化信息管理平台。关于Redmine可参考我的博客：《研发范围和时间的“信息透明化”之Redmine统一平台》。

3. 确立配置管理理念和流程

讲到需求管理就离不开配置管理。需求管理，尤其是变更管理是配置管理中的一个重要组成部分。配置管理中的配置项、基线、版本控制、状态报告等具体活动都应该引入到需求管理过程中来。通过建立粒度合适的基线，并执行变更控制的流程，确保版本控制在需求开发和系统实现中的实现来确保项目各方干系人都能对需求有一致的认识，并能够进行系统更新日志等的管理从而支持需求追述和反馈。

4. 使用Checklist

Checklist是一种简单但很实用的工具，在项目管理中很多地方都可以使用Checklist进行非正式的评审或信息同步，在需求管理过程中也能用来进行需求的控制：需求的调研可以预设需求调研项作为调研方案的一部分；需求的确认同样可以使用Checklist为客户和项目经理自身提供简单的确认结果。Checklist通常表现为语义明确的选择项或是否项，也可以根据具体需求进行灵活调整其表现形式。

四．需求管理的过程资产

1. 调研方案

调研方案主要包括以下要点：

需求调研的范围说明，调研范围来自于项目启动过程中的项目范围描述
需求调研的目标说明，确保客户方和项目经理都能明确调研的目的
需求调研的计划说明，调研的主要工作计划安排
需求调研的提纲，根据具体项目可能包括系统软硬件环境、系统集成的需要、具体业务逻辑的调研等，推荐采用Checklist形式进行组织

2. 调研记录

调研记录主要包括以下要点：

项目基本信息
调研的干系人和调研的方式，如访谈、正式的会议等
调研内容，根据调研方案展开的具体调研项和结果

3. 需求跟踪表

需求跟踪表主要包括以下要点：

用户需求和产品需求的映射关系，可以采用表格或矩阵的形式进行组织，通常确保用户需求的粒度要大于产品需求
需求问题，对需求跟踪过程中的进度、范围等问题进行记录和处理

4. 需求确认单

需求确认单主要包括以下要点：

用户需求的提纲性表述，具体的用户需求可以放在《用户需求说明书》中
用户需求的完成情况整理
用户需求承诺，典型的承诺方式如下：

本需求文档建立在双方对需求的共同理解基础之上，我同意后续的开发工作根据该需求文档开展。如需求发生变化，我们将按照“需求变更控制规程”执行。我明白需求的变更将导致双方重新协商成本、资源和进度等。
甲方负责人签字
乙方负责人签字

5. 用户需求说明书

用户需求说明书主要包括以下要点：

系统整体介绍
系统功能性需求，包括界面风格、各个功能模块和功能点介绍
系统非功能性需求，包括软硬件环境、质量要求等

五．小结

需求管理是项目管理的第三个改进域，相比其他项目管理过程而言，需求管理通常不能独立进行，而需要与产品管理中的需求开发等过程配合实施。本文中的需求管理偏向于用户需求管理，管理用户需求从项目到研发团队再到项目的一个闭环过程。作为研发工作的一种源头，需求管理通常要从过程改进的角度对其进行分析从而确保后续产品需求开发和研发工作的顺利展开。由于需求管理与需求开发关系比较紧密，下一个改进域我们讨论产品管理中的需求开发。