网站制作公司排名，合作中途业务缩减时交付范围如何重新划分
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /3e0db67702ca.html
📄
网站制作公司排名，合作中途业务缩减时交付范围如何重新划分
结论先说：业务缩减后，交付范围应当按“已经产生沉没成本的部分尽量保留、尚未开工的部分优先砍掉、共享底层能力重新定价”三步重划，而不是按合同总额等比例缩水。等比例缩水看起来公平，却会让已经完成一半的模块烂尾，反而增加返工成本。下面给出可操作的条件、反例和下一步动作。
先判断缩减发生在哪个阶段，再决定砍哪一块
合作中途业务缩减，交付范围的划分方式取决于剩余工作量落在哪个阶段。可以粗略分成三类：
- 需求与设计阶段：此时沉没成本主要是沟通和文档。缩减后可以直接删减页面数量、功能模块，甚至暂停整个项目，代价最小。
- 开发与联调阶段：部分代码已写完，数据库结构已定型。此时砍掉一个功能，可能连带影响已完成的关联模块，需要评估“拆掉它”本身的工作量。
- 上线与运维阶段：缩减通常表现为减少后续迭代、暂停推广页或降低服务器配置，而不是删功能。
判断依据不是合同写了多少项，而是问一句：砍掉这项，会不会让另一项已经做完的工作白做？如果会，优先保留；如果不会，优先砍掉。这个判断做完，再谈价格调整才有意义。
两种常见做法：等比例缩水 vs 按模块重估
业务缩减时，甲方常见的两种要求是：按剩余预算等比例减少交付，或把没做的模块直接删掉、按模块重新计价。两者都成立，但适用条件不同。
等比例缩水成立的条件
当项目模块之间耦合度低、每个模块都能独立验收时，等比例缩减是可执行的。比如十个独立的产品展示页，砍掉四个，剩下六个照常做，双方都不吃亏。代价是：单价可能不变，但甲方拿到的整体价值下降，且如果后期业务恢复，重新补做被砍模块往往要重新走一遍需求确认。
按模块重估成立的条件
当项目存在共享底层（如统一登录、统一支付、统一后台权限）时，按模块重估更合理。因为底层已经为全部模块建好，砍掉模块并不能退还这部分成本。此时正确的做法是：把底层能力单独列价，剩余模块按实际工作量重新报价。代价是谈判更复杂，甲方可能觉得“没做的凭什么还收钱”，需要乙方拿出已完成工作的证据。
一个假设例子说明差异：假设原合同包含商品、订单、支付三个模块，开发到一半时甲方决定不做支付。等比例缩水会直接扣掉支付模块的报价，但订单模块里已经写好的支付回调逻辑就成了死代码；按模块重估则会保留订单模块中与支付对接的接口部分，只扣掉支付渠道接入和测试的工作量。两种算法结果可能相差不大，但后者留下的代码更干净，后续恢复支付时改动更少。
使结论失效的反例：缩减后需求反而变复杂
上面这套划分方法有一个明确的失效场景：业务缩减后，剩下的功能反而需要更高标准。例如原来做十个页面，其中三个是普通展示页；缩减后只保留一个页面，但这个页面要承担全部转化任务，需要加表单验证、数据埋点、A/B 测试结构。此时“砍掉九个页面”并不等于工作量减少九成，剩下的一个页面可能比原来三个页面加起来还重。
遇到这种情况，等比例缩水和按模块重估都会失真。正确动作是：先确认剩余交付物的验收标准是否提高，如果提高，就按新标准重新估算，而不是在旧单价上做减法。这一步不做，后期一定会在“这个页面怎么这么贵”上扯皮。
下一步动作：把缩减写成一份变更单
无论选择哪种划分方式，最终都要落到一份书面变更单上。变更单至少包含三部分：删除项、保留项、新增或调整项。删除项要写明“不再交付”，保留项要写明“验收标准不变”，调整项要写明“因缩减导致的接口改动由谁承担”。
这份变更单的作用不是走流程，而是让下一步的付款节点有依据。如果变更单里只写“总价减少 X”，不写清楚哪些模块被删、哪些接口被保留，那么下一次付款时双方对“做到什么程度算完成”的理解一定不一致。把删除项和保留项列清楚，付款节点才能对应到具体交付物，后续恢复业务时也能直接看出哪些部分需要重新启动。
最后提醒一点：缩减谈判中，乙方最容易让步的是“没做的部分不收钱”，最容易忽略的是“已做但被砍的部分如何计价”。如果这部分不单独说明，它就会变成双方各自的模糊地带，下一次合作时被反复提起。
