如果中途需求变化，是怎么计费和管控的？
结论：先分类再计费。未达到原验收标准属于缺陷；原范围的必要澄清按合同处理；新增业务或平台、客户方向变化通常另行计费。滚水科技提交影响与报价，客户书面选择替换范围、顺延、增费或暂缓后才开发。
“2 个工作日以内默认免费”不适合作为公开通则。两天的小改可能持续发生，累计足以改变项目；一个看似半天的字段也可能影响迁移、接口和报表。是否收费应看它是否属于原合同、为何发生以及合同是否包含维护或变更额度，而不是只看单项估算天数。
常见变化可按下表处理：
| 分类 | 判断依据 | 常见计费 | 计划处理 |
|---|---|---|---|
| 缺陷 | 实际行为不符合已确认需求或验收标准 | 通常由滚水科技修复，不作为新增收费 | 按严重级别进入修复计划 |
| 澄清/遗漏 | 功能在范围内，但文档有歧义或双方均未定义细节 | 依合同、责任与影响协商 | 先补充规则和验收再开发 |
| 客户新增/方向变化 | 新角色、新流程、新平台或已确认规则改变 | 按工作量/阶段价另计，或替换等量范围 | 出变更单，更新日期与里程碑 |
| 第三方/政策变化 | 平台 API、审核、法规或供应商能力变更 | 按合同风险分配，通常需重新评估 | 先确认必须性、截止日和替代路线 |
| 技术必要修复 | 为安全、兼容或生产稳定必须升级 | 质保缺陷、维保或专项升级分别处理 | 明确风险等级和停机窗口 |
提出变更时先记录业务原因、目标用户、当前与期望行为、验收场景、截止时间和不做后果。滚水科技补充受影响的页面、后端、数据、权限、接口、测试、迁移、上架和文档。估算给出工作量区间、假设、风险和对原计划的影响，而不只写“开发 3 天”；设计、测试、发布和项目管理也是交付成本。
客户可作四种明确选择：用新需求替换尚未开始的等量原范围；保持原范围并增加预算和时间；放入后续迭代；取消该想法。若变更涉及已经完成的数据模型或外部合同，替换功能也未必等量，需按实际影响评估。任何选择都在协作平台、邮件或签署变更单中留痕，指定有权确认的人，群聊中的随口想法不直接进入开发。
计费模式也要匹配不确定性。固定总价适合范围稳定，变更单单独计价；预留变更预算适合预计会有少量变化，但要记录额度消耗；按时间和材料适合探索性较强的长期团队，并设置预算上限、周期目标和工时透明。三种模式没有绝对优劣，不能既要求固定总价又让范围无限浮动。
责任归因不应靠事后“对半承担”的口头默契。若需求文档明确而实现错误，就是缺陷；若滚水科技在约定的需求职责中遗漏明显异常路径，应按合同承担；若客户负责人确认后改变业务规则，属于变更；若双方资料都不足，则依据合同中的假设、确认记录和风险分配协商。无法达成一致时，先暂停受争议部分，继续不受影响的工作。
变更批准后要同步更新需求/原型、接口、测试、预算、里程碑和发布说明。旧版规则如果已经产生数据，还要说明迁移、历史口径和回滚；不能只改当前页面。每周变更评审可以作为节奏，但紧急安全或生产问题另走应急通道，普通新想法不应伪装成 P0 插队。
项目可监控变更数量、累计新增工时、来自哪些原因、返工比例、对关键路径的延误和未确认变更老化时间。数据用于改进需求和决策，不用于阻止合理变化。若变化率持续很高，说明应缩短承诺周期、回到原型验证或改用按工时模式，而不是不断追加小变更单。