网站服务公司：合作中途业务缩减，交付范围如何重新划分
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /73f3d9f48f0e.html
📄
网站服务公司：合作中途业务缩减，交付范围如何重新划分
先给结论：业务缩减后，交付范围不应按“砍掉一部分页面”或“少做几个功能”来粗略处理，而要先判断缩减发生在哪个阶段。若仍处于需求与原型未冻结阶段，可以重签范围清单，按新的业务目标重新排优先级；若已进入开发或已上线维护阶段，则应把已投入工作与后续新增工作分开，前者按原合同结算或折算，后者按缩减后的目标重新报价。判断依据不是对方口头说“工作量少了”，而是可交付物清单、已完成节点和验收记录是否发生变化。
假设情境：预算砍掉三成后，双方为什么谈不拢
假设一家做区域零售的企业，原本委托网站服务公司做官网改版，包含首页、六个频道页、会员积分模块和后台内容管理。合同签完两个月后，企业线下业务收缩，决定把会员积分模块去掉，频道页从六个减到三个，同时希望上线时间不变。此时双方最容易出现的分歧是：服务公司认为会员模块已经做完需求梳理和接口设计，不能因为不开发就按零计价；企业则认为没上线的模块不应该继续付费。这个情境是虚构的，用来展示判断方法，不代表任何真实项目。
要解决这个分歧，第一步不是重新谈总价，而是把原合同拆成三类条目：已完成并确认的、正在进行的、尚未启动的。已完成部分对应的是已经发生的工作，缩减不改变它的结算方式；正在进行部分要判断是继续做完更省，还是立即停止更省；尚未启动部分才是重新划分范围的主要对象。
先看缩减发生在哪个阶段，再决定重签还是变更
如果缩减发生在需求确认和原型评审之前，原合同里的页面数量、功能模块和内容迁移量都还没有进入实际生产，此时适合直接重签一份范围更小的合同。重签时把缩减后的交付物写成可验收的条目，例如“三个频道页的视觉稿与前端实现”“后台保留文章发布与栏目管理”“会员积分模块不进入本期范围”。这样做的结果是后续验收有明确对照，不会因为口头缩减留下模糊地带。
如果缩减发生在开发中或上线后，重签整份合同往往不现实，因为已经投入的工作难以简单归零。这时更适合用变更单处理：变更单只写三件事——停止哪些未启动条目、保留哪些已进入开发条目、新增或调整哪些验收条件。变更单确认后，下一步的付款节点和上线范围都以它为准，而不是继续引用原合同里的完整清单。区分这两种情况的实际意义在于：重签适合范围整体变小且尚未大量投入；变更单适合范围局部收缩且已有不可逆投入。
把“少做”换算成可验收条目，而不是按比例打折
业务缩减后，常见的错误做法是按原总价乘以一个缩减比例来重新报价。比例看起来公平，但它无法回答哪些工作已经发生、哪些工作可以取消。更可操作的方法是把缩减后的范围写成一张验收清单，每一项都对应一个可观察的结果。例如：
- 保留项：三个频道页的静态页面与移动端适配，验收时检查页面在常用分辨率下是否错位。
- 保留项：后台文章发布、栏目管理和基础权限，验收时检查编辑、删除、发布是否按角色生效。
- 停止项：会员积分模块的需求文档、接口设计和前端组件，若已产生则单独列出已完成部分。
- 调整项：原定的内容迁移数量从若干篇减少到新的数量，按实际迁移并校对完成的篇数确认。
这样做的结果是，双方不再争论“少了多少工作量”，而是逐项确认“这一项做还是不做、做到什么程度算完成”。如果某个停止项已经产生了设计稿或接口文档，把它作为已完成条目单独结算，而不是混在缩减后的总价里。
缩减后要重新确认的三件事：时间、维护和内容归属
范围缩小后，上线时间不一定自动提前。如果服务公司的排期已经锁定，缩减开发量可能只是减少投入人力，而不是把交付日期整体前移。因此需要重新确认：缩减后的上线日期是保持原计划，还是双方同意提前；如果保持原计划，空出来的时间用于哪些保留项的打磨。这个确认会影响下一步的验收节奏。
维护范围也要重新对齐。原合同可能按整站功能报价维护，缩减后如果会员模块不再存在，维护清单里的对应条目应同步删除，避免继续为不存在的功能付费。同时要确认内容归属：已经完成的设计稿、代码和文档是否随缩减后的结算一并交付，还是只交付上线部分。归属不清时，后续想恢复某个模块会涉及重新授权或重新开发。
最后，把重新划分后的范围写进一份双方确认的变更记录，注明生效日期和替代的原合同条款。动作本身不复杂，但它决定了后续付款、验收和争议处理时以哪份文件为准。
什么时候不该缩减，而是暂停或分期
并非所有业务缩减都适合立即重新划分范围。如果缩减只是短期波动，且原合同里的功能模块彼此依赖较强，例如会员模块和订单模块共用同一套用户体系，强行拆掉一个可能导致另一个也无法正常运行，此时暂停部分条目、保留整体架构，比直接删除更合理。判断条件是：被缩减的条目是否与其他保留条目共享数据结构和接口。如果共享，删除的代价可能高于暂时保留；如果不共享，删除通常更清晰。
另一种情况是缩减后剩余预算不足以支撑任何有意义的交付。这时与其把范围切得很碎，不如明确暂停合作，约定已完成部分的结算方式和资料交接，等业务前提重新明确后再决定是否继续。这样做的结果是把损失控制在已投入部分，而不是用一份被切碎的范围继续消耗双方。
无论选择重签、变更还是暂停，核心动作都是把缩减后的交付写成可验收条目，并把已完成与未启动分开。下一步的报价、排期和维护清单，都应以这份重新划分后的范围为准。
