计划基线遗漏和计划变更的分界在基线确认时点：基线确认前本应写入计划或基线的内容没有写进去，属于遗漏；基线确认后因范围、条件或优先级变化，经审批对已批准计划做正式调整，属于变更。执行中的进度偏差、任务排期细化、未影响基线的说明性补充，以及走变更流程的新增需求，都不算计划遗漏。
要点总览（TL;DR）
- 分界点在基线确认时点：确认前本应写入计划或基线的内容缺失属于遗漏；确认后因范围、条件或优先级变化经审批调整属于变更。
- 计划遗漏按内容分为四类：活动遗漏、依赖遗漏、交付物与责任遗漏、基线遗漏，四类可能同时出现。
- 基线遗漏多由编制输入不全、评审核对不到位、基线确认缺失或走过场逐步形成。
- 执行中的进度偏差、任务排期细化、未影响基线的说明性补充、经审批的正式变更、尚未进入计划范围的新增需求，都不算计划遗漏。
- 判断时先问该内容在基线确认前是否已经应当存在，再看当前动作是否改变了已批准的范围、交付物或责任。
一句话分清：基线遗漏与计划变更
计划基线遗漏，指在计划建立或基线确认环节，本该纳入范围、活动、依赖、交付物或责任人的内容没有被写进计划或基线，结果是计划本身不完整。计划变更，指基线确认之后，因范围、条件或优先级发生变化，按既定流程对已批准计划做的正式调整，结果是计划版本有意识地更新。
判断时先看一个时点：该内容在基线确认前是否已经应当存在。应当存在却没有写入，属于遗漏；基线确认后才出现的新增、删减或调整，走变更。再看处理动作：遗漏需要补全计划并说明缺口来源，必要时重新确认基线；变更需要提出申请、经过审批、留下记录，并更新基线版本。责任归属也不同，遗漏指向编制与评审环节的核对责任，变更指向提出方与审批方的决策责任。
| 对照项 | 计划基线遗漏 | 计划变更 |
|---|---|---|
| 发生时点 | 基线确认前或确认当时 | 基线确认之后 |
| 内容性质 | 本应存在却缺失 | 原有安排发生调整 |
| 典型动作 | 补全计划、重新核对、必要时重设基线 | 提出申请、审批、更新基线版本 |
| 关注重点 | 计划完整性 | 调整的合理性与可追溯性 |
计划遗漏的边界：哪些内容算漏了
计划遗漏按缺失内容可以分为四类。四类可能同时出现，但识别方式和补救动作不同，自查时应逐类核对。
- 活动遗漏：应做的任务没有列入计划。例如交付前必须完成的数据迁移、验收准备或培训安排，在计划中找不到对应活动。识别要点是拿交付物和业务过程反推：要完成这个成果，必须发生哪些动作。
- 依赖遗漏：任务之间的前后置关系没有记录。活动都列了，但接口开发与联调之间、供应商交付与内部装配之间没有建立依赖，排出来的顺序看似可行，执行时才发现等待关系。识别要点是检查每条任务的前置条件和交付输入是否对应到具体任务。
- 交付物与责任遗漏：成果物或负责人缺失。任务写了，但没有明确产出什么、由谁负责、谁验收。识别要点是逐条任务确认交付物名称、责任人和验收口径是否齐全。
- 基线遗漏：已确认的范围没有进入基线版本。计划文档里有这项内容，但基线冻结时没有纳入，导致后续对比计划与执行时看不到它。识别要点是对照批准的范围说明与基线版本，确认两者一致。
这四类的共同特征是：内容在基线确认前就应当存在。只要满足这个条件，无论缺失发生在活动层、依赖层、责任层还是基线版本层，都归入计划遗漏。
基线遗漏是怎么形成的：从计划建立到基线确认
基线遗漏通常不是某一个动作造成的，而是在计划编制、评审、基线确认三个环节中逐步形成的。
计划编制阶段的缺口多来自输入来源不全。编制者依据需求说明、交付物清单、资源安排和历史经验搭建工作分解结构，如果需求范围没有收敛、交付物清单不完整，或者跨团队接口没有提前确认，计划从起点就会缺项。这个阶段常见的表现是只分解了主要开发活动，遗漏了验收、上线准备、文档移交等支撑性工作。
评审环节的作用是对范围、依赖、责任做交叉核对。评审如果只走过场，看一遍任务列表就通过，活动之间的依赖关系、每条任务的责任人、交付物的验收口径往往不会被逐项检查。评审参与方不完整也会造成缺口，例如缺少运维、采购或外部供应商代表，相关活动就容易被忽略。
基线确认动作本身缺失或流于形式，是基线遗漏形成的最后一道缺口。基线的作用是把某一时点批准的计划固定下来，作为后续对比和变更的参照。如果团队没有执行基线确认，或者确认时没有对照批准范围逐项核对，计划文档里有的内容可能没有进入基线版本，后续就难以判断某项内容是原本就有还是后来补入。基线确认走过场还会带来一个后果：遗漏在很长时间内不被发现，直到执行受阻才暴露，此时补入的内容与变更混在一起，责任和记录都难以厘清。
在工具层面，计划编制、依赖设置和基线确认需要有对应的记录载体。以 ONES 为例，团队可以用项目计划搭建工作分解结构并制定进度计划，为任务设置前后置依赖、用里程碑标记关键时间点，并设置计划和里程碑基线；后续通过对比计划与执行的偏差、查看版本细节来追溯调整。具体能力以实际部署与套餐为准。
计划变更走的是另一条路：变更的成立条件
计划变更的成立需要同时满足几个条件，缺一项就容易退化成随意改计划或事后补记录。
- 有明确的触发来源：范围扩大或缩小、外部条件变化、优先级调整，或者关键资源与时间约束发生变化。触发来源应当可以描述，例如客户新增一项验收要求，或供应商交付时间推迟。
- 发生在基线确认之后：基线已经批准，原有安排是有效参照，调整才有变更的对象。
- 经过审批：由提出方说明调整内容、影响范围和应对措施，由有权决策的角色审批。审批的意义是确认调整值得做，并让相关方知晓影响。
- 留下记录并更新基线版本：变更内容、审批结论、生效时间进入记录，基线随之更新为新版本。旧版本保留，用于对比和追溯。
变更流程的价值在于把调整变成可追溯的决策。调整之后，团队能说清哪一版计划在什么时候因为什么原因被改过，而不是面对一份与最初版本无从对比的计划。ONES 的版本对比能力可用于追溯变更细节，审批流程与记录形式以实际部署为准。
哪些情况不算计划遗漏
以下情形容易被误判为遗漏，判断时按各自归属处理即可。
| 情形 | 为什么不算遗漏 | 应归入的处理类别 |
|---|---|---|
| 执行中的进度偏差与延期 | 计划内容完整，实际进展与计划出现差距 | 执行偏差管理，分析原因并采取纠偏措施 |
| 任务排期的细化与拆分 | 原有任务仍在计划范围内，只是颗粒度变细 | 排期管理，在计划内调整任务层级与时间安排 |
| 未影响基线的说明性补充与澄清 | 不改变范围、交付物和责任，只是把已有内容说清楚 | 计划文档维护，补充说明即可 |
| 经审批的正式变更 | 内容在基线确认后才出现，且走了审批流程 | 计划变更管理，更新基线版本 |
| 尚未进入计划范围的新增需求 | 基线确认时并不存在，不属于本应写入的内容 | 需求管理与变更管理，评估后决定是否纳入计划 |
这张表的使用方法是先定位情形，再问两个问题：该内容在基线确认前是否已经应当存在；当前动作是否改变了已批准的范围、交付物或责任。两个问题的答案都是否，就不属于计划遗漏。
相邻概念区别：遗漏、变更、偏差与排期细化
四个概念容易混用，原因在于它们都表现为“计划和实际不一样”。区别在于不一样发生在哪个层面，以及对应的管理动作是什么。
| 概念 | 核心特征 | 处理动作 | 记录方式 |
|---|---|---|---|
| 计划遗漏 | 基线确认前本应存在的内容缺失 | 补全计划，核对范围、依赖与责任，必要时重设基线 | 记录缺口内容与补全结果，说明遗漏来源 |
| 计划变更 | 基线确认后经审批调整已批准计划 | 提出申请、审批、更新基线版本 | 变更申请、审批结论、新旧版本对比 |
| 执行偏差 | 计划完整，实际进度或成本与计划出现差距 | 分析原因，采取纠偏或调整资源 | 进度对比记录、偏差分析与纠偏措施 |
| 排期细化 | 计划范围内任务颗粒度变细或时间微调 | 在计划内拆分任务、明确时间安排 | 任务层级与排期更新记录 |
遗漏与变更的分界在时点和内容性质；遗漏与偏差的分界在计划本身是否完整，偏差的前提是计划内容齐全；遗漏与排期细化的分界在是否新增了本应存在的范围，细化只是把已有任务拆得更小。执行偏差的具体处置属于项目进度管理范畴，任务排期与依赖排布属于任务排期与依赖管理范畴，本文只做边界说明。
具体例子与常见误解
基线遗漏示例。某系统上线项目在编制计划时列出了开发、测试和部署活动，基线确认后进入执行。联调阶段团队发现，上线前必须完成的历史数据清洗没有出现在计划中，也没有对应责任人和交付物。这项工作在基线确认前就应当存在，属于活动遗漏与责任遗漏并存。处理方式是补全任务、明确负责人和验收口径，评估对上线时间的影响，并检查基线版本是否需要重新确认。这里的关键是：缺失内容在基线确认前已经应当存在。
计划变更示例。同一项目基线确认后，客户提出增加一个报表导出功能，并要求提前一周上线。这是基线确认后出现的新增范围和优先级调整，应走变更流程：提出变更申请，说明新增工作量、对原有任务的影响和上线时间调整方案，经审批后更新计划与基线版本，保留旧版本用于对比。这里的关键是：内容在基线确认时并不存在，调整经过审批并有记录。
常见误解一：把变更当遗漏追责。基线确认后按流程审批的范围调整，是正常的计划变更。如果把它当作遗漏去追究编制者的责任，会打击团队提出变更的意愿，导致调整被隐藏或拖延。正确的做法是核对变更记录，确认审批是否完整。
常见误解二：把偏差当遗漏补计划。执行延期时，如果直接把原计划改掉或补入新任务来“对齐”实际，会掩盖偏差原因，也让后续对比失去参照。偏差应当单独分析原因，补计划只适用于确实存在的内容缺失。
常见误解三：把排期细化当成计划不完整。把一项任务拆成若干子任务、调整具体时间安排，只要不改变范围和交付物，属于排期管理动作，不需要按遗漏处理，也不需要走变更审批。
常见问题
基线确认时漏掉的内容，后来在执行中补进计划，算遗漏还是变更？
先看这项内容在基线确认前是否已经应当存在。如果它属于已批准范围，只是确认时没有进入基线版本，属于基线遗漏，处理动作是补全计划、核对范围与责任，并视情况重新确认基线。如果它是在基线确认后才出现的新增范围或优先级调整，即使执行中才补进计划，也应当走变更流程，经审批后更新基线版本。两种情形可能同时出现，建议分别记录：遗漏部分说明缺口来源，变更部分保留申请与审批记录。
计划变更被驳回后，原计划没动，这算不算计划遗漏？
不算。变更申请被驳回说明调整未被批准，原计划继续有效，计划内容本身没有缺失。这种情况属于变更决策的结果，应保留申请与驳回记录，说明评估结论和理由。只有当原计划在基线确认前就漏掉了本应存在的内容时，才按遗漏处理。把驳回的变更当遗漏去补计划，会让计划偏离已批准的基线，后续对比也失去参照。
项目执行中把一项任务拆成多个子任务，需要走变更审批吗？
通常不需要。任务拆分属于排期细化，原有任务仍在计划范围内，范围、交付物和责任没有改变，只是在计划内调整颗粒度和时间安排。需要走变更的是范围增减、交付物变化、责任主体调整或关键时间约束改变这类影响已批准基线的事项。如果拆分过程中发现原计划确实漏掉了本应存在的活动，那部分按遗漏补全，与拆分动作分开处理。
团队没有正式做过基线确认，还能判断哪些是计划遗漏吗？
可以判断，但需要先补一个参照。基线确认的作用是把某一时点批准的计划固定下来，缺少这个动作时，可以用已批准的范围说明、交付物清单和评审记录作为替代参照，逐项核对计划中是否缺少本应存在的活动、依赖、交付物或责任人。需要留意的是，缺少基线会让遗漏与后续调整混在一起，难以区分责任和记录。建议在补全计划的同时建立基线，后续调整统一走变更流程。
跨团队接口没有写进计划，属于依赖遗漏还是活动遗漏？
要看缺失的具体内容。如果接口对接这项工作本身没有列入计划，属于活动遗漏；如果双方任务都列了，但彼此之间的前后置关系没有记录，属于依赖遗漏。实际场景中两者常同时出现：既没有安排联调活动，也没有标注联调与各自开发任务之间的等待关系。补全时建议同时处理，先补活动，再为活动设置前置条件和交付输入，确认每条任务都能对应到具体的前后置任务。
