夜雨聆风客户一句“顺手改一下”，可能让你的项目多做半个月
如果说拖款让自由程序员心累，那么无边界地改需求，就是让项目失控的第一步。
很多项目刚开始时其实并不复杂。
客户描述得很清楚：
做一个官网 做一个后台系统 做一个小程序
功能不多，周期不急，看起来一切都很顺利。
但真正开始开发后，你会发现事情慢慢变了。
“首页能不能再加一个活动专区？”
“后台能不能顺便加个 Excel 导出？”
“用户列表能不能增加筛选？”
“短信通知能不能接一下？”
“会员等级能不能也做一下？”
每一次，客户都说得很轻松：
“这个应该不难吧？”
“顺手加一下就行。”
“这个需求很小，不会影响太多时间。”
“你先帮我做了，后面一起算。”
刚开始，你不好意思拒绝。
你觉得客户关系不错，多做一点也没什么。
结果加着加着：
原本 20 天完成的项目，拖成了 40 天； 原本 2 万元的项目，做出了 4 万元的工作量； 更糟糕的是，客户并不觉得这是新增需求。
他只会觉得：
“为什么你做得这么慢？”
后来我总结出一句话：
自由程序员最怕的不是客户改需求，而是客户把新增需求包装成“顺手改一下”。
一、为什么“顺手改一下”最危险？
因为它听起来不像需求。
如果客户明确告诉你：
“我要新增一个模块，请重新报价。”
这件事反而很好处理。
真正危险的是那些看起来很小的改动：
列表页增加几个筛选条件 表单增加几个字段 后台增加一个导出按钮 页面增加一个弹窗 支付流程增加一种优惠规则 订单状态增加几个分支 用户角色增加一种权限
单独看，每个都不大。
但项目失控，从来不是因为一个巨大的需求突然砸下来。
而是因为几十个“小需求”不断堆积。
更麻烦的是：
小改动往往会牵动整个系统。
例如客户说：
“加个字段就行。”
但实际开发可能涉及：
数据库结构调整 后端接口修改 表单校验 列表展示 搜索筛选 导入导出 权限控制 历史数据兼容
客户看到的是一个输入框。
你处理的是一整条业务链路。
这也是程序员与客户最大的认知差异：
客户说的是“加一下”。
你做的是“改一套逻辑”。
二、修改和新增，一定要分清楚
很多自由程序员之所以被需求拖垮，是因为没有区分两件事：
修改（Modification） 新增（Addition）
什么是修改？
在已确认范围内进行优化和调整。
例如：
文案修改 颜色微调 间距优化 字段名称修改 已有流程 Bug 修复
什么是新增？
原需求中不存在，现在新增的内容。
例如：
新增页面 新增模块 新增字段 新增权限 新增第三方接口 新增统计报表 新增导入导出 修改业务流程
这两类事情必须区别对待。
如果你把所有新增都当成修改处理：
项目必亏。
所以项目开始前，一定要写清楚规则：
每个阶段包含 2 轮基于已确认需求范围内的合理修改；超出已确认范围的新增功能、页面、字段及流程调整，需重新评估工期和费用。
这句话不是为了和客户对立。
而是为了避免双方预期失控。
三、需求变更必须有正式动作
很多项目后期扯皮，不是因为需求复杂。
而是因为需求都是在聊天记录里零散产生的。
今天一句。
明天一句。
后天再补一句。
你顺手做一点。
客户顺手提一点。
最后谁都说不清：
到底改了多少？
现在我的做法很简单：
只要超出原范围，就先确认，再开发。
哪怕只是微信消息，也必须确认：
新增什么内容 为什么新增 影响哪些功能 增加多少工期 是否增加费用 是否影响上线时间
这个动作非常重要。
因为它把：
“随口一提”
变成了
“正式变更”。
很多需求到了这一步，客户自己就会重新思考：
“这个功能真的现在必须做吗？”
不少需求会自然消失。
四、需求变更确认模板
直接复制即可使用。
需求变更确认
项目名称： XXX 系统开发
变更提出方： 客户 / 开发方
提出时间： XXXX 年 XX 月 XX 日
原需求范围
包含：
客户列表 新增客户 编辑客户 客户详情 基础搜索
本次变更内容
新增：
客户等级筛选 跟进状态筛选 批量导出 Excel
影响范围
前端客户列表新增筛选区域 后端接口增加筛选参数 数据库确认等级字段 新增导出 Excel 功能 增加测试用例
评估结果
预计增加工期：3 个工作日 预计增加费用：1500 元 是否影响上线时间：是
上线时间顺延 3 个工作日。
确认方式
请回复：
确认增加以上需求，并接受工期和费用调整。
收到确认后，我将安排开发。
五、客户说：“这个也要加钱吗？”
这是很多自由程序员最怕听到的一句话。
其实完全不用心虚。
话术一：解释型
这个功能不只是页面增加一个按钮，还涉及接口、数据处理和测试，因此已经超出原确认范围。我可以协助开发，但需要重新评估时间和费用。
话术二：选择型
如果这个功能必须本期上线，我们可以按新增需求处理；如果不着急，也可以放到二期，不影响当前版本按时交付。
话术三：范围提醒型
这个功能不在之前确认的需求范围内，因此属于新增需求。为了避免后续范围不清，我先整理一份变更说明，确认后再开始开发。
不要轻易说：
“给你便宜点吧。”
更不要说：
“这次免费帮你加。”
你可以偶尔赠送一些小调整。
但不要让客户形成习惯：
只要说“顺手”，就能免费获得新功能。
六、什么时候可以免费改？
并不是所有修改都要收费。
如果什么都收费，合作体验也会变差。
我的原则是：
小范围、低成本、不影响结构的调整，可以免费。
例如：
改几个字 调整按钮颜色 微调排版间距 修改字段名称 修复明显 Bug
但只要满足以下任意一项：
新增页面 新增功能 新增字段 新增接口 修改数据库 修改权限体系 修改业务流程 影响上线时间 需要额外测试
就应该进入变更流程。
七、把规则写进报价单和合同
最好的需求管理，不是在客户提需求时解释。
而是在项目开始前就写清楚。
合同建议增加如下条款：
本项目报价基于双方确认的需求范围。项目执行过程中，如客户提出超出原范围的新页面、新功能、新字段、新流程或第三方接口接入，需另行评估工作量、费用及开发周期。相关变更经双方确认后执行。
再补充一句：
未经双方确认的新增需求，不属于本项目交付范围。
这句话非常重要。
否则客户随口提过的内容，最后都可能变成你的责任。
八、需求变更不是拒绝客户，而是保护合作
很多程序员害怕谈变更。
总觉得一谈钱，客户就会不高兴。
但后来我发现：
靠谱的客户并不反感变更流程。
他们只需要知道：
为什么增加时间 为什么增加费用 会带来什么影响
真正反感变更流程的客户，往往是那些想无限加需求的人。
因为流程会限制他们不断扩张范围。
所以不要把变更管理看成麻烦。
它本质上是一种合作边界。
边界越清晰，合作越轻松。
九、最后给自由程序员的建议
从下一个项目开始：
不要再口头接需求。
当客户说：
“顺手改一下吧。”
先做三件事：
1. 判断是修改还是新增
先确认是否超出原需求范围。
2. 如果是新增，整理变更说明
把影响范围写清楚。
3. 确认工期和费用
获得确认后再开发。
你会发现：
很多项目不是代码写不完。
而是需求边界守不住。
自由程序员真正需要掌握的，不只是技术能力。
更重要的是：
管理范围，保护时间。
客户可以不断提需求。
但你的时间，不应该被一句：
“顺手改一下。”
无限透支。
