4.5 变更管理

我们在讨论“变更”之前，先搞清楚一个概念——基线。基线是开发的文档、图纸或源码（或其他产出物）的一个稳定版本，它是进一步开发、变更的基础。所以，当基线形成后，项目负责人需要通知相关人员基线已经形成，并且归档，设立版本号。这个过程可被认为是内部的发布，至于对外的正式发布，更是应当从基线化的版本中发布。

在我们开展企业培训和咨询的工作过程中发现，最大的问题是：需求、计划、成本、质量要求，这些没有基线。也就是说没有《需求跟踪表》这样的文档归档，更没有这些文档的评审和版本管理。这种情况下，一旦有人提出“需求变更”，就会乱了阵脚。因为没有基线，所以流程很容易被随意变更。变更管理的手段有：组织、流程、控制、跟踪、存档、基线。变更管理如图4.7所示。

1．确立需求变更的责任人

我们通常成立一个组织来确立需求变更的责任人，这个组织叫变更控制委员会（Change Control Board，CCB）。CCB在CMMI（Capability Maturity Model Integration，能力成熟度模型集成）中，是“变更控制委员会”的含义，同时具有配置控制委员会（Configuration Control Board）的含义。CCB可以由一群人组成，负责作出决策：究竟将哪些建议需求变更或新产品特性付诸实践？当组建CCB时，还应当包含来自硬件、软件、硬件工程、系统工程、制造部门或者硬件质量保证和版本管理的代表。

CCB是决策机构，不是作业机构，通常CCB的工作是通过评审手段来决定项目是否变更，但不提出变更方案。

对于初创团队，虽然创始人可能是决策者也是执行者，但是需求变更也应该有制度、有记录、有讨论、有跟踪，而不能随意变更。至少项目负责人需要有一个需求跟踪表进行变更登记，并且变更前需要组织评审。需求变更有“申请、评估、审批、执行、确认”五个步骤，需要以项目相关人组成临时的CCB为主体开展。

2．CCB的组成

CCB应由来自不同领域的项目利益相关者的代表组成，而且有能力在管理上作出承诺。CCB一般由部门管理者、市场代表、项目双方项目经理、开发负责人、测试负责人、QA（质量人员）、配置管理（或资料管理）工程师组成。对于不同类型、不同层次的项目，CCB的成员不尽相同，如高技术型项目会包括技术负责人，系统集成类项目一般会包括系统工程负责人，硬件产品类项目一般会包括硬件负责人，对于重要项目可能会包括项目双方的高层管理者。

有些朋友肯定会问，那么多人肯定都很忙，难道所有的基准建立、变更都要提交CCB审批吗？如果是大的变更还有必要，如果很小的变更还要提交CCB，那不是效率很低吗？这也是很多组织中疑惑的地方。为了应对这种情况，我们一般采用对CCB划分层次的方式，使得不同层次的CCB成员关注不同的变更。

3．CCB的层次

CCB的层次一般都是有必要的（规模很小的项目一般不必要），有些组织对于应该划分几个层次的问题比较疑惑。CCB层次的多少不应该统一，而是应该根据项目实际情况决定（作为组织标准规范，可以对CCB层次划分提出建议，但不应强制项目执行）。一般情况下CCB的划分从以下步骤来考虑。

（1）项目涉及范围分析：先考虑此项目与哪些人有关系。

（2）涉及范围影响分析：分析与项目有关系的人中能影响项目各类决策的人，这些人即是CCB成员。

（3）决策内容分析：对需要CCB进行决策的内容进行分析并分类。

（4）决策匹配分析：将需要决策的内容与CCB成员进行匹配，得出大致层次。

（5）层次匹配分析：上一步中得到的大致层次中会出现很多人员及决策内容的重叠，如项目进度计划的变更，影响较小的变更项目经理就可以决定，影响较大的变更需要部门管理者决定，影响更大的变更甚至需要项目双方高层管理者决定。因此需要对不同层次的决策内容进行分析。

有两种常用的CCB层次类型：

（1）按照配置项类型，如需求相关的变更由1级CCB负责，设计相关的变更由2级CCB负责，代码相关的变更由3级CCB负责。

（2）按照变更影响，拿项目进度计划举例，工期变更超过50%由1级CCB负责，工期变更超过20%、不超过50%由2级CCB负责，工期变更不超过20%由3级CCB负责。

CCB的层次及分别负责的内容应在配置管理策划/计划期间完成，并需经过评审方可作为正式内容指导相关工作。

4．CCB的决策

建立了CCB之后，需要考虑的问题是如何决策。一般来讲，有以下三种方法可以考虑：

（1）多数意见决策：通过投票的方式使所有的成员平等地参与决策过程。优点是充分调动了成员参加会议和提出建议的积极性，缺点是“少数服从多数”难以定义，2/3算多数吗？绝对多数还是相对多数？还有一个严重的问题是这种机制可能产生组织上的斗争（拉帮结派），严重影响项目决策。

（2）权力集中决策：将决策权交给一个人。优点是鼓励了决策中灵活考虑各种意见的优先级，如买方项目经理作为项目最终责任人进行决策；缺点是压抑了其他成员的积极性。

（3）一致意见决策：寻求大多数参加会议的成员的非正式（非投票）统一意见。优点是速度快，而且能让所有人的观点都得到表达和考虑；缺点是如果成员之间不能达成一致，就无法做出决定。因此，应提供一种跳出机制，当无法在合理时间内达成一致时，则由买方项目经理决策（因为是买方投资）。

5．CCB的领导者

与CCB构成同样重要的是谁来担任CCB的领导者。CCB的领导者不是行政领导者而是职责领导者，负责主持会议，确保不偏离会议主题。

CCB的领导者可优先考虑下列人员。

买方项目经理：最终对产品的用户负责、对项目投资。

卖方项目经理：负责技术开发和维护。

配置管理工程师：CM（Configuration Management，配置管理）是他的主要职责，CCB是配置管理的焦点所在。

QA（Quality Assurance，质量保证工程师）：作为协调者而非决策者，对任何决策的实施不负任何责任。

6．CCB会议

CCB会议一般在需要对变更、发布等情况做出决策时召开。

对于CCB会议，需要进行会议记录以便为CCB的决策提供可视性。CCB的会议记录还通过记录何时发生了什么事情提供对项目的可跟踪性，会议记录应是准确和具体的，不能存在让人误解的地方。无论采取什么行动，会议记录都应该记录谁是执行者以及行动何时完成等信息，还需包括会议出席和未出席的人员。会议记录不仅要呈给出席会议的人员，还要呈给买方和卖方的高层管理者，以便其对项目进行追踪。

CCB会议记录不是出于形式上的目的，而是为了记录内容清楚和完整。人们经常在结束会议时对会议结果进行推辞或对共同决定的问题持有不同的观点，这种混乱无序的结果是很危险的，会议记录避免了这种情况。

7．需求变更管理模板

本文档发布之后，要求对本文档内容进行增加、修改或删除等操作，必须经过需求变更评审。变更申请及审核模板见表4.5。