客户提出变更时，先回到已经约定的范围

找到共同参考版本

估算工作量之前，收集批准过的任务说明、交付物，以及后来接受的澄清。确认团队和客户分别使用哪个版本，先解决差异。基于不同文件评估新请求，会产生两个看似合理的答案。

Atlassian 将项目基线说明为比较计划与变化的参考。小型服务可以采用注明日期、范围、负责人和待办的文件。让文件容易查阅，有助于围绕共同依据讨论。

用变更前后描述请求

虚构案例中，工作室约定根据已批准文字制作四页目录，客户后来要求按市场再做一个版本。应记录究竟是翻译、不同信息审核，还是另一组商品选择。初始消息虽然简短，不同解释对应的工作却不同。

分别写一句变更前与变更后：“一个四页版本”和“两个版本，差异仍待定义”，再补充客户说明的原因。为满足既有约定而作的修正，与扩大结果的请求需要区分，先核对案例再分类。

检查对整体工作的影响

• 输入：需要哪些新资料或材料。
• 工作：哪些保留、调整或重做。
• 依赖：哪些审核、供应商或交付等待变更。
• 条件：哪些日期、资源或约定需要重新考虑。
• 决策：谁能接受新版本，此前还缺什么。

Atlassian 的变更控制说明区分请求、评估与批准。我们的轻量记录让这些问题可见。缺少重要信息时，应把估算保留为暂定，并指出什么条件会使它改变。

提供能够帮助选择的回应

虚构回复可以是：“我们可以先保留已约定版本，再做第二版；也可以等各市场文字齐备后一起审核。确认新日程前，需要先决定采用哪条路径。”说明每种方案保留与改变什么。

通过约定渠道书面保存决定与条件。收到请求、提出备选方案，与接受变更是不同状态。本站提案跟进指南帮助带着背景重新讨论未决事项。

更新团队使用的参考文件

达成一致后，记录新版本、替代什么、哪些仍有效。通知制作、审核或等待交付的人。检查旧文件是否仍在流传，以及现行文件放在哪里。只要能辨认差异，说明可以简短。

本站任务交接记录可以把新输入与标准传递给他人。如果交付方式变化，也要更新审核样本和批准时点。仅在自己电脑上修正指令，还需要把它传给实际使用的人。

用具体观察结束变更

结束时比较原先预期与实际需要：缺失材料、额外审核，或之前没发现的依赖。把观察与结束记录保存在一起。如果多次请求暴露同一疑问，应澄清未来提案范围，或准备专门选项。

本站服务验证指南帮助检查交付假设。变更记录提供执行过程中的证据，其价值是保留决定并从具体案例学习，不把一次经历推广到所有客户。