瀑布模型落地：阶段评审、变更控制与基线管理如何配合

瀑布模型落地时，阶段评审、变更控制和基线管理需要按“基线定基准、评审设关口、变更管差异”的顺序配合：每个阶段结束前，把已通过评审的交付物纳入基线，作为后续工作的比较基准；阶段评审判断交付物是否达到进入下一阶段的条件，通过后冻结为基线；基线冻结后出现的修改需求统一走变更控制，评估影响、审批、实施并回写新基线。本文面向按瀑布方式推进单个项目的团队，给出可执行的流程、角色分工、示例与检查清单。

要点总览（TL;DR）

• 三者按“基线定基准、评审设关口、变更管差异”配合：阶段出口触发评审，评审通过触发基线冻结，基线后的修改触发变更控制，变更批准后回写新基线。
• 落地分六步循环执行：定义阶段出口标准、确定基线对象与时点、组织阶段评审、冻结发布基线、受理评估变更、实施变更并更新基线。
• 项目经理组织评审与维护基线清单，评审主持人判定出口标准，配置管理员执行冻结与归档，变更提出人和审批人保证申请信息完整、结论有依据。
• 机制是否有效看五项：出口标准可追溯、基线清单完整、变更全部走统一入口、变更后基线同步更新、遗留问题与变更记录闭环。
• 发现绕过变更入口或基线未更新等阻断项时，先暂停新增变更受理，清理存量问题后再恢复流程。

三者如何分工：基线定基准、评审设关口、变更管差异

三者解决的是三个不同问题。基线管理回答“拿什么作为比较基准”，阶段评审回答“能不能进入下一阶段”，变更控制回答“基准确定后要改怎么办”。三者按阶段交界处的时间顺序衔接：先评审、后冻结、再接受变更，变更批准后回到基线更新，形成闭环。

基线管理确定哪些交付物在什么时点被冻结。冻结的对象通常是阶段出口的正式交付物，例如需求规格、概要设计、项目计划与里程碑。冻结意味着该版本成为后续设计、开发、测试和验收的比较依据，后续任何偏离都要能被识别。

阶段评审设在阶段交界处，作用是判断交付物是否达到进入下一阶段的条件。评审要有明确的通过标准、参与角色和结论形式，结论通常分为通过、有条件通过和不通过。有条件通过时，遗留问题需要形成清单，明确责任人和关闭时点。

变更控制处理基线冻结后的修改请求。它提供统一入口，要求提出人说明变更内容与理由，由相关方评估对范围、进度、成本和质量的影响，审批人给出批准或驳回结论。批准后实施变更，并把结果回写为新基线版本，保留变更记录以便追溯。

三者的触发关系可以概括为：阶段出口触发评审，评审通过触发基线冻结，基线冻结后的修改触发变更控制，变更批准触发基线更新。缺少任一环节，另外两个环节都会失效——没有评审，基线冻结缺少依据；没有基线，变更控制失去比较对象；没有变更控制，基线会被随意修改而失去基准意义。

机制	核心职责	触发时点	主要产出	失效后果
阶段评审	判断交付物是否达到阶段出口标准	每个阶段结束前	评审结论、遗留问题清单	未达标交付物进入下一阶段，返工成本后移
基线管理	确定冻结对象、时点与版本标识	评审通过后	基线清单、基线版本	后续工作缺少比较基准，偏差无法识别
变更控制	评估、审批、实施基线后的修改	基线冻结后出现修改需求时	变更申请、影响评估、审批结论、变更记录	修改绕过审批，范围与进度失控

落地步骤：从阶段出口定义到基线冻结的完整流程

落地时按六个步骤推进，每一步都要有明确输入、动作、输出和完成标志。步骤之间不是一次性的，而是在每个阶段循环执行。

步骤	输入	动作	输出	完成标志
1. 定义阶段划分与出口标准	项目类型、合同或立项要求、历史项目经验	确定阶段名称与顺序，为每个阶段出口列出评审检查项和通过条件	阶段出口标准清单	每个阶段都有可核对的通过条件，且团队已知晓
2. 确定基线对象与基线时点	阶段出口标准、交付物清单	标明哪些文档、设计、计划纳入基线，在哪个评审通过后冻结	基线清单（对象、时点、责任人）	基线对象无遗漏，时点与评审节点对应
3. 组织阶段评审	待评审交付物、出口标准、评审参与人	提前分发材料，按检查项逐条确认，记录结论与遗留问题	评审结论、遗留问题清单	结论明确，遗留问题有责任人和关闭时点
4. 冻结并发布基线	评审通过结论、交付物最终版本	执行冻结，赋予版本标识，向相关方发布基线版本	基线版本及发布记录	基线版本可识别，相关方已收到通知
5. 受理并评估变更	变更申请、当前基线版本	统一入口登记，评估对范围、进度、成本、质量的影响，提交审批	影响评估说明、审批结论	每个变更都有评估记录和明确结论
6. 实施变更并更新基线	批准的变更、实施结果	按批准内容实施，验证结果，更新基线版本并归档变更记录	新基线版本、变更记录	基线已同步更新，变更记录可追溯

