项目做到一半老板要加功能，需求变更这笔账怎么算

软件项目最常见的一幕：签约时功能清单写得清清楚楚，做到一半，老板开会时说了句「再加个会员积分体系吧，不难吧？」

开发方点头说好，项目经理默默加班。三个月后项目延期、预算超支，双方开始互相埋怨。问题不在那句「不难吧」，而在于没有一套变更的处理机制。

一、一句「加个功能」背后是什么

在业务人员眼里，加功能就是多一个页面。在开发眼里，它意味着：数据库要加表、接口要改、权限要配、已有页面的逻辑要联动、测试用例要补、文档要更新、上线要重新走一遍。

更麻烦的是关联影响：加积分可能牵动订单、支付、退款、对账四条链路。原本已经测完的模块，要重新回归测试。

所以变更从来不是「加一点工作量」，而是对已经完成部分的一次扰动。

二、变更分三种，别只盯着「新增」

• 新增：加功能、加角色、加报表，最常见；
• 修改：调整已有功能的规则、流程、字段，往往比新增更费工，因为要改已经写好的代码；
• 删除：看着是减法，但已经投入的开发、测试成本无法回收，删掉还可能影响其他模块的依赖。

三种都要走评估，尤其是「删除」和「小改一下」，最容易被当成免费。

三、变更该怎么走流程

建议固定成五步，双方都省心：

• 书面提出：不用正式公文，一张变更申请单即可，写清要什么、为什么；
• 影响评估：开发方在约定时间内给出评估，包括涉及模块、增加工时、费用、对里程碑的影响；
• 双方确认：企业方确认是否接受这个代价，可以砍需求、可以换方案、也可以推迟到二期；
• 排期实施：确认后进入排期，未确认的变更不进开发队列；
• 归档留痕：变更单、评估记录、确认邮件统一存档，作为后续验收和结算的依据。

四、变更单上必须有的几项

一张合格的变更单，至少包含：变更内容描述、变更原因、影响的模块与页面、增加的人天、费用金额、对上线时间的影响、验收标准、双方签字确认。缺了「对上线时间的影响」这一项，延期就会变成扯皮。

五、合同里提前写好的条款

事后争执，多半是合同里没写。签约时把这四条加进去：

• 变更机制：所有变更须以书面变更单为准，口头需求不作为开发依据；
• 计价方式：约定人天单价，或按变更工作量分档定价；
• 免费额度：可以约定合同金额一定比例内（比如 5% 工作量）的小变更不额外收费，超出部分另行计费；
• 里程碑调整：累计变更超过约定阈值时，双方重新确认上线时间。

六、怎么从源头减少变更

一是设需求冻结节点。开发启动后，非必要不调整核心流程，新想法进入二期清单。

二是给需求分级。把功能分成「必须有」「可以有」「这次不做」三档，预算紧张时先从第三档砍。

三是定期评审。每两周一次短会，集中处理积压的变更申请，避免零散口头需求堆成山。

四是让业务方看见代价。把「这个变更等于两周工期」明确说出来，很多需求会自己消失。

写在最后

需求变更不是坏事，它说明业务在往前走。真正伤项目的是没有代价感的变更——提出的人不知道要付多少钱，执行的人不敢说做不完。名牌商务网提供软件定制开发与项目管理咨询，合同阶段就把变更机制定下来，后面少吵很多架。