4. 需求基线建立与变更控制委员会

需求基线是需求变更治理的“锚点”。没有基线，任何需求都可以被解释为“本来就要做”，变更就失去了比较对象，工期、成本和验收范围也无法稳定。需求基线不是把所有需求冻结，而是把某一时刻经过评审确认的需求集合，连同版本号、状态和责任人固定下来，作为后续变更的参照。基线一旦建立，任何修改都必须走变更流程，而不是直接在文档或需求管理工具里改掉。

一、需求基线的定义与建立时机

需求基线通常由三类内容构成：已确认的功能需求、非功能需求，以及与之绑定的验收标准。基线不是单一文档，而是一个可追溯的集合。建议在需求管理工具中为每个需求条目分配唯一编号，例如 REQ-F-001、REQ-NF-003，并记录版本、状态、来源、优先级和关联的验收条件。基线版本可以用 BL-1.0 表示，后续变更产生 BL-1.1、BL-2.0 等。

建立基线的时机一般选在需求评审通过之后、开发排期之前。此时需求已经过业务、产品、技术和测试多方确认，具备可估算、可测试的条件。如果项目采用迭代交付，可以在每个迭代开始前建立迭代基线，同时保留整体产品基线。基线建立后，需求状态从“草稿”变为“已基线”，任何修改都需要变更申请。

基线建立的关键动作包括：确认需求条目完整且无歧义；确认验收标准可测试；确认需求之间的依赖关系已标注；确认基线版本号和生效日期；将基线快照归档，确保后续可以对比差异。基线不是一次性工作，而是随变更审批不断演进。

二、变更控制委员会的组建

变更控制委员会（CCB）是变更审批的决策机构。它不需要庞大，但必须覆盖受影响的关键角色。典型的CCB成员包括：业务负责人（判断业务价值与优先级）、产品负责人（判断需求合理性与范围）、技术负责人（判断技术可行性与影响）、测试负责人（判断验收与回归成本）、项目经理（判断工期、资源与合同影响）。对于涉及合同金额或交付节点的变更，还应加入合同或商务负责人。

CCB需要明确主任委员和常设秘书。主任委员通常由项目经理或产品负责人担任，负责召集会议、裁决分歧；秘书负责记录变更申请、维护变更日志、跟踪审批结果。CCB成员可以按变更类型动态调整，例如纯技术优化类变更可由技术负责人和项目经理审批，涉及范围或合同的变更必须由业务负责人和商务负责人参与。

CCB的运作要避免两个极端：一是所有变更都上会，导致决策效率低下；二是CCB形同虚设，变更仍由个人口头决定。解决方法是按变更影响分级，设置不同的审批路径。

三、变更审批权限与议事规则

审批权限应与变更影响程度匹配。可以按“影响范围、工期影响、成本影响、合同影响”四个维度划分等级。例如：

议事规则要写清楚：变更申请由谁提交、必须包含哪些信息、CCB多久开一次会、如何表决、如何记录。建议变更申请至少包含：变更编号、申请人、提出日期、变更描述、变更原因、影响分析（范围、工期、成本、质量、合同）、建议方案、优先级。影响分析由技术负责人和项目经理在会前完成，避免会上临时讨论导致决策质量下降。

表决规则可以采用“简单多数”或“关键角色一致同意”。对于L3变更，建议采用关键角色一致同意，即业务、技术、项目经理三方中任何一方反对，变更都不能直接通过，而是升级到更高层决策或重新谈判合同。对于L1、L2变更，可以采用负责人审批制，但必须记录审批意见。

变更审批结果通常有三种：批准、拒绝、退回补充信息。批准后要更新需求基线版本，同步修改需求文档、测试用例、排期计划和合同附件；拒绝要记录理由，避免重复提出；退回补充信息要明确补充内容和时限。

四、从申请到基线更新的闭环

一个完整的变更闭环包括：提出申请、影响分析、CCB审批、实施变更、验证变更、更新基线、通知相关方。其中“更新基线”最容易被忽略。很多团队审批通过了变更，但需求文档和测试用例没有同步，导致开发和测试依据不一致。建议在变更审批通过后，由配置管理员或项目经理在需求管理工具中执行基线更新，生成新的基线版本，并记录变更前后的差异。

下面这张图展示了需求基线、CCB与变更审批权限之间的关系：基线是参照物，CCB是决策机构，分级审批是处理路径，最终结果回到基线更新，形成闭环。

在实际操作中，建议把变更日志作为CCB的核心台账。每条变更记录至少包含：变更编号、关联需求编号、申请人、申请日期、变更等级、影响分析摘要、CCB决议、决议日期、实施状态、基线更新版本。这样在项目复盘或合同争议时，可以快速还原每一次范围变化的来龙去脉。

最后，CCB的议事规则要定期回顾。项目进入稳定期后，可以适当下放L1、L2审批权限，减少会议负担；项目进入交付冲刺期，则应收紧L3变更，避免范围蔓延。基线、CCB和审批权限三者配合，才能让需求变更从“谁声音大谁说了算”变成“有依据、有记录、有决策”的治理过程。