几乎没有项目会因为一次重大变更而失败。项目失败往往是因为三十个小变更：每一个单独看都合理，却没有一个被计入报价。
澄清还是变更
区分二者很重要，而且通常可以明确判断。
澄清是解决已经达成一致的内容中的歧义。规格说明要求用户可以重置密码；客户确认重置链接应在一小时后失效。这本来就会实现，只是确定了一个细节。
变更是增加、删除或修改已经约定的范围。规格说明要求用户通过电子邮件重置密码；客户现在还希望支持短信。这就是新增工作。
灰色地带出现在规格说明没有明确说明的地方。如果规格说明没有写明链接的有效时长，就必须有人做决定，而做出这个决定属于澄清。如果规格说明完全没有提到短信，增加短信支持就是变更。一个实用的判断规则是：如果一名合理的开发者在阅读规格说明后本来就会实现该内容，那么它就是澄清。
为什么小变更的成本会高于其工作量
一个需要两小时编码的变更，很少只花费两小时。它还包括：
- 讨论变更本身并编写相关规格说明。
- 对已完成内容的影响——表单、验证、数据库、报表和导出中都会出现一个新字段。
- 重新测试变更涉及的所有内容。
- 更新文档以及任何已经批准的设计。
- 中断工作所产生的成本。这一成本真实存在，却很少被计入报价。
这就是为什么在设计阶段提出的变更，其成本只是验收测试后提出的同一变更的一小部分。这两个时间点之间的成本倍数很大——人们通常将其描述为数量级差异；即使具体数值存在差异，其方向也没有争议。
尽早向客户解释这一点，会让之后的沟通容易得多，因为客户会理解，之所以要求他们在设计阶段认真思考，是有原因的。
一个足够轻量、能够真正使用的变更流程
对于小型项目，可以分为四个步骤：
- 记录变更请求。用一段话写下，并放在双方都能看到的同一个地方。口头变更是大多数争议的根源。
- 开发者进行估算——评估工作量、成本以及对交付日期的影响。日期影响与成本同样重要，却经常被忽略。
- 客户以书面形式批准或拒绝。拒绝是合理的结果，应当让人能够轻松作出这一决定。
- 将已批准的变更加入进度表和发票；如果交付日期发生变化，也应正式调整。
最常被跳过的是第三步，而跳过这一步正是项目末尾产生争论的原因：工作已经完成，却没有人正式同意为其付费。
处理小变更
为一个十五分钟的调整启动正式变更请求流程，其流程成本会高于实际工作成本，还会让项目显得充满对立。以下是两种可行的方法：
变更额度。在合同中列明一组用于小调整的小时数，并进行跟踪和报告。额度用完后，后续变更再单独报价。这种方式透明，也能减少真正小型请求带来的摩擦。
批量处理。收集小变更，在预先确定的时间点统一报价。这样可以减少中断，同时让客户看到累计成本——这往往能促使他们确定优先级。
客户应当提出异议的变更
并非所有变更请求都来自客户。如果开发者因为已约定的规格说明中某项内容比预期更难实现而提出变更，这通常不属于变更，而是估算错误；估算风险通常由作出估算的一方承担。
例外情况是规格说明确实存在歧义，而客户的理解方式成本更高。这是真正的变更，也正是项目开始阶段投入精力编写规格说明能够收回成本的原因。
保留记录
建立一份双方都能看到的清单，记录每项变更的状态、成本和日期影响。项目结束时，这份清单能够准确解释最终发票为何不同于最初报价；而能够解释差异的项目，很少会以争议告终。
相关 Manboo 服务
- Flutter 应用开发，适用于 iOS 和 Android MVP。
- 业务软件开发，适用于 CRM、预订、库存和工作流系统。
- 管理面板开发，适用于运营仪表板和后台管理。
- AI API 集成，适用于产品准备好实现智能搜索、聊天或自动化功能时。
- 准备规划第一个版本时，申请范围审查和项目估算。