瀑布模型的稳定性来自一套可追溯的配合机制：每个阶段先建立并冻结基线，阶段评审据此判断能否进入下一阶段，评审通过后任何修改都走变更控制，变更完成后形成新基线版本。本文按这一顺序给出职责分工、分步流程、角色交付物、变更示例和落地检查清单，并说明如何用ONES承载计划基线、评审记录与变更追溯。
要点总览（TL;DR）
- 三者按“基线定基准、评审做确认、变更走通道”的顺序配合：阶段结束先建基线并冻结，评审据此判断能否放行，放行后的修改统一走变更控制并形成新基线版本。
- 基线是评审和变更共同的参照物，评审记录、变更单和版本记录必须互相引用，否则追溯链在第一次变更时就会断开。
- 操作上分五步：确定基线对象与冻结时点、组织阶段评审、评审通过后发布基线、受理变更并评估审批、实施变更并更新基线。
- 项目经理统筹基线与评审，技术负责人把关技术结论，配置管理员维护版本，变更审批人对评估结论负责；小团队可兼岗，但签字责任不能无人复核。
- 检查机制是否运转看四点：基线齐全可追溯、评审有记录且结论明确、变更全部走通道、变更后基线同步更新；出现先改后补或评审走过场即为失效信号。
核心答案：三者的分工与配合顺序
瀑布模型把项目切成需求、设计、开发、测试、上线等顺序阶段，每个阶段结束时都要回答两个问题：这一阶段的成果是否达到进入下一阶段的条件，以及进入下一阶段后这些成果还能不能被随意改动。基线管理、阶段评审和变更控制分别回答这两个问题的不同部分，缺一项，顺序开发的稳定性就会被侵蚀。
三者的职责边界可以概括为：基线定义“什么是当前有效版本”，阶段评审决定“这个版本能否放行”，变更控制规定“放行之后怎么改”。基线是评审和变更共同的参照物，评审和变更必须引用同一套版本与记录，否则评审确认的版本和变更修改的版本会对不上，追溯链在第一次变更时就断了。
| 机制 | 核心职责 | 关键动作 | 产出 |
|---|---|---|---|
| 基线管理 | 为每个阶段确定冻结对象和有效版本 | 识别阶段交付物、冻结、标识版本、维护版本记录 | 基线清单、基线版本号 |
| 阶段评审 | 判断当前基线是否满足进入下一阶段的条件 | 准备评审材料、逐项核对、形成结论、签字确认 | 评审记录、评审结论 |
| 变更控制 | 管理基线生效后的所有修改 | 受理申请、影响评估、审批、实施、回归确认 | 变更单、新基线版本 |
配合时序是一条单向链：建基线→评审确认→基线生效→变更→新基线。阶段结束时先形成该阶段基线，范围、需求、设计、计划等按项目实际确定冻结对象；评审以这份基线为输入，结论为通过时基线正式生效并作为下一阶段的起点；此后出现的修改一律进入变更通道，评估审批后实施，验证通过再更新基线版本。评审未通过时回到当前阶段整改，不带着未关闭的问题进入下一阶段。
需要说明的是，冻结不等于不能改，而是改动必须留下评估和审批记录。冻结的严格程度应随项目复杂度调整：对外交付合同约束强的项目，范围和需求基线应严格冻结；内部探索性较强的项目，可以在设计或计划层面保留更灵活的调整空间，但调整同样要走变更通道。
操作步骤：从阶段基线到变更闭环怎么走
下面按阶段推进的顺序给出五步操作，每步说明输入、动作、输出和完成标志。团队可以据此建立自己的流程说明，也可以直接在项目管理工具中配置对应的工作项和文档。
第一步：确定各阶段基线对象与冻结时点
输入是项目计划、阶段划分和交付物清单。动作是逐阶段列出需要冻结的内容，常见对应关系为：需求阶段冻结需求规格与范围说明，设计阶段冻结设计文档与接口定义，开发阶段冻结代码版本与构建计划，测试阶段冻结测试方案与用例基线，上线阶段冻结发布计划。输出是基线清单，标明每个基线的对象、责任人和冻结时点。完成标志是清单经项目经理与技术负责人确认，且每个阶段都有明确的冻结对象，不存在“到时候再说”的空白项。
第二步：组织阶段评审
输入是待评审的基线材料、上一阶段遗留问题清单和评审检查项。动作包括提前分发材料、按评审项逐条核对、记录问题和结论、明确整改责任人与期限。评审项应覆盖交付物完整性、与上一阶段基线的一致性、遗留问题关闭情况。输出是评审记录和明确的评审结论：通过、有条件通过或不通过。完成标志是所有评审人签字、结论写入记录，有条件通过时附带的条件有责任人和关闭时间。
第三步：评审通过后发布基线
输入是评审结论和基线材料。动作是由配置管理员对通过评审的对象打版本标识，登记到基线清单，并通知下游阶段使用该版本。输出是带版本号的正式基线和版本记录。完成标志是基线清单更新完毕、版本号可查、下游阶段已确认引用的是这一版本。评审未通过时，此步不执行，流程回到当前阶段整改。
第四步：受理变更并完成评估审批
输入是变更申请，应写明变更内容、提出原因和期望时间。动作是先做影响评估，覆盖范围、进度、成本以及受影响的已冻结基线，评估结论形成书面意见；再由变更审批人依据评估结论决定批准、驳回或调整后批准。输出是变更单，包含评估意见、审批结论和实施安排。完成标志是变更单状态明确、审批人签字、实施责任人和时间已确定。
第五步：实施变更并更新基线
输入是已批准的变更单。动作是按变更单实施修改，完成后对受影响部分做回归确认，确认无误后由配置管理员更新基线版本，并在后续阶段评审中引用最新版本。输出是新基线版本和变更关闭记录。完成标志是变更单关闭、基线清单版本号已更新、相关下游文档或计划同步调整。变更实施中发现影响超出原评估范围时，应重新评估，不直接在原变更单上扩大实施范围。
角色与交付物：谁在哪个环节签字负责
机制能否运转，取决于每个环节是否有人对结果负责、是否留下可查的记录。角色设置应结合团队规模调整，小团队可以一人兼多职，但签字责任不能合并到无人复核。
| 角色 | 基线建立 | 阶段评审 | 变更控制 | 主要交付物 |
|---|---|---|---|---|
| 项目经理 | 组织确定基线对象与冻结时点，维护基线清单 | 组织评审、控制节奏、跟踪整改关闭 | 受理变更申请，协调影响评估 | 基线清单、评审计划、变更台账 |
| 技术负责人 | 确认技术类交付物的冻结范围 | 把关技术评审项，给出技术结论 | 负责技术影响评估 | 技术评审意见、影响评估意见 |
| 配置管理员 | 执行冻结、打版本标识、登记基线 | 提供待评审版本及版本对比材料 | 更新基线版本，维护版本记录 | 版本记录、基线发布通知 |
| 评审人 | — | 按评审项核对并签字，提出整改意见 | 参与相关影响评估 | 评审记录与签字 |
| 变更审批人 | — | — | 依据评估结论做出批准或驳回决定 | 变更审批结论 |
关键交付物包括四类：基线清单，记录每个基线的对象、版本、冻结时间和责任人；评审记录，记录评审项、问题、结论和签字；变更单，记录申请内容、影响评估、审批结论和实施结果；版本记录，记录每次基线版本的变化及对应变更单编号。四类记录应能互相引用，从任一变更单可以查到它产生的新基线版本，从任一基线版本可以查到它由哪次评审放行、由哪些变更形成。
交接与留痕的要求是：评审结论未写入记录不算通过，变更未形成变更单不算批准，基线版本未登记不算生效。阶段交接时，下游阶段负责人应确认接收的基线版本号，避免出现“按旧版本开工”的情况。
在工具层面，ONES的项目计划支持创建工作分解结构，按目标、交付物或项目阶段分解计划，并可用里程碑标记重要时间点和决策点；项目计划和里程碑基线可用于对比计划与执行的偏差；版本细节对比可用于追溯变更。评审记录、变更单等表单的具体配置方式，建议在选型或实施时结合团队流程确认。
示例：一个需求变更如何穿过评审与基线
以下为演示情景，用于说明流程如何串联，不代表真实项目数据。
某企业内部系统项目在需求阶段评审通过后，需求规格形成基线 V1.0，评审记录注明通过日期和评审人签字，项目进入设计阶段。设计进行到一半时，业务方提出增加一个审批节点。此时变更申请进入通道，申请单写明新增审批节点的业务原因和期望上线时间。
影响评估围绕三方面展开：范围上，新增节点涉及需求规格中的流程定义和设计文档中的流程配置；进度上，需要评估设计返工和测试用例补充所需时间；已冻结基线上，需求规格 V1.0 和已启动的设计文档都受影响。评估结论形成书面意见，变更审批人据此批准变更，并明确实施顺序：先更新需求规格，再调整设计，最后补充测试用例。
实施完成后，配置管理员将需求规格更新为 V1.1，变更单记录关联 V1.1 版本号并关闭。设计阶段评审时引用的是需求规格 V1.1，而不是 V1.0，后续测试阶段也以 V1.1 为准。这样，从变更申请到新基线生效形成完整链条，后续阶段不会因为版本引用不一致而返工。
这个示例的关键在于：变更发生在评审通过之后，因此必须走变更通道；新基线在变更实施并确认后才形成，而不是在审批通过时就宣布生效；后续阶段评审引用最新版本，保证追溯链不断。
完成检查：机制是否真正运转
机制建立后，需要定期核对它是否在实际运转，而不只是停留在文档里。以下清单可逐项检查。
| 检查项 | 合格标准 | 常见失效信号 | 纠正动作 |
|---|---|---|---|
| 基线是否齐全 | 每个阶段都有明确基线对象和版本号 | 部分阶段无基线，或基线只存在于个人电脑 | 补齐基线清单，明确冻结时点 |
| 版本是否可追溯 | 从任一版本可查到对应评审和变更记录 | 版本号混乱，变更后未更新版本 | 统一版本标识规则，变更后强制更新 |
| 评审是否有记录 | 每次评审有记录、有明确结论、有签字 | 评审走过场，结论只有“基本通过” | 细化评审项，结论必须明确通过或不通过 |
| 变更是否全部走通道 | 所有基线后修改都有变更单 | 先改后补、口头同意即实施 | 将变更单作为实施前置条件 |
| 变更后基线是否同步 | 变更关闭时基线版本已更新 | 变更单关闭但基线仍是旧版本 | 把基线更新列为变更关闭的必要步骤 |
除逐项核对外，还可以观察几个整体信号：如果阶段评审经常在没有材料的情况下快速通过，说明评审关口形同虚设；如果变更单数量长期为零而实际修改不断发生，说明变更通道被绕过；如果下游阶段频繁发现与上游基线不一致的问题，说明基线发布和交接环节存在缺口。发现这些信号时，应先回到对应环节补齐记录和责任人，再继续推进阶段，避免问题累积到后期集中暴露。
常见问题
阶段评审没有通过时，已经准备好的基线材料怎么处理？
评审未通过时，该阶段基线不发布、不生效，流程回到当前阶段整改。已准备好的材料保留为待评审版本，由配置管理员登记但标注为未放行状态，避免下游阶段误引用。整改完成后重新组织评审，通过后再执行版本标识和基线发布。评审结论为有条件通过时，附加条件应写明责任人和关闭时间，条件关闭前同样不进入下一阶段。
变更审批通过后，新基线是立即生效还是等实施完成才生效？
新基线在变更实施并完成回归确认后才生效。审批通过只代表变更被允许实施，此时基线仍指向原版本；实施完成后由配置管理员更新版本标识，变更单关闭，新版本才作为后续阶段评审的引用对象。这样处理可以避免出现“审批已过、代码未改、下游却按新版本开工”的错位。如果实施中发现影响超出原评估范围，应重新评估，不在原变更单上直接扩大范围。
小团队人手有限，评审人和变更审批人可以是同一个人吗？
可以兼岗，但要保留复核环节。小团队中项目经理兼配置管理员、技术负责人兼评审人是常见做法，变更审批也可以由项目经理承担。需要守住的是：提出变更的人不单独决定变更是否批准，评审结论必须有签字记录。兼岗时建议在流程说明中写清每个环节的实际责任人，避免出现“大家都以为对方在把关”的情况。
基线冻结后，哪些修改可以不经过变更控制？
基线冻结针对的是已纳入基线的交付物，对这些内容的修改都应走变更通道。文字笔误、格式调整等不影响范围、进度和技术结论的修改，可以在流程中约定简化处理方式，但仍需登记，保证版本记录完整。判断标准是修改是否影响已冻结基线的实质内容，拿不准时按变更处理，比事后补记录成本更低。
用ONES承载这套机制时，哪些环节可以直接对应到产品能力？
ONES的项目计划支持创建工作分解结构，按目标、交付物或项目阶段分解计划，并可用里程碑标记重要时间点和决策点；项目计划和里程碑基线可用于对比计划与执行的偏差；版本细节对比可用于追溯变更。评审记录、变更单等表单的具体配置方式，建议在选型或实施时结合团队流程确认，本文不展开具体配置步骤。
