范围管理-需求变更管理制度(模板).docx

XXXX项目

需求变更管理制度

YYYY-MM-DD

1 2018-01-01
编 写

评 审

上级部门 评审 审 批
版本

XXX组
XXX(PMO成员)

XXX(上级部门评审人)

XXX(上级部门上级领导)

编写

评审

评审

审批

V1. 1

时间

时间

时间

时间

YYYY-MM-DD

YYYY-MM-DD

YYYY-MM-DD

YYYY-MM-DD

目 录

1. 概述 3

1.1. 编写目的 3
1.2. 术语及缩略语 3
1.3. 参考文献 3

2. 参与人员 4

3. 输入 4

4. 输出 4

5. 工作方法 4

5.1. 工作总则 4
5.2. 评估、评审 5
5.3. 应对策略 5
5.4. 二次需求分析 6

6. 工具/模板 7

6.1. 需求变更流程 7
6.2. 需求变更申请单 7

7. 常用工作技巧 7

7.1. 建立变更规则 7
7.2. 建立范围标准 8
7.3. 双方评审确认 8
7.4. 需求早封板 8

8. 常见问题与解决方案 8

8.1 问题一及解决方案 8
8.2 问题二及解决方案 8

2 2018-01-01
1. 概述

1.1. 编写目的

需求变更是不可避免的，也不是孤立存在的。当项目范围发生变化时，需要识别需求 变更是在项目范围内还是项目范围外。通过需求变更流程进行评估、引导和控制，尽量减 少范围变更。
只有管理好项目范围，才能有效防止项目边界蔓延和项目镀金，按照项目范围约定按 时达成项目目标。
1.2. 术语及缩略语

本文中使用的名词术语和缩略语见下表。
表1 名词和缩略语
序号 缩略语 说明 备注
1 CCB 变更控制委员会

2

3

4

1.3. 参考文献

表2 参考文献
文档名称
发布日期
版本号
作者

3 2018-01-01

2. 参与人员

项目经理、商务负责人、技术经理、需求分析组、设计开发组、用户。

3. 输入

(根据实际情况剪裁)
售前的投标书：包括商务合同、技术规范书、技术建议书、报价功能清单。
项目范围基准；
项目设计文档；
项目变更流程子域的需求变更流程和需求变更申请单；

4. 输出

更新后的需求规格说明书、三级功能列表、需求跟踪矩阵。

5. 工作方法

5.1. 工作总则

售前阶段深入参与，详细审核技术建议书、报价清单中的内容，主要关注二份文档中 描述不一致或者此有彼无的功能。
项目前期功能设计过程中注意细节管理，设计文档、测试用例需严格按照功能清单的 功能编写，在此之外的功能不能包含；提前跟客户制定需求变更管理流程CCB。
项目实施过程中定期对全员宣贯需求变更管理流程，包括本次项目的范围基准以及判 断标准；安排专人进行需求管控；与客户保持良好沟通，对于确定的需求变更严格执行需 求变更管理流程，给予多样化的灵活支持，全过程文档管控，将所有的需求变更对项目的 影响以数字化体现，确保立于不败之地。
需求变更申请，基于项目范围基准，需求发生新增、减少、变化时，需求变更提出人

4 2018-01-01
向CCB提出需求变更申请。

5.2. 评估、评审

项目经理安排对应的技术经理围绕售前标书、项目范围基准、设计文档进行全面分 析，如确定属于变更，再评估影响、风险。如果变更的需求影响较小(工作量少于5人 天)，项目经理可以直接决策，接受变更，并反馈给变更提出人。但不能一味答应用户， 还是要有相应的置换或对项目决策有影响力的用户。
每月汇总，通报客户，注意方式方法，目的是告知用户项目组为此付出了相应的工作 量，为后续某些场合的沟通提供例证。
若需求影响较大(工作量大于5人天)，按照需求变更流程提交CCB进行审核，确认 是否同意变更。
5.3. 应对策略