第一步的关键是把“通过”写成可判断的条件，例如需求文档覆盖了全部已确认需求、关键接口已定义、遗留问题不超过约定数量。标准写得越具体，评审越不容易变成走过场。

第二步要避免基线对象只覆盖计划而遗漏文档类交付物。需求、设计、接口说明这类交付物一旦被下游引用，就应纳入基线，否则下游依据的版本无法确认。

第三步的评审准备决定了评审质量。材料应提前分发，评审人按检查项逐条给出意见，会议记录直接形成结论和遗留问题清单，避免会后补记导致结论模糊。

第四步的冻结动作要产生可识别的版本标识，并通知所有下游相关方。冻结不是把文件锁死，而是明确“当前以此版本为准”，后续修改必须走变更。

第五步要守住统一入口。变更申请集中登记，避免通过邮件、即时消息口头提出的修改直接进入实施。影响评估至少覆盖范围、进度、成本三个维度，必要时补充质量与风险。

第六步强调回写。变更实施后如果基线没有同步更新，下一次评审和变更评估就会基于过期版本，整个机制的可信度随之下降。

角色与交付物：谁在什么时点做什么

机制能否跑起来，取决于每个角色是否清楚自己在什么时点交付什么。小团队可以一人兼任多个角色，但职责要分开写明，避免评审、冻结和变更审批集中在同一人身上而失去制衡。

角色	主要动作	交付物	交接时点
项目经理	组织阶段评审、维护基线清单、管理变更入口、跟踪遗留问题关闭	评审通知与记录、基线清单、变更登记台账	阶段结束前组织评审，评审后推动冻结，变更受理后跟踪至关闭
技术负责人或评审主持人	判定技术交付物是否达到出口标准，主持评审并形成结论	评审结论、技术遗留问题清单	评审会上给出结论，会后确认遗留问题关闭情况
配置管理员或文档管理员	执行基线冻结、赋予版本标识、归档变更记录	基线版本、版本发布记录、变更归档	评审通过后执行冻结，变更批准实施后更新版本
变更提出人	提交变更申请，说明变更内容、理由与期望时点	变更申请单	发现基线后修改需求时提交
变更审批人	基于影响评估给出批准、驳回或延期结论	审批结论	影响评估完成后作出结论

项目经理的交付物中，基线清单是最容易被忽视的一项。清单应列明基线对象、冻结时点、当前版本和责任人，随阶段推进持续维护，而不是在项目结束时补做。

评审主持人的判断直接影响关口是否有效。主持人需要对出口标准有解释权，能够在标准未满足时给出不通过或有条件通过的结论，而不是把问题留给下一阶段解决。

配置管理员的动作看似事务性，实际决定了追溯能力。版本标识规则应提前约定，变更记录按变更编号归档，确保后续能回答“这个版本为什么变成现在这样”。

变更提出人与审批人之间要保持信息完整。申请单缺少影响范围描述时，审批人应退回补充，避免在信息不足的情况下作出批准结论。

在工具承载上，评审结论、遗留问题、变更申请和基线版本需要落在同一套记录中，才能相互关联。ONES 支持瀑布项目全生命周期管理，可用项目计划组织阶段与里程碑，并设置项目计划和里程碑基线、通过版本对比追溯变更细节；评审结论与变更记录也可借助文档与工作项关联的方式留存。具体配置方式以实际使用的产品和版本为准。

示例：一个需求阶段到设计阶段的配合过程

以下为演示情景，用于说明阶段交界处三者如何衔接，不代表真实客户案例。

某项目进入需求阶段末期。项目经理按出口标准组织评审，提前两天把需求规格、需求跟踪表和遗留问题草稿发给评审人。评审会上，评审主持人按检查项逐条确认：已确认需求是否全部覆盖、验收条件是否明确、与上游立项范围是否一致。评审结论为有条件通过，遗留三项需求描述需要补充验收条件，责任人为需求负责人，关闭时点定在设计评审前。

遗留问题关闭后，配置管理员执行需求基线冻结，赋予版本标识，并把基线版本和冻结通知发给设计、开发和测试相关方。此时需求文档成为后续设计工作的比较基准。

设计阶段进行到一半，业务方提出一项需求修改：新增一个报表导出功能。需求负责人通过统一入口提交变更申请，说明修改内容、理由和期望上线时点。项目经理组织影响评估：该功能涉及一个新的数据接口，设计需要增加约三个工作日，测试用例需要补充，对当前里程碑有约一周的进度影响。

