如果中途需求变化，是怎么计费和管控的？

小调整不另算钱，大改按工作量评估。我们的惯例是把每周需求变更过一次：单次工作量在 2 个工作日以内的优化默认包含在迭代里，不单独计费；超过这个量级的会先做工时评估、客户书面确认，再开发。这套机制让小修小补能快速进去，又不至于把项目拖成无底洞。

具体的管控流程是这样：

• 每周一次的需求评审会，把客户那一周提的所有变更整理成清单
• PM 给每条变更打一个工作量标签（小时级 / 1-2 天 / 3+ 天）
• 小时级和 2 天内的归入"日常优化"，不影响排期、不另收费
• 超过 2 天的需求拆成"需求变更单"，写清楚改动范围、新增工时、对原排期的影响，发给客户对接人确认
• 客户书面（邮件或协作平台留痕）确认后，才会进入开发，并按当时合同约定的人天单价计入变更费用

之所以要这么明确，是因为定制项目最常见的纠纷不是质量问题，而是"我以为这个本来就应该做"。提前把"哪些算变更、变更怎么算钱"说清楚，比每次到节点了再扯皮要好得多。

我们也遇到过一些情况：客户初期 PRD 没考虑周到，到中段才意识到某个核心流程必须调整。这种时候我们一般不会简单按工时收费完事，而是先评估这次调整的根因——如果是滚水科技在前期需求澄清时没问到位，我们承担工时；如果是客户业务方向变化，按变更计算；如果两边都有责任，对半。这种处理方式我们和大多数长期合作客户都形成了默契。

总之，"变更"不是个坏词，软件就是在变更里成熟的。关键是有清晰的口径、留下记录、双方都认账，整个项目就跑得动。