能通过验收却无法使用,通常不是“验收太松”或“网站有Bug”这么简单。缺口一般落在两类位置:一类是验收范围只覆盖了文件与页面,没覆盖运行条件;另一类是运行条件已具备,但旧系统或旧合作关系退出时,把仍然有价值的部分一起切断了。要界定缺口,先判断它属于哪一类,再决定是补交付、改验收,还是保留部分旧资产继续用。
常见场景是:栏目齐全、页面能打开、后台能登录,验收单上每一项都打了勾。但真正要用的时候,编辑发不出一篇带附件的公告,客服看不到历史留言,运营改不了首页轮播,或者表单提交后没有人收到通知。此时争议往往变成“这算不算没交付”。
更麻烦的是旧关系退出阶段。旧服务商停掉服务器或后台权限,新交付的静态页面虽然能看,却接不上原来的数据库、表单接收地址或图片存放位置。表面上是“新站已交付”,实际上是业务链条断在中间。
解释一:验收口径只覆盖了“看得见的部分”。清单写的是页面数量、栏目名称、浏览器打开是否正常,没有写“谁在什么权限下完成什么动作”。这种缺口属于验收定义问题,交付方可能确实完成了约定内容,但约定本身没覆盖使用场景。
解释二:验收口径没问题,是退出时把仍在使用的部分一起处理掉了。比如旧表单接收邮箱、旧图片目录、旧留言数据、旧跳转规则,这些不在新交付清单里,却仍在被业务使用。旧系统一关,缺口立刻出现。这种缺口属于退出顺序和资产归属问题,不是新交付方单方面能补的。
两种解释对应完全不同的动作:前者要补充验收项并让交付方补做;后者要先确认哪些旧资产仍有价值,再决定迁移、导出还是保留旧环境一段时间。搞错方向,就会把“该保留的旧数据”当成“该补做的新功能”反复扯皮。
可以按下面几条去核对,证据指向哪边,缺口就归到哪边。
这里要提醒一点:后台访问量下降、抓取量归零、页面打不开,这些现象都不能单独证明某一方处理正确。它们也可能是流量本身变化、临时网络问题或访问策略调整造成的。判断缺口要靠“业务动作能否完成”这条主线,而不是靠某个统计数字的涨跌。
假设某单位换建站服务,旧站退出,新站交付。验收时页面全部通过,但一周后编辑发现无法发布带附件的通知。可以这样处理:
这个例子里,动作清单是分界工具。先做动作清单,缺口会自己显形;跳过这一步,双方只能在“验收过了没有”上循环争论。动作清单完成后,下一步动作也随之明确:属于口径缺项的,补配置并复验;属于旧资产遗漏的,先保住数据再接新系统。
不是所有旧内容都值得留,但以下几类在退出前值得单独确认:仍在被业务使用的表单接收地址和通知邮箱;历史留言、订单、会员等带业务价值的数据;被外部引用或搜索流量仍在进入的旧页面地址;以及仍在使用的图片、附件目录。保留方式可以是导出备份、迁移到新环境,或让旧环境只读运行一段时间。具体选哪种,取决于这些资产是否还产生业务动作,以及迁移成本是否低于重建成本。
界定缺口的最终标准不是“验收单签没签”,而是“约定的业务动作能不能完成”。能完成,验收才算闭合;不能完成,就先分清是口径缺项还是旧资产遗漏,再决定补做、迁移还是保留。把这个判断做在前面,退出旧系统时才不会把仍有价值的部分一起丢掉。