客户的 DBA 不欠你什么，先弄清对方看重什么

设想部署进入第二周。代码已经就绪，数据读取权限却还躺在一位数据库管理员（DBA）的待办队列里。这个人不向你汇报，也不向你的上级汇报。你无权下命令，再发一次催办提醒，大概也改变不了什么。

Influence Without Authority 并不是专为前线部署工程师（FDE）写的，但很少有书能这样贴近这种处境。出版方 Wiley 称它是一本经典指南，教人从不受自己控制的人那里得到所需。

对 FDE 来说，这是每天的工作，而不是可以以后再练的软技能。你的项目依赖组织之外的人，这本书给了你一套看待他们的具体思路。

两位作者，为更扁平的世界而写

Allan R. Cohen 是 Babson College 全球领导力杰出教授（Distinguished Professor of Global Leadership）。David L. Bradford 是 Stanford Graduate School of Business 组织行为学荣休高级讲师，曾主持该院的领导力高管项目（Executive Program in Leadership）。

第三版于 2017 年出版。Wiley 把这本书放在这样的背景下：组织越来越扁平，越来越依赖外部承包商，要拿到结果，就得以平级身份协作，而且常常要跨越国界、时区和组织边界。

这句话几乎就是在描述一位驻扎在客户现场的 FDE。这一版的发布公告也明确说，这套模型适用于影响同事、上级或客户。

第一个观点：别先问“谁能逼他就范？”

书中的流程有六步，第一步是假定每个人都可能成为盟友。这听起来像一句客气的建议，却会彻底改变你接下来的做法。

如果把 DBA 当成障碍，本能反应就是升级给项目发起人。权限也许能拿到，但下周回复你的，仍然是这位 DBA。如果把 DBA 当成潜在盟友，问题就变成：这个人想把什么事做好？

升级有时仍然必要，但应该是最后的手段，前提是你真正弄懂了对方需要什么。

第二个观点：货币属于接收方

全书的核心是交换模型：回报对方有价值的东西，换取你需要的东西。对方看重的东西就是对方的“货币”，用 Wiley 的话说，这是赢得对方配合的直接工具。

回到那张卡住的工单。“给我生产环境的读取权限，好让数据管道跑起来”，这个请求只讲了你的需要。假设一起喝了杯咖啡之后，你得知这位 DBA 最怕的是半夜被叫醒，因为某条奇怪的查询拖慢了系统。

这时提议就完全不同了：用只读副本而不是主库，并发查询限制在 5 个以内，避开高峰时段运行，这些查询触发的告警由你自己接，权限 30 天后自动过期。你照样能读到数据，DBA 也得到了真正需要的东西：睡个好觉。

再把同样的提议发给安全负责人试试。假设这个人看重的是能对审计人员有个交代，那么查询限制就意义不大，需要补上的是专用账号、访问日志和一份批准读取的表清单。

所以在客户现场，第一步不是起草请求，而是问对方一周里最让他头疼的是什么，听完答案再写你的提议。

第三个观点：有来有往贯穿整个项目

这套模型建立在社会科学家所说的互惠法则（Law of Reciprocity）之上。在六步流程中，识别货币只是第四步，后面还有两项任务：维护你和对方的关系，然后通过有来有往的交换来说服对方。

这个顺序值得留意，因为货币不是一次性的技巧。一位曾经帮 DBA 修好一个老是失败的备份脚本的 FDE，到第六周申请权限时，就不必从零开始。

这里有个 FDE 需要警惕的陷阱：别用不属于你的货币付账。拿产品路线图上的功能去换权限，今天的工作是推进了，债却落到了产品团队头上。只提供你自己兑现得了的东西。

选哪个版本，怎么读？

这本书适合正在做 FDE、或即将从软件工程师（SWE）转岗的工程师，在原来的岗位上，话语权一向来自代码写得对。多年主导跨职能项目的人可能会觉得内容眼熟，不过拿它当一套术语来带队友，仍然有用。

选第三版。第二版也是 Wiley 出的，但新版补充了案例，并加入了远程团队、地理分散团队的内容。如果你要和其他时区的客户合作，单凭这一点就够了。

读法只需记住一点：按作者的顺序走完六个步骤，边读边拿一张卡住的工单来试。读到第一步时，写下手握这张工单的那个人的名字，先把他当作潜在盟友，再往下读。

读到第四步，停下来写下这个人的货币。最后两步讲关系和有来有往，正好直接用上这个答案。如果读完全书，你连一封邮件都没改过，那就等于没读。

对职业发展而言，这项能力只有拿得出证据才有价值。看职位描述时，留意那些关于与利益相关方合作、或在没有直接管理权的情况下产生影响的条目。在简历上，把“沟通能力强”换成一句具体的话：你向哪个团队提出了什么方案，打通了部署中的哪一步。

为面试中关于客户冲突的问题准备好这个故事。下次工单又没了动静，先别发第四次催办提醒，问问自己：另一端的那个人花的是哪种货币？