三张清单冻结范围
开工时把纳入的系统、角色与审计事件逐条列成清单，双方签字。之后任何新增都对照清单判断：属于清单内的实现问题，清单外的走变更。没有这份底稿，范围会在每次例会上被悄悄扩大，最后没人记得最初的边界。
变更单要写代价
变更单不只记录需求，还要写清对工期、联调与验收的影响，由业务与技术双方确认。怎么写才有效？让提出方在「延后其他功能」和「追加排期」之间选择，把取舍交回去，口头需求自然减少，会议也更容易收敛。
临时授权必须到期
审计、排查、外包驻场常需要临时高权限。怎么做？设定固定时限、绑定工单号、到期自动回收并通知申请人；没有到期时间的授权最终都会变成永久权限，年度复核时占掉大半工作量，清理成本也很高。
灰度与回滚先预演
权限收紧会直接影响业务操作，上线前应选一个部门灰度，准备好回滚脚本与责任人。边界在于：回滚只恢复授权，不恢复已产生的审计记录，因此每次回滚都要写说明，供后续审计追溯，避免记录断档。
适用与不适用
适合谁
- 多部门同时提需求、范围容易膨胀的项目
- 有外包与临时用工、授权需要时效管理的企业
- 权限收紧会影响一线操作、需要灰度试点的团队
不适合谁
- 范围已写入合同且不再变动的简单项目
典型场景
某工程集团做权限收口，第三周起各分公司陆续要求接入自有系统。项目经理拿出三张清单逐条比对，把其中两个系统排入第二期，并将影响写进变更单；同时给审计人员开通七天临时权限，绑定工单号，到期自动回收，复核时无一遗留。
可执行步骤
- 开工首周产出系统、角色与审计事件三张清单，并由双方签字
- 建立变更单模板，强制填写对工期、联调与验收的具体影响
- 为临时授权设定固定时限，绑定工单号，并配置到期自动提醒
- 选一个部门先行灰度收紧权限，同时准备回滚脚本与责任人
常见坑
- 例会上口头答应新增系统，未走变更单，联调阶段才发现接口不通，整体上线被迫推迟，信任也受损。
- 临时权限不设到期，一年后复核发现大量离职人员授权仍在，整改要逐条确认归属。
- 直接全量收紧权限，一线无法开单，业务投诉后整体回滚，后续再推阻力更大，也更难解释。
自检与验收清单
- 三张清单是否签字并作为范围基准
- 变更单是否强制评估工期与验收影响
- 临时授权是否全部带到期时间与工单号
- 灰度部门与回滚责任人是否已经确定
常见问题
业务催得急，能不能先接进来？
可以接，但要按变更单走并写清代价：要么压缩其他功能，要么顺延上线。跳过变更直接接，等于把风险留给联调阶段，届时接口不通、权限模型不匹配，返工成本会由项目整体承担。
临时权限给多久合适？
按任务实际需要设定，通常以天或周为单位，并与工单绑定。关键不在具体时长，而在到期自动回收、续期需重新审批；只要回收是自动的，时长可以随业务节奏调整，不必一刀切。
范围冻结会不会太僵化？
冻结的是范围基准，不是拒绝变化。有了基准，新增才能被计价和排序；没有基准，所有变化都变成免费加班，最后损害的是交付质量与验收标准，双方都陷入被动，也很难再谈条件。