怀化网络服务：交付物可以验收但不能被使用时怎样界定缺口
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /34f94ac6c901.html
📄
怀化网络服务：交付物可以验收但不能被使用时怎样界定缺口
先给结论：验收单上打了勾，不等于交付物能被业务使用。缺口的界定标准不是“文件是否齐全”，而是“接收方能否在不依赖交付方的情况下完成一次真实操作”。如果一次真实操作走不通，就要把缺口拆成三类——可用性缺口、可维护性缺口、可迁移性缺口——再决定是保留、要求改写还是退出。
为什么“验收通过”和“能用”会同时成立
验收通常按清单逐项核对：页面存在、链接可点、后台能登录、文档已提交。这些项目都能通过，是因为它们检查的是“有没有”，而不是“能不能独立跑通”。一个常见情形是：交付方在自己电脑上演示一切正常，接收方换一台机器、换一个账号、换一个网络环境，流程就断了。
这种反常结果不是验收造假，而是验收口径和交付口径不一致。验收口径问的是“东西在不在”，交付口径问的是“换个人能不能用”。两者都成立，缺口就藏在中间。
用一次真实操作区分三类缺口
与其争论“算不算交付完成”，不如让接收方独立做一次真实操作，记录卡在哪一步。
- 可用性缺口：操作能启动，但中途必须由交付方远程介入才能继续。比如后台配置只有交付方知道，接收方找不到入口。
- 可维护性缺口：操作能完成一次，但第二次遇到同类问题无法自行处理。比如修改一段内容需要改代码，而接收方没有对应权限或说明。
- 可迁移性缺口：操作在当前环境能跑，换服务器、换域名或换账号后就失效。比如依赖交付方持有的某个账号或密钥。
这三类缺口的处理方式不同，混在一起谈只会变成互相指责。
保留、改写还是退出：各自成立的前提
保留适用于缺口集中在可用性层面，且交付方愿意补齐操作说明和权限。前提是核心结构没有绑死在交付方手里，补文档和补权限就能让接收方独立操作。
要求改写适用于可维护性缺口。前提是双方对“接收方能自行维护”有可核对的验收动作，例如接收方在交付方不介入的情况下完成一次内容更新或配置调整。如果改写范围涉及架构调整，需要重新约定交付边界，而不是在原验收单上追加。
退出适用于可迁移性缺口无法通过补文档解决。判断依据是：接收方能否在不依赖交付方任何账号、密钥或人工协助的前提下，把交付物迁移到自己的环境。如果答案是否定的，且交付方不承诺解绑，继续投入只会加深依赖。
一个假设例子：三种解释如何区分
假设某次交付后，接收方发现后台无法登录。这至少有三种解释：账号密码给错了（可用性缺口）、权限没有移交（可维护性缺口）、后台依赖交付方服务器（可迁移性缺口）。
区分方法不是问交付方“到底行不行”，而是让接收方用自己的账号、在自己的网络环境下尝试登录，并记录失败提示。如果提示是密码错误，属于第一类，补发凭证即可。如果提示是无权限，属于第二类，需要移交权限并验证。如果提示是服务不可达，属于第三类，需要确认服务归属，再决定是否退出。
实际动作：把这次独立操作的结果写成一份简短记录，注明时间、环境、操作步骤和失败提示。这份记录的作用不是追责，而是决定下一步谈补文档、谈改写还是谈退出。没有这份记录，讨论会停留在“我觉得不能用”和“我这边没问题”之间。
把缺口写进下一次验收动作
要避免同类问题，验收清单里至少要有一次由接收方独立完成的操作，且交付方不在场。操作对象应是业务真实需要的功能，而不是演示用的样例数据。操作完成后，接收方应能说清楚：我做了什么、结果是什么、如果出问题我找谁、下次我自己能不能再做一次。
如果这四个问题里有任何一个答不上来，验收就不应标记为完成。此时缺口的界定标准已经清楚：不是东西有没有交，而是接收方能不能独立用。
