固定总价合同里,范围变化后能不能加钱,取决于变更是否改变了原报价所依据的可验收成果,而不是取决于工作量感觉变多了。若合同写的是“按现有栏目结构完成页面模板改版”,那么新增一个需要独立后台、独立数据源和独立权限的栏目,通常构成增项;若只是把某个按钮从蓝色改成绿色,一般属于原范围内的调整。关键动作是:在动工前把变更写成一条可验收的交付描述,并标注它是否改变页面数量、数据来源、权限角色或验收条件。缺少完整数据或权限时,仍可先完成这一步,但不能据此推出最终增减金额。
固定总价下最常见的冲突是:甲方认为“只是多了一个小功能”,乙方认为“这等于重做一套逻辑”。两种解释都成立,区别在于变更触及的是表现层还是结构层。
判断哪一种解释成立,不能靠“看起来像不像小改动”,而要看变更是否让原来的验收清单失效。如果原有验收项仍然全部成立,只是多出若干项,属于增项;如果原验收项本身被推翻,则可能已经超出增减项范畴,需要重新协商范围基线。
以下证据可以在缺少完整后台权限或历史数据的情况下先行收集,它们足以支撑“是否构成增项”的初步判断,但不足以单独确定金额。
反过来说,如果变更没有增加模板、没有新增数据源、没有新增角色、也没有替换验收条件,那么把它直接计为增项就缺乏依据。此时更合理的动作是先记录变更,再观察它是否在开发中引发连锁改动。
在没有完整字段清单、接口文档或后台权限的情况下,不要急着报增减金额,而是先做一次变更登记。具体动作:把变更写成一句话,格式为“在什么页面,对什么对象,做什么操作,达到什么可验收结果”。
假设一个场景:原报价范围是“现有五个栏目的列表页与详情页改版”。现在提出“增加一个会员中心,能查看历史订单”。登记后可以发现,它至少新增了会员身份、订单数据来源、登录状态和权限判断,因此属于结构层增项。如果只是“在会员中心页面加一个返回顶部按钮”,则属于表现层调整。
这个动作的结果会直接影响下一步:登记为结构层增项的,应暂停该部分开发,先确认数据来源和验收条件,再谈增减;登记为表现层调整的,可并入原范围继续推进,但要在交付说明中记录,避免结算时被重新翻出。
固定总价不等于范围冻结。要让增减项可计算,报价方案里至少应保留三个字段,而不是只写一个总价。
需要说明的是,以上字段解决的是“是否构成增减项”和“按什么口径计量”,并不等于给出了具体金额。金额仍取决于双方对单价或打包方式的约定。缺少这些字段时,即使记录了变更,也很难在结算时形成双方都认可的算法。
变更登记能证明范围发生了变化,但不能单独证明以下事项:变更一定导致工期延长;变更一定导致费用增加;变更后的页面一定无法按原验收条件通过。这些结论都需要结合具体实现方式和测试结果判断。
同样,某个功能在演示环境中没有报错,也不能证明它不构成增项。演示通过只说明当前路径可用,不代表数据来源、权限边界和异常处理已经覆盖。把“能演示”当成“在原范围内”,是固定总价改版中最容易在结算阶段引发争议的推断。
因此,固定总价下处理范围变化的顺序应当是:先登记变更,再判断它是否改变范围基线,然后确认计量口径,最后才谈金额和工期。缺少完整数据或权限时,前三步仍可执行,但不应跳过它们直接给出增减结论。