合作中途业务缩减,交付范围不能按“原合同砍掉一部分”来重新划分,而应先确定哪些成果已经独立可用、哪些工作存在前后依赖。更稳妥的做法是:把原任务拆成“已可交付”“必须收尾才能用”“可整体暂停”三类,再据此重签一份范围确认单。下面用一个假设情境说明怎么把分歧变成可核对的项目。
业务缩减可能发生在三个不同层面,对应完全不同的划分方式。
判断依据不是“哪部分花钱多”,而是“哪部分拿掉之后剩余部分仍然能独立运行”。能独立运行的部分,才可以整体移出范围。
以下为假设情境,用于说明划分方法,不代表任何真实项目。某怀化本地企业原计划建一个带产品展示、在线询价、后台内容管理三部分的网站。项目进行到中途,企业业务线收缩,决定只保留产品展示和询价,后台内容管理暂时不做。此时双方出现分歧:建站方认为询价表单已经做好,算完成;企业方认为询价提交后没有后台可看,等于没完成。
这个分歧的根源不是谁对谁错,而是“完成”的定义没有落到可核对的对象上。询价功能实际包含三件事:前台表单、提交后的数据去向、以及查看这些数据的方式。前两件属于前台和接口,第三件属于后台。缩减后如果完全不做后台,那么“查看询价记录”这件事必须有替代方案,否则前台表单即使能提交,对企业也没有使用价值。
第一步,双方各自列出“缩减后必须能用的结果”,只写结果,不写功能名。例如企业方写“客户提交询价后,我能收到并保存这条信息”,建站方写“表单提交接口可用”。两份清单放在一起,差异就变得具体。
第二步,针对差异项确认依赖关系。假设确认结果是:询价记录暂时通过邮件通知保存,不单独做后台。那么需要确认邮件通知是否在本次范围内、由谁配置、测试到什么程度算通过。这个动作会直接影响下一步——如果邮件通知也不在范围内,那么询价模块就不能算可交付,应整体移出或降级为静态展示。
第三步,把确认结果写成一份范围确认单,至少包含:保留项、移出项、移出项的当前状态、保留项之间的依赖说明、以及下次启动移出项时需要重新确认的前提。这份确认单不需要很长,但要让双方对“现在交付什么”有同一份文本可查。
第一,把“没做完”直接等同于“不要了”。有些工作虽然不在缩减后的范围里,但已经完成了一半且与保留项耦合。例如账号体系做了一半,而保留的询价功能依赖它。这时不能简单移出,要么补完到可用状态,要么把保留项改成不依赖它的实现方式。
第二,只谈钱不谈状态。缩减后如果只协商总价调整,不记录移出项完成到什么程度,下次重启时双方会再次争论。完成状态应写成可核对的事实,例如“数据结构已确认,页面未开始”,而不是“做了一部分”。
第三,忽略内容和素材的归属。已拍摄的产品图、已整理的文案、已注册的账号,这些在缩减后归谁使用、放在哪里,需要在确认单里写明。否则项目暂停后素材散落,重启成本会明显上升。
按比例缩减成立的条件是:移出部分与保留部分之间没有共享的数据结构、账号体系或接口约定,各自可以独立测试和上线。此时可以按剩余工作量重新报价。
必须整体暂停的条件是:保留部分的核心流程依赖移出部分才能跑通,且短期内没有替代方案。例如询价提交后必须写入某个后台,而后台被移出。这种情况下,强行交付一个跑不通的流程,对双方都没有意义,更合理的做法是暂停并记录当前状态。
还有一种中间情况:保留部分可以先用简化方式跑通,例如用邮件代替后台。这时应把简化方式明确写进范围,并注明它是临时方案还是长期方案。临时方案要写清后续替换时需要重新确认的内容,避免下次改回时重复讨论。
范围确认单签完后,建议立即做一次可运行验证:只测保留项,按真实使用路径走一遍,记录哪些环节能通、哪些环节依赖人工。验证结果会决定验收标准怎么写——如果邮件通知需要人工查看,验收就不能写“自动通知”,而应写“提交后邮件可收到且内容完整”。
同时把移出项整理成一份暂停清单,注明每项的当前状态和重启前提。这份清单不参与本次验收,但它是下次继续合作时的起点。做到这一步,业务缩减带来的分歧就从“各自理解”变成了“同一份可核对的记录”,后续无论是继续合作还是更换服务方,都有据可依。