改造过程中发现旧系统缺陷或业务提出新需求很常见。问题不在出现变化，而在变化没有重新评估成本、风险和验收影响。范围管理应帮助双方做取舍，而不是阻止合理调整。
区分原范围缺陷与新增目标
对照已确认的业务行为和交付物判断。修复约定功能无法运行的问题，与新增一种业务能力，不应混为一谈。前期未识别的依赖也要保留事实，避免争论仅围绕责任标签。
变更说明保持具体
记录要解决的问题、涉及模块、数据与部署影响，以及替代方案。明确是追加、替换还是延后原任务，让工期和费用变化能够被解释。
验收标准随范围同步调整
新增功能可能改变回滚、性能或权限验证，需要补充相应验收。不能只增加开发任务，却继续沿用无法覆盖新行为的旧清单。
定期确认剩余工作
用共同维护的任务与风险清单检查已完成、待确认和新增内容。对无法估算的事项先安排有限调查，再给实施承诺，减少凭感觉报周期。
常见问题：所有小修改都要复杂审批吗？
不需要，可以约定轻量处理范围；但影响业务语义、数据或生产责任的变化应明确记录与确认。
将评估落实到你的系统
准备推进现有 .NET 系统改造时，可以先约定一个范围明确的试点。通过单体系统渐进式改造服务梳理边界、兼容与迁移步骤，再按验证结果决定下一阶段。