先对照已确认的范围
开发过程中提出的新意见，需要先与功能清单、原型和验收要求比较。已经约定却没有正确实现的行为通常属于需要修复的问题；原范围没有包含的新业务目标则需要进一步评估。仅凭用户说改一下或开发说做不了，都无法形成有效结论。把具体触发条件、当前结果和预期结果写清，双方更容易判断差异。
变更影响不只在一个页面
增加一个字段可能同时影响数据结构、接口、权限、导入导出与历史数据。调整审批规则也可能改变在途单据的处理方式。因此评估时应列出受影响部分、实现方案和验证工作，不只估算界面修改时间。涉及外部接口或资料准备的依赖，也要明确负责人和可用时间，避免开发计划建立在尚未满足的条件上。
确认后再调整计划
变更记录可以包含业务理由、范围、优先级、周期与费用影响，由双方确认后纳入实施。紧急问题需要快速处理时，也应保留必要记录，并补齐后续验收。暂不纳入当前版本的需求进入待评估清单，明确它不是已经承诺的交付内容。这样既能接受合理变化，也能保持当前版本的边界清楚。
验收使用更新后的依据
变更完成后，同步修改相关原型、说明和测试场景，避免产品经理、开发和客户各自使用不同版本的资料。对于被替换的旧方案，保留历史记录但清楚标明不再适用。复盘时可以查看变更原因与影响，发现前期容易遗漏的业务规则。需求管理的目的，是让每次调整有依据、可讨论，也能落到明确交付。
方案落地前需要确认
本文以“定制开发需求变更”为主题讨论功能设计，属于方案指南，不代表某个客户项目的实际交付承诺。具体实施前，应由业务负责人确认适用规则、使用角色、现有系统接口和验收方式，再通过原型验证关键操作。对于暂时不能确定的条件，保留待确认清单，在范围明确后评估开发周期与费用，避免将示例直接套用于不同企业。