项目中途加需求不可怕，可怕的是口头一说了之。开发说好，回去加了个按钮，月底账单多出八百块，客户觉得被宰，开发觉得委屈，因为从头到尾没有一个字落在纸面上。小程序定制项目里，变更单就是治这个病的药方。
口头变更的代价
真实的场景：客户在微信上说，商品列表加个筛选吧，顺手的事。开发顺手做了。结项时这份顺手被计了三个人天，一千八到两千四，客户不服：当初你们说好的。谁说的？说了什么范围？都没证据。变更单解决的就是这三问。一份合格的变更单五要素：改什么、为什么改、影响多少人天、工期顺延几天、双方签字。填单十分钟，省掉的是月底的争吵。
不是所有变更都要加钱
客户担心变更单是服务商的加钱工具，其实规则定好了，多数变更走的是免费通道。开发过程中发现的逻辑矛盾、界面上明显不合理的细节、为了通过微信审核必须的调整，这些属于把事做对的范畴，正常的服务商不会计费。真正计费的是需求扩大：原来不要的支付功能现在要了，原来的单店改成连锁多店。数量上也有界限，一个四十五天的项目，变更条数控制在十条以内、新增工时控制在一成以内，多数项目扛得住；超过这条线，说明前期需求梳理欠了账，该停下来补一次范围评审，而不是继续往失控的方向走。区分的标准很简单，功能清单里有没有。
- 变更申请当天回复，四十八小时内给出工时评估
- 评估结果双方确认后才动工，先做后谈的一律拒收，小程序定制的变更尤其如此
- 变更累计超过原工时一成，触发范围评审会
变更单也是二期路线图
被拒掉或者延期的新需求，都进变更登记表，这张表积累下来，就是天然的二期需求池。上线后规划二期，不用重新调研，把表里的条目按使用频率和业务价值排个序就行。比格网络交付项目时会连同这张表一起交还客户，很多客户的二期合同，就是从这张表里长出来的。这张表还有个妙用，客户看到自己提的想法被认真记录和评估，配合度反而提高，扯皮自然就少了。变更单记录的数字，就是项目健康度的仪表盘，每月扫一眼，趋势不对早处理。
两条建议：合同里把变更流程和计费规则写清，这是对双方的保护；作为客户，提出变更时主动要求填单，别怕麻烦，怕麻烦的那一刻就是扯皮的种子。规则先行，加需求这件事就从撕扯变成了流程。
