变更先接住再判断
听到变更时第一反应不要是拒绝。直接说做不了，对方会觉得沟通无门，接下来可能绕过流程找别人提，反而更难管理。正确做法是先问清楚要解决什么问题，再看现有方案能不能覆盖。
很多变更的表面诉求和真实诉求不一样。要求加一个导出按钮，背后可能是他每次都要手工录数据；如果能把数据直接推送到他常用的表格工具，也许比导出更省事。问出目的，方案空间会大很多。
把变更记录进清单，包括提出时间、提出人、原始描述。清单里顺手标注每条需求对应的业务目标，后续判断要不要做会快很多。写下来本身就是一次澄清，很多模糊的诉求写到纸上就露馅了。
评估影响的三件事
第一件是影响范围：涉及哪些页面、哪些接口、哪些已有功能需要回归。范围大的变更往往牵动其他模块，不能只看表面新增的那一点。
第二件是替代方案：有没有成本更低的做法能达到相近效果。先上简化版本，验证有效再补完整，是常见且稳妥的路径。
第三件是排期置换：这次加进来的内容，需要把哪部分往后挪。不置换就直接插入，等于默认接受延期，这个后果要在当下讲清楚，而不是等到交付前才提。如果变更确实值得做，宁可当场调整交付节奏，也不要留到临近验收时再挤时间。
优先级用什么标准谈
谈优先级容易变成各说各话，需要一个简单的共同标准：不做这件事，用户能不能完成核心任务。不能完成的排在前，能绕过去的排在后。
再叠加一个标准：影响多少用户。只在极端情况下出现的问题，即使严重，也可以排在影响多数人的小问题之后。两个标准交叉，优先级排序通常就能谈得下去。
紧急程度要单独看。同一批变更里也要排序，不要因为都写在一张表上就默认全都要做。如果某处影响线上使用或涉及合规要求，无论优先级如何都要优先处理，但要明确告知其他已排期的内容会顺延。涉及核心流程的变更要单独标注，它一旦出问题，影响面通常比新增功能大得多。
回应的方式与记录
回应变更时给出三个选项而不是一个结论：本期做、下期做、本期做简化版。让对方在成本可见的前提下做选择，比直接拒绝或直接答应都更专业。
变更确认后要同步给所有相关人，避免只有提出者知道改动，开发和测试还按旧版本走。口头同步很容易漏人，写在清单或群里并注明影响范围，才算真正同步到位。每次变更都更新需求清单，清单是唯一的依据。
项目收尾时回看变更记录，能看出需求讨论阶段哪里没谈透。常见的是权限规则和异常流程，这两类最容易被跳过，也最容易在开发中途补出来。
