进度基线是经评审确认、用于对比实际进展的计划版本。它把范围、任务、工期、依赖和关键路径固定下来，让后续的进度偏差有统一参照。建立基线要先备齐输入再定版冻结，变更则要走申请、影响评估、审批和发布新版本的受控流程。本文按这两个阶段给出可执行步骤、角色分工、演示示例和完成检查清单。
要点总览（TL;DR）
- 进度基线是经评审确认、用于对比实际进展的计划版本；定版前先备齐范围、任务分解与估算依据、依赖与关键路径、资源日历和评审角色五类输入。
- 建立基线按排任务与依赖、识别关键路径、确认资源与工期、基线评审、定版冻结与版本记录五步推进，定版后基线不再直接编辑，日常执行数据正常更新。
- 涉及范围、工期、依赖或关键路径的调整走变更流程：提交申请、评估工期与资源影响、按影响程度审批、发布新版本并保留旧版本。
- 偏差分析要明确对比口径：实际进展对比当前基线，历史阶段对比当时生效的基线，避免用新基线回溯评价过去执行。
- 用版本唯一性、变更审批记录、关键路径影响评估、旧版本保留、对比口径一致等检查项验收基线管理是否到位。
建立进度基线前要准备什么
基线一旦定版，就会成为后续偏差分析的基准，因此定版前要把计划本身的不确定性降到可接受水平。范围、依赖和估算依据不清时仓促定版，后续会出现大量“基线本身就不合理”的变更申请，审批也会失去意义。准备工作围绕五类输入展开。
基线建立输入清单
| 输入项 | 应包含的内容 | 合格判断 |
|---|---|---|
| 范围与交付物清单 | 项目目标、主要交付物、验收口径、明确排除的事项 | 每个交付物有负责人和完成定义，范围外事项已列明 |
| 任务分解与工期估算依据 | 工作分解结构、任务清单、估算方法（类比、参数、专家判断等）及依据 | 任务颗粒度可分配到人，估算有可追溯的依据而非拍脑袋 |
| 依赖关系与关键路径 | 任务间前后置依赖、外部依赖、关键路径初步识别结果 | 关键路径上的任务已标注，外部依赖有对接人和时间承诺 |
| 资源、日历与约束条件 | 人员可用性、技能匹配、节假日与工作日历、硬性截止日期、预算或人力上限 | 资源冲突已识别，日历口径统一，硬约束已写入计划 |
| 评审参与角色 | 项目经理、任务负责人、职能负责人、审批人、必要的技术或业务专家 | 评审人已确定并有时间参加，审批人有权对基线定版作出决定 |
这份清单的用途是评审前的自检：任何一项缺失或明显不可靠，都应先补齐再进入排计划环节。范围频繁变动的项目，可以先按已确认的部分建立基线，把待定事项列为假设条件并注明复核时间，避免无限期推迟定版。
进度基线的建立步骤
建立基线是从计划草案到受控版本的转化过程，每一步都有明确输入、动作、输出和完成标志。下表给出五个步骤的操作口径。
基线建立操作步骤表
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 排定任务与依赖 | 工作分解结构、任务清单、估算依据 | 按交付物或阶段组织任务，逐条设置前后置依赖，标注外部依赖和责任人 | 带依赖关系的进度计划草案 | 所有任务有负责人和工期，依赖无遗漏、无循环 |
| 2. 识别关键路径 | 进度计划草案 | 计算任务最早开始、最晚开始与浮动时间，标出决定项目总工期的任务链 | 关键路径清单及浮动时间表 | 关键路径任务已标注，关键路径上的风险点已列出 |
| 3. 确认资源与工期 | 关键路径清单、资源与日历约束 | 核对关键路径任务的资源可用性，处理资源冲突，必要时调整工期或顺序并记录理由 | 资源已平衡的进度计划 | 无未解决的资源超配，工期调整均有依据 |
| 4. 基线评审 | 进度计划、输入清单、风险说明 | 组织评审会，逐项确认范围、依赖、关键路径、资源和假设条件，记录评审意见与处理结论 | 评审记录与修订后的计划 | 评审意见全部关闭或有明确处理方案，审批人同意定版 |
| 5. 定版冻结与版本记录 | 评审通过的计划 | 将计划冻结为基线版本，记录版本号、定版日期、审批人和基线内容摘要，通知相关方 | 基线版本记录与发布通知 | 基线版本唯一可查，团队按同一版本执行 |
定版冻结的含义是：基线版本不再直接编辑，日常执行中的任务状态、实际开始与完成时间、剩余工时等数据正常更新，这些更新不改变基线本身。需要调整范围、工期、依赖或关键路径时，进入变更流程。版本记录至少包含版本号、定版时间、审批人、与上一版本的差异摘要，便于后续追溯。
在工具层面，ONES 的项目计划支持创建工作分解结构、为任务设置前后置依赖，并可设置项目计划和里程碑基线，用于对比计划与执行的偏差、通过版本细节追溯变更。基线创建与冻结的具体操作路径和权限设置，需按团队实际使用的版本确认。
基线变更的触发条件与审批流程
基线管理的难点在于区分两类更新：执行数据的日常更新直接记录，不触发审批；改变承诺内容的调整才走基线变更。判断标准是看调整是否影响已定版的范围、工期、依赖关系或关键路径。
哪些情况需要变更基线
- 范围增减或交付物验收标准发生实质变化，导致任务和工期需要重排。
- 关键路径任务的工期调整，或关键路径本身因依赖变化而改变。
- 外部依赖的时间承诺变化，例如供应商交付推迟、接口方排期调整。
- 资源发生重大变化，如核心人员长期不可用、预算削减导致工作包取消。
- 经批准的赶工或顺延方案，需要形成新的承诺版本。
任务状态推进、实际工时记录、非关键路径任务在浮动时间内的微调，属于正常执行更新，不需要变更基线。若这类微调累积到影响关键路径或总工期，再按变更处理。
变更申请应包含的信息
一份可审批的变更申请应说明：变更原因与背景、涉及的任务和交付物范围、对总工期和关键路径的影响、对资源的影响、备选方案比较（赶工、顺延、缩减范围等）及推荐方案、不变更的后果、申请人及期望审批时限。信息不足的申请应退回补充，避免审批人凭印象决策。
审批层级与权限
审批层级按影响程度设置，常见做法是：影响在项目内部可消化、不改变对外承诺的，由项目经理审批并报备；影响总工期或跨项目资源的，由职能负责人或项目发起人审批；影响合同交付、对外承诺或预算的，提交更高层级决策。具体权限应在项目启动时写入管理约定，避免每次变更临时找人。
新版本发布与旧版本保留
审批通过后，按批准方案调整计划并发布新基线版本，版本号递增，记录变更单号、审批结论和生效时间，同时通知执行团队。旧版本保留不删除，用于偏差对比和历史追溯。偏差分析时明确对比口径：实际进展对比当前基线，历史阶段对比当时生效的基线，避免用新基线回溯评价过去的执行。
ONES 在 ALM 方案中围绕需求、基线、版本和变更建立统一管理对象，支撑变更影响分析和交付结果回溯；该描述面向需求基线场景，进度基线的变更审批节点与流程配置需结合团队实际设置确认。
角色分工与各阶段交付物
基线管理的责任要落到具体角色，每个阶段都有对应的产出和归档要求。下表按角色列出职责与交付物。
角色职责与交付物对照表
| 角色 | 建立阶段职责 | 变更阶段职责 | 主要交付物 |
|---|---|---|---|
| 项目经理 | 组织任务分解与排期，汇总输入清单，发起并主持基线评审，完成定版与版本记录 | 受理变更申请，组织影响评估，提交审批，发布新版本并通知相关方 | 进度计划、评审记录、基线版本记录、变更单、发布通知 |
| 任务负责人 | 提供任务工期估算依据，确认依赖关系，参与评审 | 提出变更需求，说明原因与影响，执行批准后的调整 | 任务估算说明、变更申请素材、执行进展记录 |
| 职能负责人 | 确认资源可用性与技能匹配，承诺外部依赖时间 | 评估资源影响，参与跨项目资源调整的审批 | 资源承诺记录、资源影响评估意见 |
| 审批人 | 参加基线评审，对定版作出决定 | 审批变更申请，对超出授权范围的变更提交上级决策 | 评审结论、审批意见与签字记录 |
| 执行成员 | 按分配任务确认工期可行性 | 按新版本执行，反馈实际进展 | 任务执行记录、偏差反馈 |
归档要求与阶段对应：建立阶段归档输入清单、评审记录和基线版本记录；变更阶段归档变更申请、影响评估、审批记录、新旧版本对照和发布通知。归档的目的不是留痕本身，而是让下一次偏差分析能回答“当时为什么这样定、后来为什么这样改”。
示例：一次基线变更如何走完流程
以下为演示情景，用于说明流程走法，不代表真实项目或客户案例。
某系统集成项目已定版基线 V1，关键路径为“接口开发—联调—验收测试”。执行到联调阶段时，项目经理发现第三方接口方交付推迟两周，联调任务无法按原计划开始，后续验收测试和总工期均受影响。
偏差发现与原因说明
项目经理在周度进度对比中发现联调任务实际开始时间晚于基线，且第三方交付确认函显示推迟两周。原因归类为外部依赖变化，不属于执行效率问题，需要变更基线而非仅更新任务状态。
变更申请填写
变更申请写明：变更原因（第三方接口交付推迟两周）、影响范围（联调及其后续验收测试）、工期影响（总工期顺延两周）、关键路径影响（关键路径不变，但整体后移）、资源影响（测试人员档期需重新协调）、备选方案（方案一顺延两周；方案二增加内部人力先行完成可测部分，压缩一周，但增加人力成本）、推荐方案与不变更的后果。
影响评估与方案比较
任务负责人和职能负责人分别确认联调工作量与测试资源可行性。比较结论：方案二可压缩一周，但需要额外人力且存在质量风险；方案一稳妥但影响对外交付承诺。由于涉及对外承诺，提交项目发起人审批。
审批与发布
项目发起人批准方案一，要求同步告知客户并更新交付计划。项目经理据此调整计划，发布基线 V2，记录变更单号、审批结论和生效日期，保留 V1 用于历史对比，并向团队和客户发出通知。
后续跟踪
此后每周按 V2 对比实际进展，重点跟踪联调开始时间和测试资源到位情况。若第三方再次推迟，按同一流程发起新的变更，不直接在 V2 上修改。阶段复盘时对比 V1 与 V2 的差异，评估外部依赖管理是否需要加强。
完成检查：基线建立与变更是否到位
以下检查项用于项目阶段评审或基线管理自查，每项给出可核验的通过标准。
基线管理检查清单
| 检查项 | 通过标准 |
|---|---|
| 基线版本是否唯一可追溯 | 当前生效基线只有一个版本号，版本记录包含定版时间、审批人和内容摘要，能查到历史各版本 |
| 变更是否有申请与审批记录 | 每次基线调整都有对应变更单，申请信息完整，审批人和审批结论可查 |
| 关键路径影响是否评估 | 变更申请中明确说明对关键路径和总工期的影响，评估结论有依据 |
| 旧版本是否保留 | 历史基线版本未删除，可调取用于偏差对比和追溯 |
| 偏差对比口径是否一致 | 偏差分析明确对比的是哪个基线版本，历史评价使用当时生效的基线 |
| 执行更新与基线变更是否区分 | 任务状态和实际工时正常更新，未混入基线变更；影响承诺的调整均走了审批 |
| 相关方是否知悉当前基线 | 团队和相关方按同一版本执行，发布通知可查 |
检查中发现版本不唯一、变更无审批或旧版本缺失的，应先补齐记录再继续执行，否则后续偏差数据失去参照意义。基线管理的目标是让计划与执行之间的差异可解释、可追溯，检查清单正是对这一目标的逐项验证。
常见问题
项目范围还没完全确定，可以先建立进度基线吗？
可以按已确认的部分先建立基线，把待定事项列为假设条件，注明复核时间和责任人。这样团队有统一的执行参照，后续待定事项明确后再走变更流程调整。需要避免的是在范围、依赖和估算依据都不可靠时仓促定版，否则后续会出现大量“基线本身不合理”的变更申请，审批失去意义。
任务实际开始时间晚了几天，需要发起基线变更吗？
先判断影响是否触及承诺内容。任务状态推进、实际工时记录、非关键路径任务在浮动时间内的微调，属于正常执行更新，直接记录即可。若延误发生在关键路径上，或累积到影响总工期、改变依赖关系，就需要按变更流程处理。判断标准是看调整是否影响已定版的范围、工期、依赖关系或关键路径。
基线变更由谁审批，审批层级怎么定？
按影响程度分层设置，并在项目启动时写入管理约定。影响在项目内部可消化、不改变对外承诺的，由项目经理审批并报备；影响总工期或跨项目资源的，由职能负责人或项目发起人审批；影响合同交付、对外承诺或预算的，提交更高层级决策。提前约定权限可以避免每次变更临时找人拍板。
新基线发布后，旧版本还需要保留吗？
需要保留，不删除。旧版本用于偏差对比和历史追溯，阶段复盘时可以对比新旧版本的差异，评估当时的决策依据。偏差分析时明确口径：实际进展对比当前生效基线，历史阶段对比当时生效的基线，避免用新基线回溯评价过去的执行表现。
ONES 在进度基线的建立和变更中能提供哪些支撑？
ONES 的项目计划支持创建工作分解结构、为任务设置前后置依赖，并可设置项目计划和里程碑基线，用于实时对比计划与执行的偏差，通过版本细节追溯变更。ONES ALM 方案围绕需求、基线、版本和变更建立统一管理对象，支撑变更影响分析和交付结果回溯，该描述面向需求基线场景。基线创建冻结的具体操作路径、权限设置以及变更审批的流程配置，需按团队实际使用的版本确认。