变更审批人根据评估结论作出批准决定，同时要求把该功能排入当前设计阶段而非推迟到下一版本。设计负责人据此调整设计说明，测试负责人补充测试范围。

变更实施并验证后，配置管理员更新需求基线版本，把变更申请、影响评估和审批结论一并归档，并通知设计相关方以新基线为准。至此，一次完整的“评审—冻结—变更—回写”闭环完成。

这个示例说明两个要点：评审遗留问题要在冻结前关闭，否则基线本身带有未决事项；变更影响评估要落到具体工作量和里程碑，审批结论才有依据。

完成检查：机制是否真正跑起来的判断项

机制建立后，需要定期核对它是否在实际运行，而不只是停留在文档里。以下检查项可按阶段或按月执行。

检查项	核对方式	阻断项说明
每个阶段是否有明确的评审通过标准并可追溯	抽查阶段出口标准清单与对应评审记录	存在无标准的阶段，或评审记录无法对应标准条目，视为阻断
基线清单是否完整、版本是否可识别	核对基线清单与实际冻结版本、版本标识规则	基线对象遗漏关键交付物，或版本无法区分，视为阻断
基线后变更是否全部经过统一入口	比对变更登记台账与实施记录、代码或文档修改记录	发现绕过入口直接实施的修改，视为阻断
变更批准后基线是否同步更新	抽查变更记录对应的基线版本更新情况	变更已实施但基线未更新，视为阻断
评审遗留问题与变更记录是否闭环	核对遗留问题清单的关闭状态与变更归档完整性	存在超期未关闭且无说明的遗留问题，视为阻断

阻断项的处理原则是先停止新增变更的受理，集中清理存量问题，再恢复流程。这样做的目的是避免在基线不可信的情况下继续累积变更，导致后续评估全部失真。

检查频率可与阶段评审同步，在每个阶段出口顺带核对上一阶段的基线完整性和变更闭环情况。对于阶段周期较长的项目，可在阶段中期增加一次抽查，重点看是否有绕过统一入口的修改。

检查结果应形成简短记录，列出发现的问题、责任人和整改时点。记录本身也是下一轮评审的输入，帮助团队判断出口标准是否需要调整。

常见问题

阶段评审结论为“有条件通过”时，基线应该冻结还是等遗留问题关闭后再冻结？

建议等遗留问题关闭后再冻结基线。有条件通过意味着交付物尚未完全达到出口标准，此时冻结会让基线带着未决事项进入下游，后续设计和测试依据的版本本身存在缺口。可执行的做法是：评审会上明确遗留问题清单、责任人和关闭时点，关闭后由评审主持人确认，再执行冻结。若遗留问题不影响下游工作开展，也可在评审记录中写明冻结范围与例外项，但例外项仍需在下一阶段早期关闭。

基线冻结后，下游发现文档有笔误或表述不清，也要走变更控制吗？

需要区分修改性质。影响范围、进度、成本或验收条件的修改，应走变更控制；纯文字笔误、格式调整等不改变内容的修改，可在变更登记中做简化记录后直接更正，并同步更新基线版本标识。关键在于团队提前约定“哪些修改必须审批、哪些可以简化登记”，并把判断标准写进流程说明，避免以“只是小改”为由绕过统一入口。简化记录同样要留痕，保证版本可追溯。

小团队人手有限，评审、冻结和变更审批由同一人兼任，机制还能有效吗？

可以兼任，但职责要分开写明，并在关键节点引入第二人确认。例如项目经理可同时承担评审组织和变更登记，但技术交付物的出口判定应由技术负责人给出；变更审批至少让受影响方的负责人参与，避免提出人自己批准自己。兼任的风险在于关口失去制衡，可用的补偿办法是把评审结论和变更结论形成书面记录，由上一级或相关方定期抽查，用记录留痕替代部分岗位分离。

项目已经进行到中后期，前期没有建立基线，现在补建还有意义吗？

有意义，但补建的重点应放在当前仍在被下游引用的交付物上。可先梳理需求、设计、接口说明等仍作为工作依据的文档，确认其当前有效版本，经相关方确认后冻结为基线，并注明补建时点。补建后新发生的修改纳入变更控制，历史修改不做追溯性补录。这样至少能让后续阶段有可比较的基准，避免偏差继续累积到验收阶段才暴露。

检查发现变更记录与基线版本对不上，应该先修记录还是先停流程？

建议先暂停新增变更的受理，再核对存量。记录与基线对不上意味着当前基线版本不可信，此时继续受理新变更会让影响评估建立在错误版本上。处理顺序是：冻结变更入口，逐条比对变更记录、实施结果与基线版本，补齐缺失的基线更新或标注差异原因，确认基线可信后再恢复受理。恢复后可在下一次阶段评审时顺带复核，确认问题没有反复。