项目开工两周，客户在微信上说：导航栏能不能改成红色的，顺便加个拼团功能吧。在外包这行，这种随口一句话，可能让工期多出五天。几天能做好小程序，一半的答案不在开发速度，在需求变更管得好不好。那个客户后来接受了工期顺延五天加两千块的费用，但他真正不痛快的是没人提前告诉他规则。
改动的成本不是改代码那么简单
改动一行界面的文案，五分钟搞定；改一个下单流程，牵扯前端页面、后端逻辑、支付回调、订单状态四处，改完还要把相关功能重测一遍。很多客户觉得我就改了个小地方怎么工期要顺延，其实延的不是那一下，是改动波及的整条链路。还有一种更隐蔽的：改动本身不难，但它打断了开发的连续性，工程师上午排好的活被临时插单，下午重新进入状态又是半天，这种损耗在延期里占大头，却最没人认账。
什么改动最伤工期
- 上线前一周改支付或订单流程，等于核心逻辑重测一遍
- 中途换设计风格，前面的页面全部返工
- 加一个全新模块，比如从展示改成带商城，周期重算
- 文案、图片类的小调整，基本不影响工期，放心提
反过来说，上线后通过后台改的图片和文案，根本不需要动代码，这类需求在一期就该让服务商做成可配置的。改动需求最好攒批提，一次提十条比分十次各提一条省时间得多，也方便对方整体评估影响。
变更管理的正确姿势
靠谱的做法是书面变更单：写清改什么、影响几天、加不加钱，你签字才动工。听起来麻烦，其实保护的是双方。你也可以反过来用这条规则——真到了必须改的时候，按流程走，费用该出就出，比开发到一半推翻重来便宜得多。原型确认环节值得花时间的地方就在这：对着原型逐页过一遍，能提前暴露八成的改动冲动，比开发完了再改便宜十倍。变更单不用写得很正式，微信里发一段话让对方回复确认，也算数，关键是留痕。
两条建议：问几天能做好小程序的时候，也把变更规则问清楚，这一条比砍价更影响你的上线日期；比格网络在需求确认阶段就会把变更机制和客户讲明白，白纸黑字，双方都省心，你可以拿这个做法去要求其他团队。
