需求管理在于管理产品研发过程中的客户需求，建立项目相关干系人对需求的共同理解，维护需求与所开发产品之间的一致性，并控制需求的变更。需求管理的重要性不言而喻，在前面讲到的项目启动、项目计划以及接下去要讲的项目监控这几个改进域中，客户需求都是我们开发工作的输入和基础，研发团队存在的意义也是围绕着客户的需求，以满足客户需求、提高客户满意度为工作的目标，项目管理团队更是如此。本文主要阐述在项目需求管理过程中涉及的主要规程、可能存在的问题、分析这些问题并提出相应的改进措施。
关于需求管理，首先要明确它与“需求开发”之间的区别和联系。虽然很多场景下需求管理和需求开发可能由同一个人或同一个角色来实施，这种现象在小型团队尤为明显，但需求管理和需求开发是两个完成不同的改进域，在综述中我们就提到需求管理是属于项目管理类改进域，而需求开发则属于产品管理；在项目计划中我们也崇尚信息传递的不对称，由项目线来进行需求管理，而由研发线对项目需求进行过滤之后再进行需求开发也是这种思想的体现。在轻量级过程改进系列的上下文中，项目经理负责需求管理，管理的是用户需求；而产品经理负责需求开发，开发的是产品需求，两者所面临的问题以及改进的方法也是不同的，但正是通过需求管理和需求开发，来自客户的信息通过用户需求来到项目线，再通过产品需求转移到研发线，并通过需求跟踪形成了如下的端到端的闭环:
注意，了解CMMI-DEV模型的朋友可能会发现上面这段描述和这张图与CMMI中的RD、REQM两个过程域中的描述有较大出入：在CMMI中需求调研、需求确认以及用户需求和产品需求的概念都是针对需求开发这个过程域，但这只是说明了需求管理和需求开发应该做些什么事情，而没有说明由谁来做。本文基于下图所示的项目线与产品线的关系，立足于站在项目经理和产品经理的角度上看待需求管理和需求开发这两件事情：
如上图所示，个人认为由项目经理负责对外的面向客户的诸如需求调研、需求确认等工作；由产品经理来负责对内的面向产品的需求开发工作是合理和高效的。这里面实际上只是一些名词的解释和工作的划分问题，是对CMMI模型的一次裁剪，裁剪的依据是团队的组织结构以及具体项目的实施过程。
本文关注需求管理工作，需求管理是一项持续性工作，通常包括的规程有：
需求管理是项目范围管理的核心，通常用户需求与项目计划组成项目管理三角形中最重要的范围和时间管理这两个维度。在系统研发过程中，需求作为研发工作的源头发挥其重要作用，很多研发过程中的问题都是由于需求不明确或需求管理不当所造成，需求管理中典型的问题有：
需求调研也是一项流程性工作，在每个项目启动之后、研发工作开展之前需要确保进行需求调研。在实际操作过程中，作为用户需求来源的一部分，项目经理团队都认为需求调研是一项必要的工作，但往往缺乏足够的重视和投入导致调研不充分，从而为后续的研发工作埋下隐患。需求调研不充分体现在缺少标准化的调研方案，缺少有效的调研信息保存和传递机制等。
需求管理如同项目计划一样，需要在项目线和产品线之间形成信息过滤，过滤的结果就是形成面向用户的用户需求和面向产品的产品需求。如果没有区分用户需求和产品需求，把用户需求直接抛给研发团队、或者把产品需求直接交与用户确认都是不合适的。同时，根据本文第一部分提到的产品线与项目线的关系，用户需求和产品需求的混淆会导致无法确立正确的产品线。
用户需求和产品需求进行区分之后，势必要建立完善的需求跟踪机制维护用户需求和产品需求之间的双向跟踪关系，从而确保用户需求信息和产品需求信息都能得到跟踪和反馈。缺少需求跟踪机制会导致需求信息失去透明性，并引起由于信息传递过程所导致的不必要沟通成本和不理想的沟通效果。
需求确认面向客户，需要建立正式统一的工作规范。项目管理中涉及客户参与的部分都是应该形成规范的，需求确认作为用户需求管理的组成部分，需要在客户和研发团队之间达成一致。如果缺乏需求确认规范，需求的范围和完成情况无法得到客户的认可，导致客户对系统交付不满意无疑会影响到整个研发团队的工作。
如果一旦形成工作模式，需求管理相比项目计划会简单一点，对需求管理过程改进的切入点包括：
需求本身是有其生命周期的，但根据不同的项目线和产品线的关系，可能会形成不同的表现形式。根据已有产品线功能作为一个起点，通过需求调研进一步明确用户需求，完成需求确认并进行用户需求和产品需求的转化，进行需求跟踪是本文中提到的需求生命周期。关注需求生命周期是进行过程改进和裁剪的基础，如果团队的需求生命周期表现形式有所不同，自然其管理方式也应该有所不同。
个人认为信息透明是研发管理的核心，需求管理也不例外。很多项目上的问题和研发过程中的问题都是和信息传递的效果有直接关系。如何使用一定的沟通媒介和模式确保信息透明同样是需求管理工作所需要关注的一个方面，通过使用电子化、高效的信息管理系统是需求管理的一个有效切入点。
需求管理具有对内、对外两面性，其中对外的需求调研、需求确认都与基于客户管理，毕竟我们的系统最终是要交付和客户的。如何让客户能够尽量多的参与到需求管理的过程中，确保客户支持并积极配合需求调研等活动，需要项目经理和销售人员确保客户参与到需求管理过程中来，尽量保持客户的思路与我们保持一致。
需求管理与后续的需求开发不同，需求管理会更多的偏重于流程性工作，需求调研、需求变更、需求确认等都需要流程的支持和约束，不建议各个项目有自己的工作方式，而应该强调统一和规范。流程的规范化需要过程资产建设作为支持，也需要管理理念的转变和加强。
针对上述切入点，我们梳理需求管理过程改进的模式和实践包括：
用户需求面向客户和项目，但用户需求即是产品需求的输入也是产品需求的输出。结合本文中提到的项目线/产品线关系，产品线需要项目线作为输入，反过来产品线也为新的项目提供系统功能的基本范围，两者之间需要建立同步机制才能确保需求管理的高效性和时效性，建立产品核心工作小组和产品平台通常是一项好的实践。产品核心工作小组负责产品需求的设计和开发并根据产品平台版本发布系统的产品需求，项目线根据产品需求和项目具体要求形成用户需求；另一方面，项目线收集项目需求并提交给产品核心开发小组确保其能够根据产品平台的建设需要进行需求的梳理和过滤。用户需求和产品需求同步机制能很大限度协助和完善需求管理工作。需求开发和产品平台属于产品管理范畴，关于产品管理我们将在后续系列文章中进行阐述。
确保使用电子化信息管理平台进行需求的跟踪。需求跟踪的表现形式可以是一张简单的需求跟踪表，但需求跟踪表中的内容来自于研发团队日常的研发成果，如果没有高效和透明的信息化管理工具，则统计这些研发成果将是一件成本很高的工作。目前业界主流的项目管理工具都一定程度上支持需求的管理和跟踪功能，这里个人推荐Redmine作为团队的电子化信息管理平台。关于Redmine可参考我的博客：《研发范围和时间的“信息透明化”之Redmine统一平台》。
讲到需求管理就离不开配置管理。需求管理，尤其是变更管理是配置管理中的一个重要组成部分。配置管理中的配置项、基线、版本控制、状态报告等具体活动都应该引入到需求管理过程中来。通过建立粒度合适的基线，并执行变更控制的流程，确保版本控制在需求开发和系统实现中的实现来确保项目各方干系人都能对需求有一致的认识，并能够进行系统更新日志等的管理从而支持需求追述和反馈。
调研方案主要包括以下要点：
调研记录主要包括以下要点：
需求跟踪表主要包括以下要点：
需求确认单主要包括以下要点：
本需求文档建立在双方对需求的共同理解基础之上，我同意后续的开发工作根据该需求文档开展。如需求发生变化，我们将按照“需求变更控制规程”执行。我明白需求的变更将导致双方重新协商成本、资源和进度等。
甲方负责人签字
乙方负责人签字
用户需求说明书主要包括以下要点：
需求管理是项目管理的第三个改进域，相比其他项目管理过程而言，需求管理通常不能独立进行，而需要与产品管理中的需求开发等过程配合实施。本文中的需求管理偏向于用户需求管理，管理用户需求从项目到研发团队再到项目的一个闭环过程。作为研发工作的一种源头，需求管理通常要从过程改进的角度对其进行分析从而确保后续产品需求开发和研发工作的顺利展开。由于需求管理与需求开发关系比较紧密，下一个改进域我们讨论产品管理中的需求开发。
原文地址：http://blog.csdn.net/lantian08251/article/details/40735421
