项目变更里，审批责任和评审责任经常被混在一起说。简单区分：审批责任是对变更能否生效作出决定并承担决策后果，评审责任是对变更的必要性、影响和可行性给出专业判断和证据。本文讨论范围限定在单项目约束调整，如范围、进度、成本、资源的调整；需求对象修改和跨研发资产的变更治理不在本文重点。
要点总览（TL;DR）
- 审批责任是对变更能否生效作出决定并承担决策后果，核心动作是批准、否决或附条件放行；评审责任是对必要性、影响和可行性给出专业判断与证据，核心动作是分析、质询和出具意见。
- 事项边界上，变更是否放行、优先级调整、资源与基线调整归审批；影响范围分析、可行性判断、风险与依赖识别归评审。
- 流程中两类责任按受理分级、评审、审批、生效回写的顺序接力，评审意见与审批结论不一致时，审批人应书面说明理由，重大风险可作为放行条件记录。
- 评审通过不等于变更生效，签字也不免除评审人对判断质量的责任；责任按环节分布，不因签字顺序而转移。
- 本文范围限定在单项目约束调整，需求对象修改与跨研发资产变更治理不在本文展开。
一句话说清：审批责任与评审责任各管什么
审批责任，指某个角色对一项变更是否放行、以什么条件放行作出最终决定，并对这个决定带来的后果负责。它的核心动作是批准、否决或附条件放行，产出物是生效性的审批结论。
评审责任，指某个角色从专业角度分析变更的必要性、影响范围和可行性，给出判断与证据。它的核心动作是分析、质询和出具意见，产出物是评审意见，包括影响分析、风险提示、可行性结论和支撑材料。
两者的衔接关系可以概括为：评审输出意见，审批据此决定。评审让审批人拿到做判断所需的信息，审批让变更获得效力。缺少评审，审批容易变成拍脑袋；缺少审批，评审意见只是建议，变更无法正式生效。
需要强调的是，这两种责任可以由不同角色承担，也可以由同一人兼任，但职责边界应当分开记录。同一个人既评审又审批时，记录上仍要区分“我作为评审人给出的意见”和“我作为审批人作出的决定”，否则事后追溯时无法判断哪一步出了问题。
| 对比项 | 审批责任 | 评审责任 |
|---|---|---|
| 回答的问题 | 这个变更能不能生效 | 这个变更该不该做、能不能做、影响多大 |
| 核心动作 | 批准、否决、附条件放行 | 分析、质询、出具意见 |
| 产出物 | 审批结论（生效性） | 评审意见（建议性） |
| 后果承担 | 对决策后果负责 | 对判断质量和证据充分性负责 |
边界划分：哪些事属于审批，哪些事属于评审
把两类责任落到具体事项上，边界会清楚很多。审批责任覆盖的是“决定权”：变更是否放行、优先级如何调整、资源和基线是否随之调整，这些最终决定由审批人作出。评审责任覆盖的是“判断权”：影响范围分析、技术或业务可行性判断、风险与依赖识别，这些专业结论由评审人给出。
| 事项 | 归属 | 说明 |
|---|---|---|
| 变更是否放行 | 审批 | 最终决定，具有生效效力 |
| 优先级调整 | 审批 | 涉及资源排序，需决策授权 |
| 资源与基线调整 | 审批 | 影响项目约束，需正式决定 |
| 影响范围分析 | 评审 | 专业判断，提供证据 |
| 技术或业务可行性 | 评审 | 由具备相应专业能力的人给出 |
| 风险与依赖识别 | 评审 | 输出风险清单和依赖关系 |
边界模糊的情形主要有两类。一类是评审人同时是审批人，此时两种责任叠加在一个人身上，容易出现“评审意见写得含糊、审批直接通过”的情况，解决办法是在记录上强制区分意见与决定。另一类是审批人跳过评审直接拍板，这会让审批失去信息基础，决策后果仍然由审批人承担，但组织应明确这种做法的适用条件，例如紧急变更且影响可控时，事后补评审。
本文范围限定在单项目约束调整。需求对象本身的修改方法归需求变更与版本管理，跨研发资产的变更治理与影响分析归研发变更控制与影响分析，这两类主题不在本文展开。
机制解析：一个变更从提出到生效，两类责任如何接力
按流程顺序看，两类责任在变更生命周期的不同节点触发，通过明确的输入输出完成交接。
第一步，受理与分级。变更提出后，先由受理角色判断变更类型和影响等级，据此确定需要哪些评审角色参与。分级的作用是匹配评审投入：影响小的变更可以简化评审，影响基线或关键路径的变更需要完整评审。这一步的产出是评审角色清单和评审要求。
第二步，评审。评审人围绕必要性、影响范围、可行性和风险出具意见。一份可用的评审意见应包含：变更要解决什么问题、影响哪些工作项和交付物、有哪些替代方案、主要风险及应对建议、评审人明确的结论倾向。意见需要留痕，记录评审人、评审时间和意见内容，便于后续追溯。
第三步，审批。审批人依据变更单、评审意见和相关数据作出决定。决策结果应记录为批准、否决或附条件批准，附条件批准要写清条件内容和验证方式。审批人如果不同意评审结论，应在记录中说明理由，而不是简单签字了事。
第四步，生效与回写。审批通过后，变更才正式生效。此时由执行角色更新基线、计划和范围，并通知相关方。回写动作要有责任人，更新后的基线版本要可追溯，避免出现“审批通过了但计划没改”的脱节。
评审意见与审批结论不一致时，处理路径通常是：审批人书面说明不采纳评审意见的理由，必要时升级到更高决策层级复核；如果评审意见指出重大风险而审批仍决定放行，风险应对措施应作为放行条件一并记录。这条路径的意义在于让分歧可见，而不是让分歧消失在签字流程里。
在责任留痕和交接这个环节，工具可以承担记录和追溯的工作。ONES 瀑布项目管理解决方案支持设置项目计划和里程碑基线，实时对比计划与执行的偏差，并通过对比版本细节追溯变更细节，帮助团队掌握项目进展和变更情况（适用于采用瀑布项目管理方式的场景，具体功能以实际部署与套餐为准）。这类能力解决的是“变更前后发生了什么、谁在什么时候记录了什么”的问题，审批与评审的职责划分仍需组织自己定义。
容易混淆的相邻概念：评审意见、审批决定与变更执行
实际工作中，有几个概念常与审批、评审混用，区分它们有助于把责任落到正确的人身上。
评审意见与审批决定。评审意见是建议性判断，回答“从专业角度看这个变更怎么样”；审批决定是生效性决定，回答“这个变更是否放行”。评审意见写得好，不等于变更自动生效；审批决定作出后，评审意见仍然是决策依据的一部分，供事后复盘。
审批责任与变更执行责任。审批责任是决定放行，执行责任是落实变更内容。审批人批准了里程碑调整，不等于审批人负责把计划改完；执行人按批准的内容更新计划、协调资源，对执行质量负责。两类责任分开，出问题时才能判断是决策失误还是执行偏差。
变更评审与变更告知。评审是专业判断，需要评审人投入分析并给出结论；告知是信息同步，接收方了解变更内容即可，不承担判断责任。把告知当成评审，会让评审流于形式；把评审当成告知，会让专业意见缺位。
责任记录与责任承担。留痕记录的是“谁在什么时候说了什么、决定了什么”，它是追溯的依据，本身不等于免责。评审人记录了意见，仍要对判断质量负责；审批人记录了决定，仍要对决策后果负责。记录的价值在于让责任可查，而不是让责任消失。
具体例子与常见误解
以下为演示场景，用于说明两类责任的分工，不代表真实项目案例。
某项目原计划在月底完成系统集成，因外部供应商接口交付推迟两周，项目经理提出调整里程碑的变更：集成完成时间顺延两周，验收时间相应后移，测试窗口压缩三天。
评审环节，技术负责人分析接口依赖和测试窗口压缩的影响，指出压缩三天可能导致回归测试覆盖不足，建议保留关键路径上的冒烟测试并增加一轮专项测试；采购接口人确认供应商新的交付承诺。评审意见记录为：变更必要，风险集中在测试覆盖，建议附条件放行。
审批环节，项目负责人依据评审意见作出附条件批准：同意顺延，条件是增加专项测试并每周同步供应商进度。审批结论与条件一并记录。随后执行角色更新基线计划和里程碑，通知相关方，变更生效。
这个例子中，技术负责人和采购接口人承担评审责任，项目负责人承担审批责任，项目经理承担执行与协调责任。三方各自对自己的环节负责，记录上可以清楚区分。
常见误解有三条。其一，评审通过就等于变更生效——评审只是给出意见，生效需要审批决定。其二，审批人签字后评审人不再对判断质量负责——评审人对自己出具的意见负责，意见失实或分析遗漏仍要追溯。其三，责任只落在最后一个签字人身上——审批人对决策负责，评审人对判断负责，执行人对落实负责，责任按环节分布，不因签字顺序而转移。
常见问题
评审人同时是审批人时，责任怎么记录才清楚？
两种责任可以由同一人承担，但记录上要分开。建议在变更单上分别保留评审意见和审批结论两个字段：评审意见写清分析依据、影响判断和结论倾向，审批结论写清批准、否决或附条件批准及理由。同一个人先后填写时，审批结论里应体现对评审意见的采纳情况，不采纳的要说明原因。这样事后追溯能判断问题出在判断环节还是决策环节。
紧急变更来不及完整评审，审批人可以直接决定吗？
可以设置紧急通道，但需要明确适用条件，例如影响范围可控、时间窗口不允许等待完整评审。此时审批人仍对决策后果负责，组织应要求事后补做评审，并把补评审的时限和责任人写进流程。紧急通道使用越频繁，越说明常规评审的分级机制需要调整，例如为低影响变更设置简化评审，避免所有变更都走完整流程。
审批人不同意评审结论时，应该怎么处理？
审批人应在记录中书面说明不采纳评审意见的理由，而不是简单签字通过。如果评审意见指出重大风险而审批仍决定放行，风险应对措施应作为放行条件一并记录，并明确验证方式。分歧较大或涉及关键基线时，可升级到更高决策层级复核。让分歧在记录中可见，比让它在签字流程里消失更有利于后续复盘。
变更执行出了问题，是审批人还是评审人承担责任？
按环节判断。审批人对决策负责，评审人对判断质量和证据充分性负责，执行人对落实变更内容负责。如果执行偏差源于审批时遗漏了关键约束，追溯指向审批环节；如果源于评审意见分析失实，追溯指向评审环节；如果批准的内容正确但计划没改到位，追溯指向执行环节。责任记录的价值在于让每个环节可查，而不是把责任集中到最后一个签字人身上。
用工具承载变更流程时，重点看哪些记录能力？
重点看三件事：评审意见与审批结论能否在同一变更记录上分别留痕，变更前后的基线能否对比追溯，审批通过后的计划更新是否有责任人和版本记录。以 ONES 瀑布项目管理解决方案为例，其支持设置项目计划和里程碑基线，实时对比计划与执行的偏差，并通过对比版本细节追溯变更细节（适用于采用瀑布项目管理方式的场景，具体功能以实际部署与套餐为准）。审批与评审的职责划分仍需组织自己定义，工具承担的是记录与追溯。
