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

> 把每天的等待换算成演示推迟的天数，客气的催促就变成跟踪表、一道减法和一条带选项的消息。

原文: https://fdetimes.net/zh/guides/slow-client-data-access-fde-deadlines/

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

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

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，以及由谁发起变更单。答案能告诉你，这家公司是在给一线工程师授权，还是只是把他们派出去独自等待。

## 本周练习

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

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

**本周动手试试:**

- 为当前项目建立一张登记表，记录每项依赖的负责人、截止日期、受影响的交付物和升级对象。
- 阅读 SOW，或者问负责合同的人，数据和审批的延迟如何处理。
- 在启动会的时间线上为安全评审单独加一个格子，写明客户方由谁负责、通常需要多长时间。

## 信源

- [Client Sandbagging, Data Delays, and Dependency Management](https://umbrex.com/resources/the-consulting-career-guide/client-sandbagging-data-delays-and-dependency-management/)

- [Escalate correctly!](https://www.openproject.org/blog/escalate-correctly/)

- [Alloy.ai | Statement of Work - Alloy.ai](https://alloy.ai/alloy-ai-statement-of-work)

- [Ten mistakes you could be making in your customer implementations](https://rocketlane.com/blogs/ten-mistakes-you-could-be-making-in-your-customer-onboarding-implementations)

- [Your reputation is at stake during implementation kick-off](https://hellobaton.com/article/your-reputation-is-at-stake-during-implementation-kick-off/)