先给结论:生产权限被卡住时,不要停掉整个项目,而要把交付拆成一条不依赖生产权限的支线,用可验证的中间产物换取后续权限。下面用一个假设情境,把这条支线怎么排、排到什么程度、什么条件下必须回头要权限讲清楚。
假设一家怀化本地企业委托外部IT团队做一套内部订单处理系统。开发环境、测试数据、需求文档都已经对齐,但上线前企业方以安全审查未完成为由,不开放生产服务器、数据库和发布流水线的操作权限。团队已经催过两次,对方回复“再等等”,项目却还有验收节点。
这时要区分三种卡点,因为处理方式完全不同:
判断属于哪一种,最直接的动作是向对接人问一句:“如果这周开不了权限,你们内部谁能在生产环境执行命令?” 如果对方能立刻说出人名,说明是流程问题;如果说不出,说明是制度问题,交付方案要整体改向。
在权限未开放期间,可执行的交付物包括:
这条支线的价值不在于“看起来在干活”,而在于它把后续权限需求变成了具体请求。当团队拿着回滚手册和校验脚本再去要权限时,谈的就不是“给我们生产访问”,而是“请让运维执行这两个脚本并把输出发回”。请求范围缩小,审批阻力通常随之下降。
常规做法失效时,最容易犯的错是把所有沉默都当成拖延,然后不断加码催促。可以用一组可观察的证据来区分:
如果是隐性拒绝,继续等待只会消耗排期。此时应主动提出替代方案:由企业方人员操作,外部团队远程旁听或事后核对日志。这个动作的结果会直接决定下一步——对方接受,说明合作可以继续;对方仍不安排人,就要把交付范围正式缩到不涉及生产环境的文档与脚本,并在验收条款里写明生产上线不在本次范围。
更稳妥的安排是从一开始就把生产权限设为独立里程碑,而不是默认它会在开发完成后自动到位。假设项目总周期为若干周,可以在合同中把交付分成两段:文档与脚本交付为第一段,生产环境执行与验证为第二段,第二段的启动条件写明“企业方指定执行人并完成一次脚本试运行”。
这样做的实际影响是:第一段结束时,即使权限仍未开放,也有可验收的成果,团队不必空等;第二段启动时,权限问题已经转化为一个明确的执行动作,而不是模糊的审批状态。对怀化本地企业来说,这种分段的另一个好处是内部审批压力变小——需要批的不再是“开放生产权限”,而是“安排一个人跑一次脚本”。
不是所有情况都适合继续推进支线。出现以下任一条件,应当暂停并重新确认合作范围:
这几种情况下,继续做文档和脚本只会积累无法验证的成果。此时应把已完成部分整理成交接材料,明确哪些已验证、哪些待验证,再决定是调整交付范围还是更换执行方式。判断依据始终是同一个:下一步动作是否有人能执行、执行结果是否能被观察到。能满足,就继续;不能满足,就先解决执行人问题,而不是继续加文档。