答案取决于第三方延期是否影响你这一侧可独立验证的交付。如果延期只卡住依赖外部接口、数据或审批的少数环节,就把验收拆成“可独立完成”和“必须等待”两组,先对前者出结论;如果延期已经让整批交付无法判断,就暂停整体验收,只保留可复现的证据记录,等第三方恢复后再合并判断。下面用两种条件展开,并给出可执行动作。
当第三方延期集中在外部数据接入、接口联调、第三方账号权限或审批流程时,你这一侧的页面结构、内容上线、内链调整、日志记录、配置变更记录往往已经可以单独检查。此时拆分的依据不是“谁做的”,而是“没有第三方,这个结论是否仍然成立”。
可执行动作:让执行方按交付项列出三栏——已可验证、依赖第三方、无法判断。对第一栏逐项给出证据位置和检查方法,例如某批页面的标题与正文是否已发布、跳转是否按预期工作、站点地图是否已更新。动作的结果决定下一步:第一栏通过,就把它记为阶段验收,不因第三方延期而整体扣住;第一栏不通过,说明问题不在第三方,应先修内部项。
边界要写清:个别样本能打开、能返回预期内容,不等于规模化后仍然成立。样本量小的时候,人工抽查容易覆盖;数量一上来,缓存、权限、限流、数据同步延迟都可能让原本通过的项目出现例外。所以局部验收只对已检查范围负责,不替未检查范围背书。
如果第三方延期影响的是判断交付是否成立的关键依据,例如数据源本身、对外接口可用性、必须由对方出具的确认,那么拆分验收会制造假结论。此时更稳妥的选择是暂停整体验收,把已完成部分封存为“待合并证据”,而不是提前宣布通过或失败。
判断依据可以看三点:没有该依赖,验收项是否还能被独立复现;延期是否会让已通过项在第三方恢复后失效;继续拆分是否只是为了赶内部时间点。只要前两点成立,就属于核心依赖,不适合硬拆。
实施动作:发出一份延期影响说明,写明受影响交付项、当前已固定证据、第三方恢复后需要重跑的检查项,以及重跑后由谁确认。这样做的结果是:内部不会因等待而停摆,但也不会把未验证部分算作已完成。第三方恢复后,先重跑受影响项,再决定是否合并此前阶段结论。
可独立复现的意思是:换一个人、隔一段时间、按记录步骤操作,仍能得到同一结论。它比“页面已上线”“对方说做完了”更可靠。对SEO服务网站的交付,常见可独立复现项包括已发布内容清单、已变更配置记录、可访问性检查结果、结构化数据是否按预期输出、跳转关系是否一致。依赖第三方的项则包括外部数据回传、对方系统权限、联合审批结果。
动作与结果:把每个验收项写成一句可检查的话,并注明所需条件。如果一句话里出现“等对方确认后才能看”,就归入依赖组;如果不依赖对方即可检查,就归入独立组。这样分组后,延期只会推迟依赖组,不会拖住独立组,也避免把“暂时看不到”误判成“已经完成”。
需要说明的是,请求量、抓取量或某项统计暂时归零,不能单独证明处理正确。它可能是第三方延期导致的采集缺口,也可能是统计口径变化、时间窗口不同或数据尚未回传。把它当作唯一证据,容易把延期问题误判为交付问题。
假设某SEO服务网站的交付包含内容上线、站内链接调整、外部数据接入三部分,外部数据方延期两周。可先验收内容上线和站内链接调整,因为它们不依赖外部数据;外部数据接入单独列为待验收。若内容上线抽查发现部分页面未按约定发布,则先修这一项,再谈外部数据。若内容上线通过,则记录为阶段通过,但明确它不覆盖外部数据恢复后的表现。
这个例子的假设是:内容上线和站内链接调整确实可以脱离外部数据独立检查。如果实际交付中两者必须依赖同一数据源,那么它们也应归入依赖组,不能照搬这个顺序。边界就在这里:拆分验收的依据是依赖关系,不是交付项名称。
第三方恢复后,不要直接把延期期间的旧结论拿来合并。先重跑受影响项,确认恢复后的结果与延期前记录是否一致;若不一致,以恢复后的重跑结果为准。然后检查阶段验收项是否因延期而失效,例如权限变化、数据口径调整、页面被覆盖。只有重跑和复核都完成,才把两组结论合并成最终验收。
这套做法的取舍是:拆分验收能保住内部进度和证据链,但会增加一次合并成本;整体暂停能避免假结论,但会拖慢内部节奏。选择哪一种,取决于延期影响的是局部还是核心依赖,以及已通过项在恢复后是否仍然成立。