项目排期会进行到中途，客户突然提出想增加一个会员积分功能，理由也很直接：别家都有，做上去应该不难。这类临时加需求在网站开发中并不少见，但“加一个功能”从来不是简单的加法。功能背后涉及页面、数据表、后台权限、测试范围、上线时间和后续维护责任，任何一项没有算清，原本稳定的排期就可能被拖出缺口。接不接，不能靠当场拍板，而要按顺序判断。
先问清三件事，再谈技术。第一，积分给谁用，是全部注册用户，还是只针对某一类会员；第二，积分怎么获得、怎么消耗，是下单返积分、签到送积分，还是后台手动调整，消耗端是抵现、换礼品还是换权益；第三，谁来长期运营这套规则，是客户自己有专人维护，还是希望开发方连规则一起代管。这三问答完，基本能分清它是展示型需求还是业务系统需求。只在前端放一个积分数字，和让积分真实参与订单金额计算，工作量完全不在一个量级。
接着按五步清单逐项核对。第一步，翻出原合同的功能清单，确认积分是否落在已约定的范围之外，避免把新增内容混进原有交付。第二步，评估数据表结构是否要动，积分账户、流水记录、有效期、冻结与扣减逻辑，往往需要新增表和关联字段。第三步，评估后台权限是否要扩，运营人员能否查询、调整、导出积分，是否需要操作日志。第四步，评估测试与上线窗口，积分涉及金额和用户权益，测试用例会明显增加，赶在活动前硬上风险很高。第五步，评估后续维护归属，规则调整、数据异常、对账问题由谁响应，要提前说清。
有三种做法要尽量避开。一是口头答应后补合同，先做再说，最后范围、费用和责任都模糊；二是直接砍掉其他已排期功能硬塞进来，看似保住了进度，实际把风险挪到了别处；三是把运营规则写死在代码里，比如固定比例、固定门槛，日后客户想改一次就要发一次版本。更稳妥的方式是把规则做成可配置项，同时明确配置由谁操作、改动如何记录。
在需求变更沟通中，it数运通常先把变更写成可核对的条目，再谈排期和资源：新增哪些页面、动哪些数据结构、扩哪些权限、增加多少测试量、上线时间是否顺延。条目清楚，双方才好判断值不值得做、什么时候做。这正是“技术有章法，服务有回应”的落地方式，不是一味答应，也不是简单拒绝。
最后建议用一页纸的变更确认单收口，字段包括变更名称、需求描述、涉及页面与接口、数据结构影响、权限影响、测试范围、预计工期、费用影响、上线窗口、验收标准、维护责任和双方确认日期。把这些写清楚，比会上的一句“应该不难”可靠得多。涉及具体合同条款与双方权益，仍以书面约定为准。
