需求管理在于管理产品研发过程中的客户需求，建立项目相关干系人对需求的共同理解，维护需求与所开发产品之间的一致性，并控制需求的变更。需求管理的重要性不言而喻，在前面讲到的项目启动、项目计划以及接下去要讲的项目监控这几个改进域中，客户需求都是我们开发工作的输入和基础，研发团队存在的意义也是环绕着客户的需求，以满足客户需求、提高客户惬意度为工作的目标，项目管理团队更是如此。本文主要阐述在项目需求管理过程中涉及的主要规程、可能存在的问题、分析这些问题并提出对应的改进措施。
一． 需求管理的规程
关于需求管理，首先要明白它与“需求开发”之间的差别和联系。尽管非常多场景下需求管理和需求开发可能由同一个人或同一个角色来实施，这样的现象在小型团队尤为明显，但需求管理和需求开发是两个完毕不同的改进域，在综述中我们就提到需求管理是属于项目管理类改进域，而需求开发则属于产品管理；在项目计划中我们也崇尚信息传递的不正确称，由项目线来进行需求管理，而由研发线对项目需求进行过滤之后再进行需求开发也是这样的思想的体现。在轻量级过程改进系列的上下文中，项目经理负责需求管理，管理的是用户需求；而产品经理负责需求开发，开发的是产品需求，两者所面临的问题以及改进的方法也是不同的，但正是通过需求管理和需求开发，来自客户的信息通过用户需求来到项目线，再通过产品需求转移到研发线，并通过需求跟踪形成了例如以下的端到端的闭环:
注意，了解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. 用户需求说明书
用户需求说明书主要包含下面要点：
- 系统总体介绍
- 系统功能性需求，包含界面风格、各个功能模块和功能点介绍
- 系统非功能性需求，包含软硬件环境、质量要求等
五．小结
需求管理是项目管理的第三个改进域，相比其它项目管理过程而言，需求管理通常不能独立进行，而须要与产品管理中的需求开发等过程配合实施。本文中的需求管理偏向于用户需求管理，管理用户需求从项目到研发团队再到项目的一个闭环过程。作为研发工作的一种源头，需求管理通常要从过程改进的角度对其进行分析从而确保兴许产品需求开发和研发工作的顺利展开。因为需求管理与需求开发关系比較紧密，下一个改进域我们讨论产品管理中的需求开发。