项目变更日志至少要保留六类信息：变更标识与提出信息、变更前后的基线内容、变更原因与依据、影响评估结论、审批与决策记录、实施与关闭结果。每条记录都应能回答“谁在什么时候、基于什么理由、把哪项约束从什么改成什么、经过谁批准、实际落地到什么程度”。本文的范围限于单项目约束调整的变更记录；需求对象本身的修改归需求变更与版本管理，跨研发资产的变更治理归研发变更控制。
要点总览（TL;DR）
- 项目变更日志至少保留六类信息：变更标识与提出、变更前后基线内容、原因与依据、影响评估结论、审批与决策记录、实施与关闭结果。
- 建表时按六类分组区分必填与选填，必填字段保证每条记录可追溯，选填字段补充背景与关联链接。
- 填写按提出登记、前后对照、原因依据、影响评估、审批决策、实施关闭六步推进，每步有输入、动作、输出和完成标志。
- 提出人、项目经理、评估责任人、审批人、实施验证人各填自己负责的字段，审批与实施分离时在日志中留下条件交接痕迹。
- 缺少审批记录或影响评估的记录不得关闭，日志在提出、评估、审批、实施四个节点更新并定期核对编号连续性与状态闭环。
一份可用的变更日志先定字段框架
建表时先把字段按六类信息分组，再区分必填与选填。必填字段保证每条记录可追溯，选填字段用于补充背景。分组的好处是：填表人知道当前该填哪一段，检查人也能按组核对，避免只记了“改了什么”却说不清“为什么改、谁批的”。
| 字段名 | 所属分组 | 必填/选填 | 填写要点 |
|---|---|---|---|
| 变更编号 | 标识与提出 | 必填 | 项目内唯一、连续，便于引用与检索 |
| 提出人、提出时间 | 标识与提出 | 必填 | 记录到人、到日期，多人提出时列主提人 |
| 涉及约束项 | 标识与提出 | 必填 | 写明是范围、进度、成本、质量中的哪一项或哪几项 |
| 原基线值 | 变更前后内容 | 必填 | 引用已批准的基线，写具体数值或版本 |
| 拟变更值 | 变更前后内容 | 必填 | 与基线值同口径，便于直接对照 |
| 受影响工作项或交付物 | 变更前后内容 | 必填 | 列出被牵动的工作项、里程碑或交付物 |
| 触发事件 | 原因与依据 | 必填 | 写清是什么事件或发现引出了这次变更 |
| 依据文件或决策来源 | 原因与依据 | 必填 | 引用会议纪要、客户函件、评估报告等 |
| 影响评估结论 | 影响评估 | 必填 | 按范围、进度、成本、质量分维度给结论 |
| 评估人、评估时间 | 影响评估 | 必填 | 记录实际做评估的人，便于回溯 |
| 审批人、审批结论 | 审批决策 | 必填 | 写明同意、不同意或有条件同意 |
| 审批时间、附加条件 | 审批决策 | 必填 | 附加条件要可执行、可验证 |
| 实际执行结果 | 实施与关闭 | 必填 | 写实际落地情况，与拟变更值对照 |
| 生效时间、验证人 | 实施与关闭 | 必填 | 记录生效日期和完成验证的人 |
| 关闭状态 | 实施与关闭 | 必填 | 已关闭、实施中、已取消等明确状态 |
| 备注、关联链接 | 各分组通用 | 选填 | 补充上下文或指向申请单、纪要 |
字段与追溯问题的对应关系可以这样理解：标识与提出回答“谁提的、什么时候提的”；前后内容回答“从什么改成什么”；原因与依据回答“为什么改”；影响评估回答“改了会牵动什么”；审批决策回答“谁批的、批的条件是什么”；实施与关闭回答“最后落地到什么程度”。六组字段各管一个问题，缺一组，追溯链就断一环。
逐字段填写：从提出到关闭的操作步骤
填写按变更生命周期推进，每一步都有明确的输入、动作、输出和完成标志。按顺序填，能减少漏项，也方便交接。
第一步：提出登记
输入是变更诉求或触发事件；动作是分配变更编号，登记提出人、提出时间和涉及的约束项；输出是一条待评估的记录；完成标志是编号已分配、约束项已写明。编号在项目内连续，不要跳号或复用。
第二步：前后对照
输入是已批准的基线和拟调整内容；动作是填写原基线值、拟变更值，并列出受影响的工作项或交付物；输出是可直接对照的前后差异；完成标志是前后值同口径、受影响对象已列全。基线值要引用已批准的版本，避免拿草稿做对照。
第三步：原因与依据
输入是触发事件和相关文件；动作是写清事件经过，并引用依据文件或决策来源；输出是可核查的变更理由；完成标志是依据可定位到具体文件或会议。只写“客户要求”不够，要能指向具体函件或纪要。
第四步：影响评估
输入是前后差异和受影响对象；动作是按范围、进度、成本、质量等维度逐项评估，记录评估人和评估时间；输出是分维度的评估结论；完成标志是每个受影响维度都有结论，没有遗漏。评估结论要具体，例如工期顺延多少天、成本增减多少，避免只写“有一定影响”。
第五步：审批决策
输入是评估结论；动作是提交审批，记录审批人、审批结论、审批时间和附加条件；输出是可执行的决策记录；完成标志是结论明确、附加条件可验证。有条件同意时，条件要写成可检查的事项，而不是笼统的“注意风险”。
第六步：实施与关闭
输入是审批通过的变更；动作是记录实际执行结果、生效时间、验证人和关闭状态；输出是闭环记录；完成标志是实际结果与拟变更值完成对照、验证人已确认、状态已置为关闭。实际结果与计划不一致时，要在记录中说明差异原因。
角色分工与各环节交付物
变更日志由多人共同维护，各角色只填自己负责的字段，避免变成项目经理一个人的补记。职责边界清楚，记录痕迹才完整。
| 角色 | 主要动作 | 在日志中留下的记录 | 交付物 |
|---|---|---|---|
| 提出人 | 发起变更、说明诉求 | 提出人、提出时间、约束项、触发事件 | 变更申请单 |
| 项目经理 | 分配编号、组织评估、跟踪闭环 | 变更编号、状态维护、关闭确认 | 变更日志主记录 |
| 评估责任人 | 按维度做影响评估 | 评估结论、评估人、评估时间 | 影响评估说明 |
| 审批人 | 审阅并给出决策 | 审批结论、审批时间、附加条件 | 审批意见 |
| 实施与验证人 | 执行变更并验证结果 | 实际执行结果、生效时间、验证人 | 实施与验证记录 |
审批与实施由不同人承担时，交接要留下痕迹：审批人把附加条件写进日志，实施人按条件执行并在实际结果中逐条回应，验证人确认后再关闭。这样即使人员变动，后续接手的人也能从日志看出条件是否落实。
填写示例：一次工期约束调整的完整记录
以下为演示情景，用于说明字段如何填满，不代表真实项目数据。背景是某单项目因外部依赖延迟，需要调整里程碑工期。
| 字段 | 填写内容 |
|---|---|
| 变更编号 | CR-2024-017 |
| 提出人、提出时间 | 张工，2024-06-03 |
| 涉及约束项 | 进度 |
| 原基线值 | 里程碑M2计划完成日2024-06-28（基线V1.2） |
| 拟变更值 | 里程碑M2计划完成日调整为2024-07-12 |
| 受影响工作项或交付物 | M2验收、联调工作项、交付物D3 |
| 触发事件 | 外部接口提供方延迟交付，联调无法按原计划启动 |
| 依据文件或决策来源 | 接口方延期通知函、6月3日项目周会纪要 |
| 影响评估结论 | 进度顺延14天；成本增加少量加班投入；范围与质量不受影响 |
| 评估人、评估时间 | 李工，2024-06-04 |
| 审批人、审批结论 | 王经理，有条件同意 |
| 审批时间、附加条件 | 2024-06-05；条件为7月5日前完成联调环境准备 |
| 实际执行结果 | M2于2024-07-12完成，联调环境7月3日就绪，条件已满足 |
| 生效时间、验证人 | 2024-07-12，赵工 |
| 关闭状态 | 已关闭 |
容易漏填的字段有三处：一是原基线值没写版本，事后无法确认对照的是哪版计划；二是附加条件只写“注意进度”，实施人无法逐条回应；三是实际执行结果直接抄拟变更值，没有记录条件是否满足。漏填的后果是追溯时说不清变更是否真正落地，验收和复盘都缺少依据。
日志维护与完成检查
日志要持续可用，更新时点和责任人要固定下来。建议在变更提出、评估完成、审批完成、实施完成四个节点各更新一次，分别由提出人、评估责任人、审批人和实施验证人补充对应字段，项目经理负责状态维护和最终关闭。
日常检查关注三项：编号是否连续、有无跳号或重复；每条记录状态是否闭环，实施中的记录是否有明确下一步；日志与变更申请单、会议纪要等证据是否能一一对应。证据对不上的记录，要回到源头补齐，而不是在日志里改数字。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 编号连续性 | 项目内编号连续、无重复 | 日志编号列 | 项目经理 |
| 六类字段完整 | 必填字段无空缺 | 日志记录本身 | 项目经理 |
| 前后值同口径 | 基线值与拟变更值可直接对照 | 基线版本、变更申请单 | 提出人 |
| 影响评估齐全 | 受影响维度均有结论 | 影响评估说明 | 评估责任人 |
| 审批记录可查 | 审批人、结论、时间、条件齐全 | 审批意见 | 审批人 |
| 实施结果已验证 | 实际结果与拟变更值对照、验证人确认 | 实施与验证记录 | 实施验证人 |
| 状态闭环 | 无长期停留在实施中的记录 | 日志状态列 | 项目经理 |
阻断项要明确：缺少审批记录或影响评估的记录不得关闭，即使实施已经完成，也要先补齐审批和评估再置为关闭。这条规则保证日志里的每条关闭记录都经得起复盘检查。
当变更记录需要与工作项状态、审批流转和文档证据放在同一处管理时，可以把日志字段对应到工作项属性，把审批意见和会议纪要作为附件关联到记录上，让状态变更和证据留存同步完成。ONES 支持在工作项中维护自定义字段、记录审批过程并关联文档，适合承载这类单项目变更记录的日常维护；具体字段配置可按项目实际约束调整。
常见问题
变更日志里的原基线值应该引用哪个版本？
引用已批准生效的基线版本，并在字段中写明版本号，例如“基线V1.2”。如果项目在变更前刚更新过基线，以最新批准版本为准；草稿或未评审的计划不作为对照依据。基线版本写清楚，后续复盘时才能确认这次变更是相对哪一版计划做出的调整。
审批结论是“有条件同意”时，日志里要记到什么程度？
附加条件要写成可执行、可验证的事项，并记录条件对应的完成时点或检查方式。实施人在“实际执行结果”中逐条回应条件是否满足，验证人确认后再关闭。只写“注意风险”“控制进度”这类笼统表述，实施人无法逐条回应，复盘时也判断不了条件是否落实。
变更实施到一半被取消，日志状态怎么处理？
把关闭状态置为“已取消”，并在实际执行结果中说明取消原因、已执行部分的影响以及是否需要回退。取消同样属于状态闭环，不能长期停留在“实施中”。如果取消涉及已生效的基线调整，还要记录基线是否恢复以及恢复的依据。
需求本身的修改要不要记进项目变更日志？
本文范围限于单项目约束调整，需求对象本身的修改归需求变更与版本管理。如果需求修改同时牵动了项目范围、进度或成本约束，可以在项目变更日志中记录约束调整部分，并关联对应的需求变更记录，避免同一件事在两处重复维护、口径不一致。
小项目也需要六类字段全部填吗？
六类信息是追溯的最小集，小项目可以精简字段数量，但标识与提出、前后内容、审批决策、实施关闭这四类不建议省略。原因与依据、影响评估可以合并成一段简短说明，前提是能回答“为什么改、改了什么、谁批的、最后落地没有”。精简的是篇幅，不是追溯链上的环节。
