变更本身不是问题
做任何一个系统，需求一定会变。原因很正常：看到第一个版本之后，你才知道自己真正想要什么。
真正让项目失控的，不是变更多，而是变更没记录、没评估、没边界。到交付那天，双方各拿出一个版本的"当初说好的"，谁也说不清。
三步把变更变成动作
第一步：写下来。 变更不要只在微信里说一句"这里改一下"。用一句话写清：现在是什么样、要改成什么样、为什么改。三行字就够，但它决定了这件事有据可查。
第二步：评估影响。 每一项变更都要回答三个问题：改动涉及哪些页面和功能、多花多少时间、会不会影响已经做好的部分。这三问答不出来，就不该开始改。
第三步：确认再动手。 评估结果给对方确认，双方同意再改。这一步是为了避免"我以为不要钱"和"我以为你要加钱"撞在一起。
免费改的边界要提前说
合同或需求确认单里，最好写明这几条：
- 上线前的文案、图片、颜色调整，属于正常打磨，通常不额外计费。
- 新增页面、新增角色、新增业务流程，属于功能变更，按工作量计费。
- 已经验收通过的部分如果推倒重做，按新需求计费。
把这三条提前写清楚，比事后争论"这个算不算改需求"省事得多。
一个常见误区：一次改一堆
很多人习惯攒一批问题一起提。看似省事，实际上让评估变难，也让问题定位变难——一次改十处，出了 bug 不知道是哪一处引起的。
更好的做法是分批：一次改一组相关的问题，改完看一眼，再改下一组。节奏慢一点，返工少很多。
版本要留
每次交付都留一个版本快照，标明日期和改了什么。这不是为了追责，是为了能回到上一个能用的状态。
出问题时最值钱的不是"谁的责任"，是"多久能恢复"。有版本快照，恢复是几分钟的事。
给甲方的一句话
你不需要懂技术，但你需要懂这三件事：我要什么、改了影响什么、改完怎么算完成。把这三件事说清楚，项目就走在正轨上。
需求变更不可怕，可怕的是它只存在于聊天记录里。