需求变更的处理经验及应对方法

1. 什么是需求变更？

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

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

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

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

        2.需求变更产生的原因

在软件开发项目中，需求变更可能来自方案服务商、客户或产品供应商等，当然，也可能来源于项目组内部。

对于需求变更发生的原因，细细追究起来无外乎以下几种原因：

        2.1对需求的理解不一致：

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

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

        2.2实际需求发生变化

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

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

        2.3缺乏明确的需求变更流程

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

        3.需求变更管理原则

虽然需求变更的内容和类型有各种各样，但需求变更管理的原则却是万变不离其宗。实施需求变更管理需要遵循如下原则：

 (1)建立需求基线。需求基线是需求变更的依据。在开发过程中，需求确定并经过评审后(用户参与评审)，可以建立第一个需求基线。此后每次变更并经过评审后，都要重新确定新的需求基线。

(2)制订简单、有效的变更控制流程，并形成文档。在建立了需求基线后提出的所有变更都必须遵循这个控制流程进行控制。同时，这个流程具有一定的普遍性，对以后的项目开发和其他项目都有借鉴作用。

(3)成立项目变更控制委员会(CCB)或相关职能的类似组织，负责裁定接受哪些变更。CCB由项目所涉及的多方人员共同组成，应该包括用户方和开发方的决策人员在内。

(4)需求变更一定要先申请然后再评估，最后经过与变更大小相当级别的评审确认。

(5)需求变更后，受影响的软件计划、产品、活动都要进行相应的变更，以保持和更新的需求一致。