一个设备租赁平台的项目，原定八周。第五周客户要求后台加一个合同到期自动提醒功能，项目经理没含糊，当天出了张变更单：改动内容、影响范围、顺延六个工作日、增加费用三千二。客户签字，一周后功能上线，项目最终只延了五天。定制建站的变更管理，说穿了就是给改需求这件事立个规矩，立得好，工期是保得住的。
一张变更单该写什么
五项就够：改什么，写成一句话能看懂的描述；为什么改，需求来源是什么；影响哪些已完成的页面和功能；工期顺延几天；费用怎么算。别用邮件长篇大论，一张单子一页纸，双方签字或微信文字确认。变更单最大的价值不是收费依据，是让提需求的一方看清代价——很多客户看完「顺延六天」这行字，主动说那这个先不做了。变更单不苛求格式，能讲清五件事就行，哪怕是拍照发的一张手写表格，也比口头一句「帮我改一下」强百倍。
变更单还有一个没人提的好处：它替企业留了决策记录。一年后复盘，哪次改动是临时起意、哪次是市场变化倒逼，翻变更单一目了然。有家客户把两年的变更单整理出来，发现六成改动来自同一个人，回去就把内部提需求的流程改了。
工期和费用怎么算才服气
工期不是拍脑袋：改动落在已测试完成的模块上，重测时间要算进去；改动牵连的关联页面，一个都不能漏。费用按人天算，写进合同的附加单价表里，改多久、几个人、单价多少，三个数一乘就有答案。透明公式的好处是双方都不用猜，吵不起来。重测成本最容易被漏算，改一个已经测过的模块，回归测试的时间常常不比开发少。
有些「变更」其实是前期欠的账
要注意区分：需求清单里写明了的功能，做出来和描述不符，那叫缺陷，免费修；清单里没有的，才叫变更。很多纠纷就混在这里，客户觉得「我明明说过」，翻签约附件却找不到。所以变更管理的第一道防线其实在签约时——清单写多细，后期扯皮就有多小。把「缺陷」和「变更」两个词的定义在启动会上念一遍，双方都点头，后面就清净了。
建议企业和建站方在启动会上就把变更流程说定：多大量级走变更单、响应时间多长。比格网络这类项目制度成熟的团队，做定制建站一般都有现成的变更单模板和单价表，开工前要一份样本看一眼，心里就有底了。变更管理做得顺的项目，客户反而更愿意提想法，因为每一笔代价都算得清楚。
