项目变更日志和变更请求记录常被混用，但两者回答的问题不同：变更请求记录针对单个变更提案，记录提出人、变更内容、理由、影响评估、审批结论与执行状态；项目变更日志是项目层面的变更台账，按时间顺序登记已发生或已批准的变更及其对基准的影响。本文聚焦单项目内的约束调整，说明两者的字段、边界与衔接方式。
要点总览（TL;DR）
- 变更请求记录是单个变更提案的过程档案，回答“这个变更要不要做、做到哪一步”；项目变更日志是项目层面的变更台账，回答“这个项目改过什么、现在基准是什么”。
- 变更请求记录覆盖提案从提出、评估、审批到执行的全过程，被驳回的提案同样留档；变更日志只登记已发生或已批准的变更，按时间顺序排列并关联基准调整结果。
- 一条变更获批并实施后，其编号、日期、类别、影响范围、批准人和基准调整结果应写入变更日志，两份记录由此衔接。
- 问题日志、版本记录和变更控制流程与本文两个概念职责不同，混用会让记录边界不清。
- 常见误用包括只维护日志不保留请求过程、把请求记录当项目台账、日志只记结果不记基准影响。
一句话说清两者的区别
可以直接引用的判断是：变更请求记录是单个变更提案的过程档案，项目变更日志是项目层面的变更台账。前者回答“这个变更要不要做、做到哪一步”，后者回答“这个项目改过什么、现在基准是什么”。
这组关系可以概括为过程记录与结果台账的关系。变更请求记录伴随一个提案从提出、评估、审批到执行的全过程，即使提案被驳回，记录仍然保留；变更日志则只登记已经发生或已经批准的变更，按时间顺序形成项目变更的历史清单。一个变更请求获批并实施后，其关键信息应进入变更日志，两份记录由此衔接。
| 对照维度 | 变更请求记录 | 项目变更日志 |
|---|---|---|
| 记录对象 | 单个变更提案 | 项目范围内已发生或已批准的变更 |
| 回答的问题 | 这个变更要不要做、做到哪一步 | 这个项目改过什么、现在基准是什么 |
| 记录时点 | 从提出到执行的全过程 | 变更获批或发生后按时间登记 |
| 记录性质 | 过程档案 | 结果台账 |
| 是否包含被驳回项 | 包含，驳回结论同样留档 | 不包含未获批准的提案 |
变更请求记录包含什么、不包括什么
变更请求记录的对象是单个变更提案，一份记录对应一个提案。它的作用是让提出理由、影响判断和审批结论有据可查，并为后续执行提供依据。典型字段包括：
- 提出人：谁发起变更，便于回溯责任与沟通对象。
- 变更内容：具体改什么，例如范围、进度、成本或交付物的调整。
- 变更理由：为什么需要改，说明触发变更的业务或技术原因。
- 影响评估：对范围、进度、成本、质量等方面的影响判断。
- 审批结论：批准、驳回或要求补充信息，以及审批人和审批时间。
- 执行状态：待评估、待审批、实施中、已完成等状态标识。
变更请求记录不包括项目全部变更的历史汇总。它是一份份独立的提案档案，不承担按时间排列项目变更清单的职责。若需要查看项目整体改过什么，应查阅变更日志。此外，需求对象的修改及其版本管理属于需求变更与版本管理的范畴，本文不展开。
项目变更日志包含什么、不包括什么
项目变更日志的对象是项目范围内已经发生或已经批准的变更，记录粒度是“一次变更一条登记”，并按时间顺序排列，同时关联基准版本，使读者能看出每次变更对基准造成了什么调整。典型字段包括：
- 变更编号：与变更请求记录对应的唯一标识，便于互相追溯。
- 日期：变更获批或发生的日期，支撑时间顺序排列。
- 类别：范围变更、进度变更、成本变更等分类。
- 影响范围：受影响的模块、阶段或交付物。
- 批准人：对该变更作出批准结论的责任人。
- 基准调整结果：变更后基准如何更新，例如新里程碑日期或调整后的预算口径。
变更日志不包括未提交或未获批准的讨论过程。讨论、评估和驳回意见留在对应的变更请求记录中，日志只呈现已经生效的变更结果。跨研发资产的变更治理与影响分析属于研发变更控制与影响分析的范畴，本文不展开。
一条变更从请求到日志的流转机制
理解两者衔接最直接的方式，是跟踪一条变更从提出到登记的全过程。同一项变更在请求记录中呈现为过程档案，在日志中呈现为一条结果条目，信息随流程推进逐步沉淀。
- 提出变更请求并登记提案信息：提出人填写变更内容、理由和期望调整方向，形成一份变更请求记录，状态为待评估。
- 影响评估与审批形成结论：相关角色评估对范围、进度、成本和质量的影响，审批人给出批准、驳回或补充信息的结论，结论写回请求记录。
- 批准后实施并更新基准：获批的变更进入执行，执行完成后按变更结果更新项目基准，例如调整计划日期或里程碑基线。
- 关键信息登记进变更日志形成台账：将变更编号、日期、类别、影响范围、批准人和基准调整结果写入变更日志，形成项目层面的变更历史。
被驳回的请求留在请求记录中，不进入日志。这样处理既保留了提案被否的原因，避免同类提案反复提出，也保证日志只反映实际生效的变更。在工具承载上，ONES 支持围绕需求、基线、版本和变更建立统一管理对象，支撑变更影响分析、过程状态追踪和交付结果回溯；设置项目计划和里程碑基线后，可对比计划与执行的偏差，并通过版本细节对比追溯变更细节。这些能力可用于承载变更请求的登记、审批状态流转以及变更后基准的对照，具体可用性以实际部署与套餐为准。
容易混淆的相邻概念
变更日志和变更请求记录之外，还有几个概念常在项目文档中出现，混用会导致记录职责不清。下表按“记录什么、不记录什么”的口径作对照。
| 概念 | 主要记录内容 | 与本文两个概念的区别 |
|---|---|---|
| 变更请求记录 | 单个变更提案的提出、评估、审批与执行状态 | 过程档案，覆盖提案全生命周期 |
| 项目变更日志 | 已发生或已批准变更的时间顺序台账及基准影响 | 结果台账，只登记生效变更 |
| 问题日志 | 项目中出现的风险与问题及其处理状态 | 记录风险与问题，不记录变更决策 |
| 版本记录 | 交付物或文档的状态与版本演进 | 描述交付物状态，不承载审批结论 |
| 变更控制流程 | 变更的提出、评估、审批、实施的规则与角色安排 | 是规则与角色安排，日志与请求记录是其产出 |
区分要点在于：问题日志关注“出了什么问题”，版本记录关注“交付物处于什么状态”，变更控制流程关注“按什么规则处理变更”，而变更请求记录和变更日志关注“某个变更提案怎么处理”和“项目改过什么”。四类记录可以并存，但各自承担不同的信息职责。
一个具体例子与常见误解
假设一个项目原计划在 6 月底完成上线，因第三方接口联调延迟，项目经理提出将上线时间顺延两周。以下演示这一变更在两份记录中的不同形态（示例为演示情景）。
在变更请求记录中，这份提案登记为：提出人为项目经理，变更内容为上线日期从 6 月 30 日调整到 7 月 14 日，理由为第三方接口联调延迟，影响评估为测试窗口压缩、需增加一轮回归，审批结论为批准，执行状态为实施中，随后更新为已完成。在项目变更日志中，则登记为一条记录：变更编号与请求对应，日期为批准日，类别为进度变更，影响范围为上线里程碑及测试计划，批准人为项目发起人，基准调整结果为上线里程碑更新为 7 月 14 日。两份记录指向同一件事，但一份保留决策过程，一份呈现基准结果。
实际使用中常见的误解有三类：
- 只维护日志，不保留请求过程。日志只记结果，一旦需要复盘“当时为什么批准”，就缺少理由和影响评估的依据。请求记录应随提案保留，作为审计与改进的材料。
- 把请求记录当项目变更台账使用。请求记录按提案分散存放，无法直接回答项目整体改过什么、当前基准是什么。需要项目层面的视图时，应维护变更日志。
- 日志只记结果，不记基准影响。只写“上线延期两周”而不写基准如何调整，日志就失去了对照基准的作用。每条日志应明确基准调整结果，便于后续对比计划与执行偏差。
把两份记录配合使用，变更请求记录保证每个提案有据可查，变更日志保证项目变更历史完整可追溯，二者共同构成项目变更管理的记录基础。
常见问题
变更请求被驳回后，还需要在变更日志里留一条记录吗？
不需要。变更日志登记的是已发生或已批准的变更，被驳回的提案不进入日志。驳回结论、理由和影响评估保留在对应的变更请求记录中，用于说明提案被否的原因，避免同类提案反复提出。如果后续再次提出类似变更，可以引用原请求记录作为参考。
项目变更日志和变更请求记录可以由不同角色分别维护吗？
可以，但需要约定好交接规则。常见做法是提出人负责填写请求记录中的变更内容与理由，评估与审批角色补充影响评估和审批结论，项目经理或变更管理责任人负责在变更获批实施后把关键信息登记进变更日志。分工的关键是明确“谁在什么时点把哪些字段写入日志”，避免日志漏登或与请求记录对不上。
变更日志里的变更编号和请求记录如何对应？
建议在变更请求创建时即分配唯一编号，并在请求记录和变更日志中使用同一编号。这样从日志中的一条记录可以回溯到完整的提案过程，从请求记录也能确认该提案是否已进入台账。编号规则可按项目或年度编排，保持稳定、不重复即可。
小型项目变更不多，两份记录可以合并成一份吗？
变更数量很少时，可以用一张表同时承载提案信息和登记结果，但建议保留两类字段的区分：提案过程字段（提出人、理由、影响评估、审批结论、执行状态）和台账字段（变更编号、日期、类别、影响范围、批准人、基准调整结果）。合并的是载体，不是职责。项目规模扩大或变更频次上升后，再拆分为独立记录会更清晰。
变更日志需要记录基准调整前后的具体数值吗？
建议记录。只写“上线延期两周”而不写基准如何调整，日志就难以支撑后续的计划与执行偏差对比。较实用的做法是同时写明调整前和调整后的关键基准值，例如原上线日期与新上线日期、原预算口径与调整后口径，使日志本身就能说明基准变化。
