如果一份交付物在验收单上被勾选,却进不了实际使用环节,缺口通常不在“有没有交”,而在“交的东西能不能被接住”。这时要先把验收标准和可用标准分开:验收回答的是“是否按约定完成”,可用回答的是“接手方是否具备继续使用它的条件”。两者不一致时,先不要急着判定谁违约,而是找出缺口属于权限、数据还是环境依赖。
同样表现为“能验收、不能用”,原因可能完全不同。第一种解释是交付物本身不完整:例如只给了关键词表,没有说明字段含义、优先级依据和更新方式;只给了页面改动建议,没有对应到具体模板或内容类型。此时缺口在交付物内部,验收人如果只核对数量,很容易漏掉。
第二种解释是交付物完整,但使用条件没有同步准备。例如接手方没有后台编辑权限、没有数据查看权限、没有测试环境,或者服务器和发布流程仍由原执行方控制。此时文件本身没问题,缺口在访问和操作链条上。把这两种解释混在一起,就会变成反复补文件、反复说“已经给过了”。
还有一种容易被忽略的情况:交付物按旧环境编写,而接手方已经换了主题、换了发布流程或换了统计口径。它既不是单纯缺件,也不是单纯没权限,而是依赖前提变了。判断时要单独标记,不要塞进前两类。
第一组证据看“打开后能否独立完成一步动作”。假设交付物是一份内容优化清单,接手方在没有原执行方解释的情况下,能否根据清单找到对应页面、完成一次修改并发布?如果不能,缺口更可能在交付物的字段说明和映射关系上。
第二组证据看“权限和路径是否可验证”。让接手方实际登录所需后台,确认能看到对应模块、能保存草稿、能查看必要数据。如果登录失败或看不到入口,缺口在权限交接;如果能看到但不知道改哪一项,缺口回到交付说明。
第三组证据看“同一动作在原执行方手里是否成立”。假设原执行方声称某份配置已经生效,那就让接手方按同一路径复现一次。若原执行方能完成、接手方不能,差异通常出在账号、环境或未写明的操作步骤上;若双方都不能完成,则更可能是交付物本身没有形成可执行状态。
这三组证据的作用不是追责,而是决定下一步动作。缺交付说明,就补字段定义和对应关系;缺权限,就列权限清单并逐项开通;缺环境,就记录依赖版本和替代方案。动作不同,后续排期和验收方式也应不同。
在数据不全、权限不齐的情况下,仍然可以要求接手方做一次空手复现:不依赖原执行方口头解释,只打开现有交付物,尝试完成一个最小闭环,例如修改一个页面的标题和描述、提交一次草稿、记录一次改动前后的观察方式。
这个动作会产生明确结果。若复现成功,说明交付物至少在一个最小场景里可用,后续可以把范围扩大到更多页面和更多字段。若复现失败,失败点就是缺口位置:找不到页面,是映射缺失;打不开后台,是权限缺失;改完无法发布,是流程依赖;发布后无法判断变化,是数据口径缺失。
需要提醒的是,一次复现成功不能推出整套交付都可用,一次复现失败也不能单独证明交付物整体无效。它只能定位当前阻塞点,并决定先补哪一项。下一步应把复现记录写成清单,逐项标注“已具备”“待开通”“待补充说明”,再据此安排交接。
如果只保留原验收单,缺口还会重复出现。更实用的做法是在验收单旁增加一列可用性条件,至少写清四件事:接手方需要哪些账号或权限;交付物依赖哪些数据来源和统计口径;哪些步骤必须由原执行方演示一次;出现不一致时由谁确认。
这四件事不需要一次写全。可以先从当前最阻塞的一项开始,例如先解决后台权限,再补字段说明,再确认数据查看方式。每完成一项,就重新做一次最小复现,观察阻塞点是否前移。这样做的结果不是立刻让所有交付物可用,而是让缺口从模糊的“不能用”变成可排序的待办项。
假设一份交付物包含页面清单、关键词映射和修改建议,但接手方没有发布权限,也没有数据查看权限。此时可执行的最小动作是:先核对页面清单能否对应到现有站点结构,再把权限需求写成清单交给有控制权的一方。若页面能对应、权限开通后能完成一次发布,说明主要缺口在权限;若页面无法对应,则先补映射关系,而不是继续催权限。这个顺序会影响下一步:先补映射可以减少开通权限后的返工,先开权限则能更快验证发布链路是否通畅。
交付物可以验收但不能被使用时,不要只争论验收是否成立。先判断缺口属于交付缺件、权限缺失、环境依赖还是口径变化,再用空手复现定位阻塞点,最后把阻塞点转成带责任人和完成条件的交接项。这样界定的缺口,才能直接决定下一步是补说明、开权限、换环境还是调整验收标准;否则验收单只会继续积累勾选,而使用环节仍然停在同一处。