说明：对于项目需求变更，一定要先弄清楚客户的原始意图，有的放矢。
针对已经确认属于项目新需求的功能，不能仅仅局限于“做”“不做”，需提供更多 的处理方法给用户选择，让用户感觉到我司不是为了拒绝而去拒绝，是做了详细分析才给 出的建议：
a) 部分实现： 跟用户沟通分步实现， 选取变更内容中的一部分完成， 满足用户最紧迫
的需求。这样可以减少工作量及复杂度，用户也相对容易接受。
b) 方案替换： 以用户最终目的为目标， 考虑简单系统实现方案， 达到既满足了用户的
要求，又减少了开发、测试工作量。
c) 功能置换： 同意作为需求变更处理， 但是可以考虑将一部分不重要、 不紧急的功能
跟用户沟通进行置换，保持总体工作量不变。
d) 不同意实现： 告知不能在本期工程实现的原因， 说明对工程的影响， 让用户在工期
与功能上进行选择； 此处一般为系统架构限制无法实现或者改动工作量太大， 导致 前期工作会进行大范围推到重来，严重影响总体进度。
e) 延后实现： 适用于客户相对重要但是不太紧急的需求变更，跟用户明确上线后 XXX
日给与实现，减少当前工程压力。
f) 全部实现： 同意作为需求变更处理， 并实现变更的所有内容； 需明确告知工作量(需

5 2018-01-01
要用户补充费用)及对工期的影响。
需求变更在任何项目中都无法绝对避免，需求变更管理是一个长期的过程，贯穿整个 项目过程，双方需要基于相互理解、相互信任的基础上进行多层次、多轮次的沟通，达到 一个共赢的结果。
沟通需掌握好度，客户方有理的时候一定要爽快答应(包括一些很小的改动，比如界 面按钮调整UE类)，建立信任；客户方不占理时也需充分说明理由、影响、难处，获得客 户的理解、认可，最高境界是客户同意我司不做也认为我司是在为客户着想：
a) 不该做：利用好判断依据，能够依据判断依据有理有据的告知用户，不在合同范
围， 所以我们不希望做或者是归属于其他外围系统实现； 此条适用于讲道理、 守合 同的客户。
b) 不能做：系统架构不支持、会导致前期的工作出现无用功；此条适用于技术型客
户。
c) 不白做： 改动工作量大， 需要用户增补大量额外费用； 此条适用于对费用比较敏感
的客户。
d) 不敢做： 严重影响工期， 我司无法保障工期如期完成； 此条适用于对工期有要求的
客户。
e) 定期做： 项目后期时间紧， 改动大可能会影响上线质量， 我司承诺上线后 XXX 日
给与实现；此条适用于对上线稳定性有较高要求的客户。
沟通的过程是一个相互说服的过程，需要提前跟相关干系人建立起合作默契，掌握有 效的沟通技术，最大化的争取项目整体利益，具体沟通技巧可见沟通管理白皮书。
充分利用好月度例会，可以达到2个目的：让相关利益方明白需求变更对工程/工期的 影响、从客户领导层面入手，说服领导同意项目组的策略，下面具体执行人员自然不攻自 破。
在对外做好沟通的同时，需要定期与项目组内部各环节宣贯需求管理办法，避免各环 节人员有镀金的行为。
5.4. 二次需求分析

审核通过的变更需求，需求分析团队人员及时访谈需求变更提出人。完成需求分析， 更新需求规格说明书，完成内部评审，外部评审，并最终和用户签字确认。同步更新三级

6 2018-01-01
功能列表、需求跟踪矩阵，完成与用户的签字确认。

6. 工具/模板

6.1. 需求变更流程

6.2. 需求变更申请单

需求变更申请单.xls

7. 常用工作技巧

7.1. 建立变更规则

项目启动后，及时同用户建立CCB和需求变更流程。引导客户建立规则，让需求变更 变的更有计划、更易控制。

7 2018-01-01

7.2. 建立范围标准

以合同报价清单、需求文档为标准来衡量是否在合同范围内；
以设计文档、测试案例、技术建议书为辅。

7.3. 双方评审确认

项目范围基准、设计文档一定要经过用户双方评审，一式两份，并签字确认，为减少 范围变更提前预埋条件。
7.4. 需求早封板

在确定项目计划时，要与用户协商好需求封版时间。时间越早，项目范围变化就越 小，给项目组预留的执行时间越充分，有利于控制项目风险和项目质量。
8. 常见问题与解决方案

8.1 问题一及解决方案

问题： 项目组确认需要进行范围变更，需要变更基准和增加预算后，如何快速的完成 公司要求的变更流程。
解决方案：
由于项目范围基准变更，可能造成成本基准和进度基准的变更。由项目经理输出项目 基准变更初稿，商务部门总监评审通过后，方可向CCB发起基准变更申请。
8.2 问题二及解决方案

问题： 如何处理客户紧急需求或刚性需求的变更
解决方案：
a) 首先按需求变更流程安排项目需求分析组分析评估，判断是合同内还是合同外需
求，并确认工作量及影响。

8 2018-01-01
b) 若是合同外需求，请商务部门牵头，项目组PMO 配合，和用户领导进行沟通，申
请增加工作量或增补合同。 用户认可后， 协调人力资源进行需求调研、 需求分析和 开发支撑。
c) 若是合同内需求，安排需求分析组进行需求调研和需求分析，就需求内容、影响
度和计划安排，要与用户沟通、达成共识。
9 2018-01-01