企业不开放生产权限时,交付不应停摆,而应改为“离线生产、受控验证、分步上线”。先把权限缺口拆成内容、数据、代码三类,再决定哪些工作能独立完成,哪些必须由企业侧执行。核心判断标准只有一条:如果交付物无法在本地或隔离环境中被验证,就不能算完成,只能算待验证。
很多团队把权限问题笼统归结为“客户不配合”,实际上它至少分三种:只读权限缺失、写入权限缺失、发布权限缺失。三者对应完全不同的交付安排。
判断属于哪一种,最直接的动作是:让对方提供一份当前账号能做什么、不能做什么的简短说明,而不是反复追问“能不能给权限”。这份说明决定后续是继续开发,还是转入交接模式。
假设你手上有一份企业提供的产品介绍文档,目标是做成一个可上线的页面,但对方不提供服务器和后台权限。可执行的处理顺序如下:
这个动作的结果是:交付从“等你给权限”变成“你按说明操作”。如果企业连上传都不做,那么后续沟通的重点就不是技术问题,而是确认项目是否继续。
没有生产权限,有一类验证无法由外部完成:真实域名下的访问、真实数据下的展示、真实账号下的提交。这些必须由企业侧执行。可执行的安排是提供一份最小验证清单,让对方只做必要动作:
清单越短,对方执行的概率越高。如果验证清单超过五步,通常说明交付物本身还没有收敛到可交接状态。
不是所有权限缺失都要硬扛。出现以下情况时,应改变安排:
关键区分点是:企业是否愿意承担最后一步操作。愿意,则交付可以继续;不愿意,则交付边界必须收窄。这个判断直接影响报价、工期和验收标准,应在动手前确认,而不是做到一半再回头谈。
无论属于哪种权限情况,最终都应落到一份交接单上。它不需要复杂,但必须包含:已完成的文件清单、需要企业替换的具体内容、需要企业执行的验证步骤、以及完成这些步骤后如何反馈。交接单的作用不是免责,而是让“可执行”有明确的落点。如果对方连交接单都不愿确认,那么问题已经不在权限,而在项目本身是否具备继续推进的条件。