需求变更管理

需求变更管理

​ 需求变更的定义：根据软件工程思想定义，需求说明书一般需要经过论证，如果在开发说明书经过论证以后，需要在原有需求基础上追加和补充新的需求，对原有需求进行修改或削减，都属于需求变更

​ 软件研发项目的需求本身就有模糊、变化、主观、不确定这些特征，相较于制造、建筑等传统产业，客户变更软件需求，是软件开发与生俱来的特性，是一个无法避免的事实。

​ 需求变更是万恶之源，为项目的正常开展带来种种不确定性。需求变更的来源是多种多样的，如客户临时改变想法、项目预算增减、技术实现方案遇到了问题等，需求变更一旦决定实施，往往意味着不得不修改架构设计、代码实现、项目计划等等，如果这个过程缺乏控制过程或者控制过程无效，大概率引起项目的成本、质量、进度出现问题，对团队也会产生比较严重的打击。

​ 需要区分需求变更和范围蔓延的概念，范围蔓延一定伴随着变更行为，变更却不一定是范围蔓延。如甲方要求增加需求，但会相应的增加预算，就不属于范围蔓延。

需求变更的原因

变更本身是无法避免的，变更也不是目的。需求变更常见的原因包括：范围变化、进度变化、成本变化、质量变化、风险问题、资源问题、采购问题、相关方沟通问题等。需求变更是为了更好的实现项目目标，达成团队和客户共同成功的双赢目标。

需求定义不明确

​ 渐进明细的需求：项目起始阶段，甲方往往只是有大概想法，只能基于逻辑的分析和预测进行需求描述，难以明确具体的落地思路和预期。随着项目的推进，会有更多的信息产生，这些信息在帮助进一步细化需求的同时也可能会引入一些需求的变更。

​ 合同签署的不明确，在项目招投标阶段，为了尽快签署合同，往往在需求还没明确的阶段，销售、售前人员往往会对一些“简单的、不大的”需求直接予以承诺，对需求描述、完成标准也不甚清晰明了，在后期实施过程中，给交付团队带来实质性的困扰。

​ 不明确的需求，过程中如果没有足够的沟通、回顾、复核、确认，在交付上线阶段就会暴露出很多问题，只能被迫进行频繁变更进行弥补。（我去年的项目就是一个比较失败的案例，只对需求分析的架构设计进行了确认，过程中开发人员按照自己的理解进行系统开发，在初验过程中相当一部分功能不满足用户实际需求，教训惨重）

对需求的理解不一致

知识的诅咒：当一个人知道一件事后，就无法现象自己是不知道这件事的。你以为的我以为，不是你以为的样子。

​ 需求沟通过程中涉及甲方、需求分析人员、开发人员三类角色，需求分析人员包括项目经理、产品经理，甚至可能有专门的需求分析岗位。实际项目开展过程中，乙方组成相应的需求沟通小组，同甲方进行相关内容的沟通确认。甲方干系人根据自己理解和想法向乙方的传达对项目的愿景、期望，乙方由于知识领域、所处视角等原因往往很难彻底理解相关内容，甚至不同人会得到差异极大的理解结果，所以通常关键内容会反复进行沟通确认，双方逐渐不胜其扰 、希望尽快结束这个阶段。虽然最后达成了一致，但如同雾里看花，需求的整体轮廓基本可以看清，细节就难免失真了。

​ 出现需求理解不一致的原因，主要有：1. 客户自己描述需求时进行了裁剪，客户在相关领域拥有自己的立场和专业度，对某些细节的描述会下意识的省略；2. 客户自己对需求也只有大概的想法，也没有准确的理解；3. 乙方缺乏相关的专业知识，理解需求时不准确，甚至错误；4. 人员更替、不同角色之间链式传递信息会带来一些失真，造成需求偏离。

实际需求发生变化

项目初期，是在假设条件、约束、组织过程资产和事业环境因素诸多条件的影响下，基于逻辑进行的分析和预测。随着项目的推进，由于环境因素改变、项目的实际进度等原因，业务需求发生改变

需求本身是具有时效性的，现代社会各行各业都处于快速发展、快速改变的过程中，项目实现周期过长，项目如果不能积极的响应变化，很可能会出现交付即落后，上线即淘汰的情况。

缺乏明确的需求变更流程

​ 没有明确的需求变更流程，无限制的接受客户需求。会让客户形成频繁提需求的惯性，甚至因为某个普通用户的使用习惯、个人审美就会产生一些需求变更要求。客户习惯于提出需求变更，一个重要的原因就是客户对变更产生的成本没有明确的概念，完整明确的需求变更控制流程中，包含的相关需求的变更请求的优先级、成本、工期、质量影响等的评估、判断。甲乙双方根据评估结论，判断需求变更是否进行、何时进行。如果用户能接受需求变更带来的后果和成本，就做吧。

需求变更的来源

项目的所有干系人、影响因素都可能引起需求变更。站在项目管理者的角度看，来源可以归结为两个方面：内部来源和外部来源

内部来源

1. 产品经理（产品负责人）

   产品经理提出需求变更的目的，通常是为了让项目成果更贴近于客户要求、产品设计。

   产生变更的原因可能有：项目前期考虑步骤、产品设计发生变化、由于其他原因产生的临时需求。

