客户迟迟不开权限？把等待变成发起人的决策

项目进入第二周。你有了笔记本电脑、门禁卡和一间借来的会议室，唯独没有客户系统的账号。申请已经提交了三次，工单状态仍是“等待安全团队”，而面向高管团队的演示日期没有任何人调整过。

遇到这种情况，人们往往有两种本能反应：再发一封客气的催促邮件，或者憋着气干等。两种做法都会让项目时间悄悄流失，却不需要任何人做任何决定。摆脱这种处境是一项需要练习的技能，就像调试一样。

Umbrex 的咨询手册建议，把客户的反复拖延当作项目依赖风险，而不是个人的烦恼，从被动等待转向主动的依赖管理。要做到这一点，需要三样东西：一张跟踪表、一道减法和一条带选项的消息。

延迟要写进计划

把时间倒回启动会，那时开头那一幕还没有发生。时间线投在屏幕上，项目发起人和安全、IT 部门的人都在场，还没有谁在任何事情上拖延。这是谈论延迟最容易的时刻，因为没有人需要被追责。

指向时间线上一个具体的格子：集成方案的安全评审。这是一个典型的障碍，Rocketlane 就提醒过，单是一个部门就可能让项目耽误好几周。然后问：“你们这边由谁负责这件事，通常需要多长时间？”

得到的答案是一个名字和一个天数，两者都直接写进时间线。这也是 Baton 的建议：从一开始就把客户方常见的障碍纳入计划。一个没有接收人的提醒，不会让任何人采取行动。

如果合同里也写着同样的内容，客户会更重视你在启动会上说的话。所以在启动会之前，先读工作说明书（SOW），再看数据表结构。Alloy.ai 的 SOW 就是一个清楚的例子：所有时间线都取决于能否及时获得数据访问权限，延迟可能导致通过变更单延长项目。

客户不回应时，这份文件还赋予实施方暂停集成、调走人员的权利。你需要先弄清自己的合同里有没有类似机制，才能谈升级。

一个假设项目的逐日推演

假设项目是为一家保险公司开发一个对理赔案件进行分类的智能体。启动会是 N1，演示定在第 20 个工作日，记为 N20。拿到真实系统的读取权限后，你估计需要 10 天开发，再加 3 天让业务团队验收结果。

计算只需要一行：20 减 13 等于 7。访问权限最晚必须在 N7 到位；如果评审完成后开通账号需要 2 天，那么安全团队最晚要在 N5 批准。这正是客气的催促永远告诉不了你的：每项依赖真正的截止日期。

Umbrex 建议为每项依赖记录负责人、截止日期、受影响的交付物和升级对象。套用到这个假设项目上（人名同样是假设的），登记表如下：

依赖项	客户方负责人	截止日期	受影响的交付物	升级对象
集成方案的安全评审	Lan，安全负责人	N5	所有基于真实数据的工作	项目发起人
只读账号	Minh，IT 管理员	N7	第一版开发	IT 负责人
用于评测的 12 个月理赔数据导出	Ha，数据工程师	N12	演示用的评测集	数据负责人

最重要的一列是负责人：每个格子写的都是一个具体的人，而不是“客户方”或某个笼统的职位。如果某个格子里填不出人名，你就找到了项目的第一个风险。

到了 N6，评审还没完成

现在是 N6，N5 的截止日期已经过了。在给发起人写信之前，你先问 Lan：“评审卡在哪里？我们这边还缺什么吗？”Umbrex 把这个问题视为升级前的一步，因为好奇的态度能让对方少一些防御心理，也能暴露真正阻碍项目的原因。

Lan 回复说材料已经齐全，但评审委员会要到 N10 才开会。所以原因在于会议日程，而不是申请写得含糊，再发一次催促或重写申请都无济于事。账号最早 N12 才能到位，比截止日期晚 5 天；12 加 13，完整演示要到 N25。

Umbrex 强调，有效的升级是帮助客户选择方向，而不只是告诉对方你很着急。所以发给发起人的消息应该这样写：

N20 的演示有风险：账号要到 N12 才能到位，晚了 5 天，原因是安全委员会 N10 才开会。

已与 Lan 确认：申请材料齐全，唯一的阻碍是会议日期。

A. 保持 N20，缩小范围：用匿名化导出数据做演示，前提是安全团队同意，且导出数据最晚在 N7 到位。

B. 保持完整范围，演示推迟到 N25。

C. 由您请安全团队在 N7 安排一次专门评审：账号 N9 到位，N22 做完整范围的演示。

请在 N6 结束前做出选择。

决策截止日期定在 N6，是因为方案 A 和 C 都取决于 N7。按方案 A，只有导出数据在 N7 当天到位，13 天的工作才刚好赶上 N20；方案 C 则需要当天就开评审会。拖到第二天，就只剩方案 B 了。

这条消息不指责任何人，也没有形容词。OpenProject 的升级指南把这称为决策模板：书面发出，尽早发出，写明原因和选项。

发起人未必知道是安全团队拖住了项目，但他们能打一个你打不了的电话。

无论选了哪个方案，都要把决定记进登记表，并发一封确认邮件。如果 SOW 中有类似 Alloy.ai 的条款，而工期确实要延长，你这边负责合同的人需要尽早知道，以便及时处理，而不是等到为时已晚才发现。

应用到项目中的六个步骤

第一步是启动会：直接说明通常会在哪里慢下来，并要求每项依赖都有一个负责人。

第二步是建立登记表。一张定期复查的电子表格就足以起步。

第三步是从交付物倒推，得出真正的截止日期，而不是凭感觉定日期。

第四步是升级之前先问清为什么延迟。申请含糊就需要重写，写清具体的表、具体的权限和理由；负责人工作过载，就需要发起人调整优先级。这两种原因需要不同的解法，笼统的催促哪一种也解决不了。

第五步用在真正的截止日期已经守不住的时候：用上面那样的多选项消息升级，每个选项都有日期和范围。

第六步是在等待期间继续做所有不需要访问权限的工作：写测试，用合成数据搭建数据管道，并打听谁手里已经有一份获准使用的数据副本。

让项目一直卡住的错误

不要等截止日期过去很久才升级，因为到那时你已经拿不出代价小的选项给发起人。也不要用错误的方式升级，比如把一串邮件直接转给某人的上级，却不附上后果和选项。这样做会失去一个盟友，而发起人仍然不知道该怎么办。

更危险的错误是自己找变通办法，比如借用一位友善员工的账号，或者通过私人渠道索要文件。你省下了几天，却把与正在评审你的安全团队之间的全部信任押了上去。最后一个错误是默默加班把时间补回来，这样客户永远看不到延迟的真实代价。

求职时如何展示这项技能

不要只在简历上写“沟通能力强”，这句话无法让读者看到你做了什么。用你自己的真实数字，描述你发现了哪项依赖、算出了多少天的风险、提供了哪些选项，以及最后的结果。

到了面试阶段，问一问前线部署工程师（FDE）能否阅读 SOW，以及由谁发起变更单。答案能告诉你，这家公司是在给一线工程师授权，还是只是把他们派出去独自等待。

本周练习

挑一件你正在等待客户或公司内其他团队提供的东西。从交付物倒推，找出真正的截止日期，问负责人工作卡在哪里，然后按上面的模板写一条三选项消息，每个选项都有日期和范围。如果你连第二个选项都写不出来，说明你对自己的项目还了解得不够。

下一次工单状态还是“等待安全团队”时，你的工作不再是等待，而是算清还剩多少天，以及谁需要知道这个数字。