项目里出现未经批准的变更，往往不是单一环节出错：有人绕开流程直接安排，有人觉得改动太小不必评估，也有人不清楚该找谁批准，或在进度压力下先做后补。本文按“症状界定—原因假设—证据验证—分类处置—验证恢复”的顺序，帮助读者判断一次未批准变更属于哪类原因，并给出对应的处置动作与验证指标。
要点总览（TL;DR）
- 未经批准的项目变更常见于四类来源：流程绕行、评估缺位、审批责任与权限不清、进度或客户压力下先做后补。
- 诊断时先按发起、评估、审批、执行四个环节收集变更申请记录、审批痕迹、基线版本对比和沟通记录，证据不足的原因保留为待验证假设。
- 判断流程缺失还是个人绕行，看同类变更在多个项目中的普遍情况：普遍找不到入口或审批人，倾向流程缺失；流程存在而个别变更跳过，倾向个人绕行。
- 处置按原因对应：补建申请入口、建立影响评估最小字段、公示审批人与批准标准、设置补批时限与停止点；已执行变更先评估影响再决定回退或冻结。
- 用未批准变更数量、补批率、基线偏差三项指标验证恢复，并通过定期基线对比、变更复盘和审批责任公示防止复发。
未经批准的变更通常表现为什么样
未经批准的变更在早期往往没有正式单据，而是以“已经这样做了”的形式出现在项目记录里。识别症状是诊断的第一步，因为不同表现指向不同的发生环节。常见的表现有三类：范围悄悄扩大，例如交付清单里多出未在批准范围内的功能或交付物；计划日期被口头调整，例如里程碑时间在会议或聊天中被改动，但项目计划文件没有同步；预算被先行支出，例如采购或人力投入已经发生，变更申请尚未提交。
这些表现的共同点是“执行先于批准”。判断时可以对照三个位置：当前执行内容与最近一次批准的基线是否一致，计划日期与已批准版本是否一致，实际支出与已批准预算是否一致。任何一处出现偏差且找不到对应的批准记录，就可以初步归入未批准变更。
需要界定本文的讨论范围。本文聚焦单项目内范围、计划、预算三类变更的申请与批准环节，关注“该批未批”或“未批先做”的问题。需求对象本身的修改流程、跨研发资产的变更治理属于另外的管理主题，涉及这些内容时应按相应流程处理，本文不展开。把边界划清，原因排查才不会失焦：先确认问题出在单项目的批准环节，再往下追原因。
原因假设：四类常见来源
在拿到证据之前，对原因的判断只能作为假设。把假设列全，再用线索逐项验证，可以避免凭印象下结论。实践中较常见的来源有四类，每类都对应可观察的线索。
| 原因假设 | 典型情形 | 可观察线索 |
|---|---|---|
| 流程绕行 | 口头指令、即时通讯里拍板、用会议纪要替代正式申请 | 执行记录存在但无变更申请单；决策散落在聊天或纪要中；当事人认为“已经说过了” |
| 评估缺位 | 变更被视为小事，未做影响评估即执行 | 变更无范围、工期、成本、依赖的分析；执行后才发现连锁影响；返工集中在变更之后 |
| 责任与权限不清 | 执行者不知道审批人、审批链或批准标准 | 申请被反复转交；同一类变更在不同项目由不同角色批准；有人以“不知道找谁”为由跳过 |
| 压力驱动 | 进度、客户或上级压力下先做后补 | 补批申请集中在里程碑前；变更执行时间明显早于申请时间；补批理由多为“客户要求”“节点紧” |
四类假设可能同时存在。例如一个项目既缺少明确的审批人，又在节点前承受压力，绕行就更容易发生。排查时不必急于归为单一原因，可以先记录每类线索的出现频次，再判断哪一类是主要来源。线索只是指向，不能直接当作结论：聊天里出现“先做吧”不等于流程一定被绕行，还需要核对是否存在随后补交的正式申请。
用证据排除与确认原因
确认原因需要把假设落到证据上。可用的证据主要有四类：变更申请记录，用于判断是否发起过正式申请；审批痕迹，用于判断是否经过批准以及由谁批准；基线版本对比，用于判断执行内容与批准范围是否一致；会议纪要与沟通记录，用于还原决策过程。四类证据互相印证，才能把假设转为结论。
排查按变更发生的环节推进，顺序是发起、评估、审批、执行。先看发起环节：是否存在申请记录，申请内容是否覆盖实际执行的改动。再看评估环节：申请或决策材料中是否有范围、工期、成本、依赖的分析。然后看审批环节：审批人是否明确、是否在权限范围内、批准标准是否被引用。最后看执行环节：执行时间与批准时间的先后关系，执行内容与批准内容是否一致。
判断“流程缺失”还是“个人绕行”，关键看同类变更的普遍情况。如果同一类变更在多个项目中都找不到申请入口或审批人，倾向于流程缺失；如果流程存在、其他人按流程执行，只有个别变更跳过，倾向于个人绕行。两者的处置方向不同：前者补流程，后者纠行为并明确后果。
| 排查环节 | 要回答的问题 | 主要证据 | 可能的结论 |
|---|---|---|---|
| 发起 | 有没有正式申请，申请是否覆盖实际改动 | 变更申请记录、执行清单 | 流程绕行，或申请入口不可用 |
| 评估 | 是否分析过范围、工期、成本、依赖 | 申请材料、评审记录 | 评估缺位，或评估标准未定义 |
| 审批 | 审批人是否明确，是否按标准批准 | 审批痕迹、权限说明 | 责任与权限不清 |
| 执行 | 执行与批准的时间、内容是否一致 | 基线版本对比、时间记录 | 压力驱动下的先做后补 |
证据不足时，把该项保留为待验证假设，在记录中注明缺少哪类证据、计划如何补充，不要写成确定结论。原因诊断的价值在于后续处置是否对症，过早定性能让处置动作偏离真实问题。
按原因采取处置动作
处置动作应与已确认的原因对应，并交代适用条件和停止点。以下四组动作可以单独使用，也可以组合使用。
针对流程绕行：补建统一的变更申请入口，明确哪些变更必须走申请，例如影响已批准范围、里程碑日期或预算额度的变更一律提交申请。同时规定口头指令和即时通讯决策不能替代申请，会议纪要可以作为申请附件但不能单独作为批准依据。适用条件是组织内已有一致的变更分类；如果分类本身混乱，先统一分类再建入口。
针对评估缺位：建立影响评估的最小字段，至少包括变更涉及的范围、对工期的影响、成本变化、受影响的依赖项。评估可以由提出人完成初稿，由项目负责人确认。完成标志是评估字段齐全且被审批人引用；缺少任一关键字段的申请退回补充，不进入审批。
针对责任与权限不清：明确每类变更的审批人、审批链和批准标准，并以书面形式公示。审批链要说明升级条件，例如超出某一额度或影响关键里程碑时上移到更高层级。批准标准要可判断，例如“影响里程碑日期超过约定天数需项目负责人批准”，避免只写“重大变更需审批”。
针对压力驱动：设置先做后补的补批时限与停止点。可以允许在紧急情况下先执行，但须在约定时限内补齐申请与评估，例如两个工作日内提交。停止点用于控制风险：变更影响未评估前，冻结与之关联的后续调整；补批时限到期仍未提交的，暂停相关工作的继续投入，由项目负责人决定回退或升级处理。
涉及已经执行的变更时，先评估影响再决定回退或保留。回退适用于改动尚未扩散、回退成本可控的情况；如果改动已进入下游环节，优先冻结后续关联调整、补齐评估与批准，再决定是否保留。无论哪种选择，都要把处理结论写入变更记录，作为后续基线更新的依据。
在变更申请、影响评估、审批和基线记录需要统一承载时，可以借助项目管理系统把这条链路固定下来。ONES 瀑布项目管理方案支持设置项目计划和里程碑基线，实时对比计划与执行的偏差，并通过对比版本细节追溯变更细节；其多层级管理能力可以把项目到任务的进度反馈与监控串起来。对于需求链条较长的研发场景，ONES ALM 方案围绕需求、基线、版本和变更建立统一管理对象，需求变化时可沿关联关系分析受影响的任务、测试和交付内容，并保留过程追踪和审计依据。这些能力的具体范围以实际开通的模块为准。
验证恢复与防止复发
处置是否生效，要用指标验证，而不是凭感觉判断。建议跟踪三项指标：未批准变更数量，按周期统计新发现的未批准变更；补批率，即先执行后补交申请的比例；基线偏差，即执行内容与最近批准基线的差异程度。三项指标同时下降，说明申请与批准环节在恢复；只有补批率下降而未批准变更数量上升，可能只是把问题藏得更深，需要继续排查。
基线更新与批准记录的一致性检查是验证的关键动作。每次批准变更后，确认基线版本已同步更新，批准记录能对应到具体的基线版本；抽查若干已执行变更，核对执行内容、批准内容和基线记录三者是否一致。发现不一致时，回到证据排查环节重新判断原因，而不是直接补记录了事。
复发预防依靠三项常规安排。定期基线对比，按固定周期把执行情况与批准基线比对，尽早发现偏差；变更复盘，对未批准变更逐项回顾发生环节和原因，形成可复用的判断；审批责任公示，把审批人、审批链和批准标准保持在项目成员可见的位置，减少“不知道找谁”的情况。
验证周期可以与项目节奏对齐，例如在每个里程碑评审时检查一次指标，在阶段结束时做一次完整复盘。责任角色上，项目负责人对指标结果负责，变更提出人负责补齐申请与评估，审批人负责按标准批准并确认基线更新。三项职责分开，验证才有可追溯的依据。
常见问题
变更已经执行完了才发现没走审批，应该先补批还是先回退？
先评估影响，再决定补批还是回退，避免直接补记录掩盖问题。评估内容包括改动是否已扩散到下游环节、回退成本是否可控、对已批准范围和里程碑的影响程度。
改动尚未扩散、回退成本可控时，可以回退到最近批准的基线；改动已进入下游环节时，优先冻结与之关联的后续调整，补齐影响评估和批准，再决定是否保留。无论哪种处理，都要把结论写入变更记录，并同步更新基线版本，使批准记录与基线一致。
口头指令和会议纪要能不能作为变更批准的依据？
口头指令和即时通讯里的拍板不能替代正式申请与批准。会议纪要可以作为变更申请的附件，用于还原决策背景，但不宜单独作为批准依据，否则审批痕迹与批准标准都无从核对。
可行的做法是明确哪些变更必须提交申请，例如影响已批准范围、里程碑日期或预算额度的变更；同时规定纪要、聊天记录在申请中的角色，要求补交正式申请并由有权限的审批人按标准批准。
紧急情况下允许先做后补，补批时限怎么定才合理？
补批时限要结合变更影响面和项目节奏确定，常见做法是约定在一到两个工作日内提交申请与影响评估。时限本身不是重点，配套的停止点才是控制风险的关键。
可以规定：变更影响未评估前，冻结与之关联的后续调整；补批时限到期仍未提交的，暂停相关工作继续投入，由项目负责人决定回退或升级处理。时限和停止点应书面公示，并在变更记录中留下执行时间与申请时间的对照，便于后续统计补批率。
同一类变更在不同项目由不同角色批准，算不算权限不清？
算。同类变更的审批人、审批链和批准标准不一致，会让执行者难以判断该找谁批，也容易成为绕行的理由。判断时可以抽查若干已批准变更，核对审批人是否在权限范围内、批准依据是否引用了统一标准。
处置方式是按变更类型明确审批人和审批链，并写明升级条件，例如超出某一额度或影响关键里程碑时上移到更高层级。批准标准要可判断，避免只写“重大变更需审批”这类无法执行的表述。
补批率下降了，是不是说明未批准变更问题已经解决？
不一定。补批率下降可能来自申请与批准环节恢复，也可能来自变更被藏得更深、根本没有进入记录。需要结合未批准变更数量和基线偏差一起看：三项指标同时下降，才说明问题在缓解。
验证时还要做一致性检查，抽查已执行变更，核对执行内容、批准内容和基线记录三者是否一致。发现不一致时回到证据排查环节重新判断原因，而不是直接补记录。验证周期可以与里程碑评审对齐，由项目负责人对指标结果负责。