2. 开发团队

   开发团队提出需求变更的目的，通常是为了实现方案更合理、更具有操作性、具有更好的效果（性能、体验）。产生变更的原因可能是出现了更好的技术选型、遇到了无法解决的技术问题、开发进度跟预期有较大偏差、团队人员变动等。

外部来源

1. 客户

   客户涵盖公司内部用户和公司外部用户，用户引入需求变更的主要目的是让产品更加贴合自身需求。

2. 公司内部、项目组之外

   项目团队之外、公司内部的其他部门、各级boss随着项目的进展、对项目的了解，会对项目的实施提出一些变更要求，这部分需求变更的主要目的是以最小的代价实现项目目标，产生的原因可能来自项目盈利目标、只能团队资源竞争等等

3. 环境因素改变

   环境因素包括政策因素、市场环境以及其他突发事件。这部分需求变更的主要原因是产品的合规、合法以及符合市场需求。

控制需求变更

​ 需求包括功能需求和非功能需求两部分，功能需求主要是用户对产品能力的要求和预期，属于产品一定要提供的能力，非功能需求则是实现项目需要的系统需求、业务规则、质量要求、开发约束等。

​ 软件工程中的需求变更本身是无法避免的，即使做了详细的计划、需求说明书，也让用户签字确认了，最后仍然会出现一些需求需要调整、变更。

​ 评估需求变更的一个重要分析原则是，该变更对项目是否有益，这个益处体现在包括功能、进度、成本、质量各方面。

​ 需求变更对项目的进度、成本、质量都有重要的影响，对其是否进行良好的管理，在一定程度上可以影响到项目的成败。对需求变更的处理，不能一概而论，不能一味拒绝，也不能一味的迁就。毕竟需求变更控制的目的并不是杜绝变更的产生，而是对变更进行控制，确保变更对项目成功有益。

工作做在前面

​ 变化往往伴随着风险和挑战，我们拥抱变化，但不能放任变化。在一个项目周期内，要尽量维护目标确定、一致。在开展项目实施工作之前，制定需求基线，在实施过程中冻结需求。我们没法保证不发生需求变更，可以努力实现小需求可以调整，大方向不变。

​ 项目生命周期中，拥有各种过程资产，我们可以借助这些过程资产，建立需求基线。在合同、协议、项目章程中增加相关的条件，如限定提出需求变更的时间、什么类型的需求变更可以接受、拒绝或部分接受以及出现需求变更时候的变更管理流程。虽然软件工程项目在项目初期很难对需求进行精确定义，但合同、协议作为甲乙双方最具有约束力的文件，在其中对高层级需求和争议处置方式进行描述，能够对项目成功提供相当程度的保障。在项目初期或者项目中预定节点，通过有客户参与的评审过程，对需求进行确认达成一致。以需求说明书、原型设计、概要设计等形式建立需求基线。此后每次变更都需要通过完整的需求变更流程进行评估、审核。保障在一个固定周期内需求相对稳定，保证项目质量、进度。建立需求基线，可以为后续的项目阶段奠定良好的基础。

​ 制定明确的变更控制流程，确定需求变更审批流程、各环节、看门人、审批事项，这样一方面可以将需求变更尽可能的规范化，减少心血来潮、不合理、不重要、不紧急的需求给项目成功带来负面影响；另一方面，为每次需求变更留痕，为项目收尾阶段的过程回顾、成本核算提供书面依据（为可能的扯皮提供弹药）。

需求优先级管理

​ 需求是否合理、是否重要，是判断需求变更是否应该实施的一个重要依据。需求变更进行仔细估算和规划，排定优先级，按照一定周期对高优先级需求变更进行处理（此处参考敏捷scrum等方法），确保重要的需求变更可以得到实施，也不会因为频繁的变更导致项目失败。期间可以周期性的召开需求变更相关的会议，集中研究需求的优先级、影响因素、实施时间等，收集上一阶段需求变更带来的结果、反馈，制定下一阶段的需求变更计划。

​ 敏捷实践对需求变更相对而言更友好，我们虽然不一定要全盘实施敏捷，其中对需求的估算、排序、回顾等工具在其他项目方法中同样可以借鉴。

专人专职沟通需求

​ 缺乏沟通，特别是缺乏有效的沟通，是项目常见的失败原因。而实际项目实施过程中有时候会出现，项目经理专注于进度、成本，开发人员专注于功能实现，忽略了与客户的随时沟通，造成项目入歧途而不自知的局面。也有时候会出现客户为了图方便，越过项目经理、产品经理，直接同开发人员沟通需求，开发人员直接进行实施的现象。这些都给项目打上了负面buf，其带来的危害，越到项目后期，越明显。

​ 在项目团队，至少应该安排一名专职的需求接口人，负责与客户及时沟通、跟踪、汇报需求变更的进度和现状，收集产品反馈、变更请求。条件允许，还可以成立项目变更控制委员会（CCB）或职能类似的组织，负责裁定接受那些变更，这个委员会应该涵盖项目涉及的各类干系人，包括客户方、研发人员、以及双方的决策者。