可以分期的交付,不是“不重要的工作”,而是那些彼此独立、能单独验收、且延后不会让已上线部分失效的模块。预算减半时,优先把“上线必需”和“上线后仍可独立补做”的部分拆开:前者一次做完,后者按阶段排期。如果拆开后发现某块交付一旦延后就会导致整站无法运行或数据无法衔接,那它就不能分期,必须留在第一期。
可分期交付有三个可核对的判据,缺一不可:
按这三条筛,常见的可分项是:内容页面的批量填充、非核心栏目的模板、站内搜索、多语言版本、数据统计与报表、会员或登录体系、部分营销落地页。而首页与核心转化路径、基础导航结构、表单提交与通知、移动端适配、基础安全与备份,通常不具备分期条件,因为它们一旦缺席,整站就不成立。
预算减半时,出资方、业务方和执行方对“砍掉什么”常有三种不同默认。出资方以为砍的是“锦上添花”,业务方以为砍的是“以后再说”,执行方以为砍的是“工作量减半”。这三种理解不对齐,报价单就会反复改。
把分歧转成可核对项的做法是:列一张表,每一行是一个交付模块,列出三栏——上线必需 / 可延后 / 延后后需重做的成本。第三栏是关键:有些模块延后不是“晚点做”,而是“第一期做完还得改”,那它实际成本更高。用这张表对齐,讨论就从“砍哪个”变成“哪个延后的返工代价可接受”。
假设原方案包含首页、产品列表、产品详情、站内搜索、会员登录、数据报表六块。预算减半后,第一期只做首页、产品列表、产品详情和表单通知,第二期补站内搜索和数据报表,会员登录视业务需要再定。前提是:第一期在搭建内容结构时就预留搜索字段和报表所需的数据埋点位置,第二期接入时不需要重构模板。如果第一期没有预留,第二期补搜索往往要改动列表和详情页的字段结构,返工成本会吃掉分期省下的钱。
如果延后的模块与第一期共享同一套底层结构,且结构在第二期必须改动,那么分期就不成立。典型情况是:内容模型、URL 规则、权限体系、多语言路由这类“地基级”设定。它们在第一期定下后,第二期若要新增,往往牵动已上线的所有页面。
另一个反例是时间敏感型交付。如果某块内容或功能必须在某个业务节点前可用,延后到第二期就等于没有价值,此时它应视为第一期必需,而不是可分期项。判断标准不是“重不重要”,而是“延后是否还成立”。
在让执行方重新报价之前,先由业务方和出资方共同确认三件事:第一期必须上线的页面与功能清单;可延后模块的验收标准;第一期需要为第二期预留哪些字段、结构和接口位置。这三件事确认后,再要求报价按“第一期 / 第二期 / 预留改动”三部分分别列出。
这样做的结果是:报价不再是一个总数,而是可核对的分段成本。哪一段超预算、哪一段可以再延后,都能单独讨论。如果执行方无法把某模块拆成独立验收项,说明该模块与其它部分耦合较深,把它放进第一期通常比强行分期更省事。