项目基线更新的做法是：先确认变更已获批准，再按“变更影响评估—更新范围界定—受控文件与计划修订—版本与记录归档—通知与再基线确认”的顺序执行，最后由项目经理组织核对新基线的一致性并留痕。关键是把更新限定在已批准的单项目约束调整内，需求对象本身的修改走需求变更流程。下文给出可直接照做的步骤、角色分工、完整示例与完成检查清单，并说明版本与记录如何借助ONES承载。
要点总览（TL;DR）
- 基线更新以变更获批为起点、以再基线确认为终点，中间按影响评估、范围界定、文件与计划修订、版本归档、通知确认五步推进，每步都有可核对的完成标志。
- 项目经理负责组织与最终确认，配置管理员负责版本与归档，审批者在变更批准和再基线确认两处签署，形成前后两道关口。
- 判断更新是否到位，看七项证据：变更批准、影响评估、更新范围清单、文件版本一致、旧版可追溯、通知有确认、新基线经签署生效。
- 版本留存、记录关联和通知确认容易散落在邮件与共享盘，把变更单、基线文件与版本记录放在同一管理对象下关联，检查时可直接取证。
- 本文范围限于单项目约束调整；需求对象本身的修改走需求变更流程，跨研发资产的变更治理另行处理。
基线更新的核心步骤与每步产出
基线更新的起点是变更批准，终点是再基线确认。中间每一步都要有明确输入、动作、输出和完成标志，避免“改完文件就算更新”的常见偏差。以下六步按顺序执行，前一步的完成标志即后一步的输入前提。
第一步：确认变更已获批准
输入是变更申请单及其审批记录。动作是核对批准范围：批准的是哪项约束调整（范围、进度、成本或质量），批准人是否具备对应权限，批准日期是否在有效期内。输出是一份可执行的变更批准结论。完成标志是变更单状态为“已批准”，且批准内容与拟调整的基线对象一一对应。未获批准的调整不得进入后续步骤。
第二步：变更影响评估
输入是已批准的变更单和现行基线文件。动作是逐项评估变更对范围、进度、成本、质量等约束的影响：范围上哪些交付物增减，进度上哪些里程碑移动及移动天数，成本上人力与采购是否变化，质量上验收标准与测试范围是否调整。输出是一份影响评估记录，列明受影响对象、影响程度和应对措施。完成标志是评估记录经相关职能负责人确认，且影响结论能支撑后续修订。
第三步：更新范围界定
输入是影响评估记录和基线文件清单。动作是明确哪些基线文件与计划需要修订、哪些保持不变。常见受控对象包括项目计划、里程碑清单、需求基线文档、验收标准、资源与预算表。输出是一份更新范围清单，逐项标注“修订/不变”及理由。完成标志是清单经项目经理确认，且没有遗漏评估中识别出的受影响对象。
第四步：修订受控文件与计划
输入是更新范围清单。动作是按清单逐项修订文件与计划，并在每份文件上标注新版本号、修订日期、修订人和修订说明。输出是修订后的受控文件与计划。完成标志是所有列入清单的文件均完成修订并标注版本，修订内容与影响评估结论一致。
第五步：归档记录与通知相关方
输入是修订后的文件与旧版本。动作是将旧版本移入归档区保留可追溯，将新版本纳入受控库，并向受影响的相关方发出更新通知，说明变更内容、生效时间和需要配合的事项。输出是版本归档记录和通知记录。完成标志是旧版本可查、新版本可获取、通知已送达并有回执或确认。
第六步：再基线确认
输入是新版本文件、归档记录和通知确认。动作是由项目经理组织核对新基线的一致性：文件之间是否互相引用正确、计划与里程碑是否对齐、版本号是否连续。输出是再基线确认记录。完成标志是确认记录经审批者签署，新基线正式生效，旧基线标记为“已被替代”。
谁来做：角色分工与交付物
基线更新涉及提出、评估、修订、归档、确认多个环节，职责不清最容易出现“文件改了但没人认账”。下表按角色列出职责边界与交付物，实际项目中一人可兼多角，但每项交付物必须有明确责任人。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 项目经理 | 组织整个更新过程，界定更新范围，主持再基线确认，对最终结果负责 | 更新范围清单、再基线确认记录 |
| 变更提出方 | 说明变更原因与期望结果，配合影响评估提供业务信息 | 变更申请单及补充说明 |
| 影响评估参与方（技术、测试、职能负责人） | 从各自专业角度评估变更对范围、进度、成本、质量的影响 | 影响评估意见 |
| 配置管理员或文档管理角色 | 维护受控库，执行版本标注、旧版归档、新版本入库 | 版本归档记录、受控文件清单 |
| 职能负责人 | 确认本职能相关计划修订的合理性与可执行性 | 计划修订确认意见 |
| 审批者 | 批准变更，签署再基线确认，对基线生效负责 | 变更批准记录、再基线确认签署 |
分工时注意两点：配置管理员负责版本与归档的技术动作，不承担内容正确性的判断；审批者的签署放在再基线确认环节，与变更批准形成前后两道关口，避免同一人既改又批而失去制衡。
一个基线更新的完整示例
以下为演示情景，不对应真实客户项目，仅用于说明流程如何落地。
情景设定：某单项目原计划10周完成，第4周时客户要求增加一项报表功能，导致测试范围扩大。项目经理判断这属于单项目约束调整，走基线更新流程。
变更批准：变更提出方提交申请，说明新增报表的业务价值。审批者批准，批准范围为“范围增加一项报表功能，进度顺延1周”。
影响评估：技术负责人评估开发工作量增加3人日；测试负责人评估测试用例增加约20条，测试周期延长2天；职能负责人确认人力可调配。评估结论汇总为影响评估记录。
更新范围界定：项目经理确认需修订项目计划、里程碑清单、需求基线文档和验收标准四份文件，预算表不变。
文件修订：四份文件分别升版，标注修订说明“新增报表功能，进度顺延1周”，修订人与日期记录在文件头。
版本记录与通知：配置管理员将旧版本归档，新版本入库，向开发、测试、客户对接人发出更新通知，说明生效时间与配合事项，收到三方确认回执。
再基线确认：项目经理核对四份文件引用一致、里程碑与计划对齐，审批者签署确认，新基线生效，旧基线标记为已被替代。整个过程从批准到确认用时3个工作日。
完成检查：基线更新是否做到位
更新完成后，可用以下清单逐项核对。每项给出通过标准，任一项不通过即视为更新未完成。
| 检查项 | 通过标准 |
|---|---|
| 变更批准记录 | 变更单状态为已批准，批准范围与本次调整一致，批准人具备对应权限 |
| 影响评估记录 | 覆盖范围、进度、成本、质量等约束，结论经相关职能负责人确认 |
| 更新范围清单 | 逐项标注修订或不变，无遗漏受影响对象 |
| 受控文件与计划版本 | 所有修订文件版本号连续、修订说明完整，内容与评估结论一致 |
| 旧版本可追溯 | 旧版本已归档，可查询、可对比，未被直接覆盖 |
| 通知与确认 | 受影响相关方均已收到通知，并有回执或确认记录 |
| 再基线确认 | 新基线经审批者签署，文件间引用一致，旧基线标记为已被替代 |
建议把这套检查项固化为更新后的评审动作，由项目经理主持、配置管理员提供版本证据，检查结果随变更单一起归档，便于后续审计和复盘。
用工具承载基线更新的记录与版本
上述流程中，版本留存、记录关联和通知确认是最容易在邮件与共享盘之间散落的部分。把变更单、基线文件、版本记录放在同一管理对象下关联，能让“哪次变更改了哪份文件、谁确认的”随时可查。ONES在项目计划与里程碑管理中支持设置基线并对比计划与执行的偏差，也支持通过对比版本细节追溯变更；围绕需求、基线、版本和变更建立统一管理对象，可支撑影响分析与交付结果回溯。对于需要把评审节点和交付物模板固化为执行流程的团队，这些流程要素也可以沉淀为可复用资产。
落到基线更新的具体动作：变更单与受控文件建立关联，影响评估记录作为变更单的附件留存；每次修订形成新版本，旧版本保留可对比；通知与确认在变更单上留痕，再基线确认由审批者在同一记录上签署。这样，检查清单中的每一项都能在工具中找到对应证据，而不必另行翻找邮件或本地目录。具体操作入口与权限配置以实际使用版本的说明为准。
常见问题
变更已经口头同意，可以先改文件再补审批吗？
不建议。基线更新的第一步就是确认变更已获批准，批准范围要与拟调整的基线对象一一对应。口头同意缺少批准人、批准范围和日期记录，后续影响评估和再基线确认都失去依据，检查清单第一项就无法通过。
如果时间紧张，可以先完成影响评估供审批者判断，但文件修订应在批准之后进行，避免出现“先改后批”导致版本记录与审批记录对不上。
影响评估要评估到什么颗粒度才算够？
评估颗粒度以能支撑修订决策为准。范围上要列出增减的交付物，进度上要指明移动的里程碑及天数，成本上说明人力与采购变化，质量上说明验收标准与测试范围的调整。
每项影响都应有对应职能负责人的确认意见。评估结论如果无法回答“哪份文件要改、改成什么样”，说明颗粒度还不够，需要补充后再进入范围界定。
旧版本文件可以直接覆盖或删除吗？
不能覆盖。旧版本需要移入归档区保留可追溯，新版本纳入受控库，两者并存才能支撑后续对比和审计。检查清单中“旧版本可追溯”一项要求旧版可查询、可对比，未被直接覆盖。
归档时建议同时记录归档时间、归档人和替代关系，便于日后回溯某次变更前后的差异。
通知发出去了，但相关方没有回复，算完成吗？
不算。通知环节的完成标志是通知已送达并有回执或确认，仅有发送记录不足以证明受影响方已知悉变更内容和生效时间。
实际操作中可以设定确认期限，到期未回复的由项目经理逐一跟进，确认记录随变更单一起归档。这样再基线确认时才有完整的通知证据链。
需求内容本身的修改，也走这套基线更新流程吗？
不走。本文的基线更新限定在已批准的单项目约束调整，例如进度顺延、范围增减带来的计划与基线文件修订。需求对象本身的修改属于需求变更与版本管理的范围，跨研发资产的变更治理与影响分析另有对应流程。
两类流程会在项目层面衔接：需求变更获批后，如果引起项目约束调整，再触发本文所述的基线更新动作。
用工具管理基线更新，至少要留存哪些记录？
至少三类：变更单及其审批记录、影响评估记录、受控文件的版本记录。ONES 在项目计划与里程碑管理中支持设置基线并对比计划与执行的偏差，也支持通过对比版本细节追溯变更；围绕需求、基线、版本和变更建立统一管理对象，可支撑影响分析与交付结果回溯。
把变更单与受控文件关联、影响评估作为附件留存、通知与确认在变更单上留痕，检查清单的每一项都能找到对应证据。具体操作入口与权限配置以实际使用版本的说明为准。
