Skip to content
Published on

工程师的沟通术：如何让技术决策获得通过

🇰🇷KO🇺🇸EN🇯🇵JA🇨🇳ZH
필사 모드
分享
Authors

引言 — 代码没错，但没人听

只要在这行干得够久，多少都经历过这种事。你明明看清了更好的架构，但会议还是决定走另一条路。几个月后，另一个团队碰巧得出了相似的结论，还被表扬了一番。你心里不是滋味。你明明早就知道。

多数工程师在这里得出了错误的教训——「这是政治问题」。但真正的问题通常更简单，也幸运地可以修正。他们没意识到的是，拥有一个好想法，和让别人采纳这个想法，是完全不同的两种技能。

区分高级工程师和资深工程师的那条线，从来不是写代码的能力。到了那个级别，多数人代码都写得足够好。真正的差别在于让决策获得通过的能力——不只是知道正确答案，而是让组织选择这个答案。本文谈的正是这项技能。它不是一个关于政治的故事，而是一个关于清晰表达的故事。

设计文档与 RFC——为什么书面胜过口头

推动技术决策的最有力工具，既不是幻灯片，也不是会议上一段热情洋溢的发言，而是一篇写得好的文章，通常叫做设计文档（design doc）或 RFC（Request for Comments）。Google 把设计文档当作其工程文化的基石，是有原因的。

书面胜过口头，理由很具体。

  • 文字会被审阅。 会议上口头抛出的提案，容易被现场的气氛和嗓门最大的人左右。文档则让人们各自按自己的节奏冷静阅读，并在空白处留下反驳意见。好想法能扛住这种审视，坏想法会在这个过程中被筛掉。
  • 文字会强制思考。 有些想法在脑子里看起来完美无缺，一旦落成文字就会露出漏洞。「这种情况该怎么处理？」这样的问题，往往是在写作过程中自然浮现出来的。写作这个行为本身就是一种设计。
  • 文字能扩散、能留存。 会议只有在场的人知道。文档却能同样传达给身处不同时区的同事、半年后才加入的新人，以及未来那个想搞清楚决策背景的自己。

一份好的设计文档，通常都有一套共同的骨架。

  标题 / 作者 / 状态（草案·审阅中·已批准·已废弃）/ 日期

  1. 背景与问题 (Context)
     - 现在什么出了问题，为什么。为什么要读这份文档。

  2. 目标与非目标 (Goals / Non-Goals)
     - 要解决什么，明确不解决什么。
     - 非目标是防止讨论跑题的一道围栏。

  3. 提案 (Proposed Design)
     - 核心方案。图示、数据流、关键接口。

  4. 已考虑的备选方案 (Alternatives Considered)
     - 其他选项，以及为什么没有采用它们。

  5. 权衡 / 风险 (Trade-offs / Risks)
     - 这个选择放弃了什么。哪里可能出错。

  6. 上线 / 迁移（可选）

其中大多数人会跳过的两节，其实才是最重要的——已考虑的备选方案和权衡。没有这两节的文档，是一份「请接受我的答案」的主张；有了这两节的文档，则是一份「让我们一起判断」的邀请。审阅者对后者的信任度要高得多。当他们发现自己正要提出的备选方案，早已在文档里被认真考虑并否决时，就会安心下来——「这个人是真的想清楚了」。

先用问题说服，而不是解决方案

工程师最常犯的说服错误，是从自己早已爱上的解决方案说起。「我们把这个换成 Kafka 吧。」这一刻，屋子里一半的人在心里已经站到了对立面——他们还不知道为什么要改，结论就已经被塞了过来。

人在买解决方案之前，会先买问题。把顺序倒过来。

  • 先把问题描绘清楚。「现在订单处理在高峰期出现积压，最近一个月，支付后库存更新平均延迟了 40 秒，期间发生了 217 次超卖。」
  • 到这一步，屋子里的所有人都站到了同一边——没人希望出现超卖。你现在拥有了和你一起看着同一个问题的人。
  • 只有到这时，才把解决方案连同备选方案一起端出来。因为人们已经对问题产生共鸣，此时他们评判解决方案的标准变成了「合不合适」，而不是「敌是友」。

反驳一个解决方案很容易，反驳一个定义清晰的问题却很难。

把这句话反过来想，它就变成了一个诊断工具。如果有人激烈反对你的提案，他们通常不是不喜欢那个解决方案，而是根本不同意这是一个值得解决的问题。这时更卖力地捍卫解决方案是白费力气。你得退一步回到问题本身。「我们现在看的是同一个问题吗？」这句问话，比十次功能对比更能把讨论向前推进。

根据听众调整信息

同一个决定，说给不同的人听，包装方式必须完全不同。最常见的失败，是像对待同事工程师一样，把实现细节一股脑倒给经营层。对方五分钟就失去兴趣，而你则误以为「这个人不懂技术」。

关键在于知道每一类听众真正担心的是什么。

维度经营层 / 领导者同事工程师
最想知道的成本、风险、时间表权衡、实现方式
想要的结论「花多少钱、风险在哪、什么时候完成」「为什么是这个设计、哪里薄弱」
偏好的依据业务影响、机会成本、竞争风险基准测试、失败模式、代码结构
细节程度结论优先、以摘要为主深入，直到给出依据
时间预算短——三句话内说到重点长——已经准备好深入探讨

对经营层，要先说结论。「这次迁移需要 6 周，中途有回滚计划，如果不做，下个季度的流量下会有较大的故障风险。」领导者想要的不是一个优雅的算法，而是决策所需的输入——成本、风险、时间表。他们要用这三样东西，把你的提案和另外十个优先事项放在天平上权衡。

对同事工程师，则反过来，深入分享权衡与实现细节。他们想知道「为什么是 B 而不是 A」「这个设计在并发场景下会怎么崩掉」，你回答得越认真，积累的信任就越多。

讲同一个真相，但用对方能带走的形式递过去——这不是操纵，而是体贴，也是翻译。

明确说出权衡

如果要我举出一个信号，用来区分不成熟的提案和成熟的提案，我会看它是否主动揭示自己的权衡。每一个技术决策都要付出代价，天下没有免费的午餐。可新手的提案往往只列出优点：「这样会更快、更干净、更可扩展。」这种提案反而会招来不信任。经验丰富的审阅者知道，看不见代价，只是说明代价还没被发现。

所以，有分量的提案会先说出自己的弱点。

  • 「这个缓存层能大幅加快读取速度，但会引入一整类新的 bug——缓存失效的复杂性。」
  • 「拆成微服务能让各团队独立部署，但代价是分布式事务和运维复杂度。」
  • 「用这个库能省下两个月，但会把我们绑死在他们的发布节奏上。」

先把代价说出口，会同时带来三件事。第一，赢得信任——「这个人看到了全局」。第二，掌握讨论的主导权——在对方指出弱点、喊出「抓到了」之前，你已经先把这个弱点搬上了台面。第三，提升决策质量——因为整个团队判断的依据，是摆在明面上的代价，而不是被藏起来的代价。

每一个决定都要付出代价。你不主动报价，账单迟早会连本带利地找上门。

异步 vs. 同步——什么时候文档赢，什么时候会议赢

「这个要写成文档，还是约个会？」这个每次都让人犹豫的选择，其实有相当清晰的判断标准。有两条轴：信息的复杂程度，以及意见收敛的程度。

异步（文档、讨论串）胜出的情形：

  • 信息复杂、精确性很重要的时候。架构提案、故障复盘、API 设计——这些都需要人们各自按自己的节奏消化，并精确地提出反驳。
  • 团队跨越多个时区的时候。文档能让讨论继续推进，而不必吵醒正在睡觉的人。
  • 需要留下记录的时候。任何一个决定，只要六个月后可能有人需要回答「当初为什么这么决定」，就属于这一类。

同步（会议、通话）胜出的情形：

  • 意见分歧、情绪也上来了的时候。在讨论串里来回五次都缩小不了的对立，往往一通 15 分钟的电话就能化解。文字很容易放大误解和防御心理。
  • 连问题本身的定义都还模糊的时候。一起摸索到底该解决什么，实时的来回对话，速度远远快过文字。
  • 事情紧急、又牵扯到人际关系的时候。建立信任或修补冲突，需要一张脸（或至少一个声音）。

在实践中，最有效的做法是把两者结合起来。会议前先把文档发出去，让所有人站在同一个语境上（「会前先读」），会议本身则只用来实时收敛文档里已经暴露出来的分歧。而会议上做出的决定，再写回文档里，作为异步记录留存。亚马逊那个著名的做法——在会议开头的 20 分钟里，所有人静默阅读一份六页的叙事文档——正是这种结合：既拿到了文档的精确性，又拿到了会议的即时性。

要提防一种反模式：讨论串里的无休止争论。如果同一个话题下的评论数超过了二十条，而且每个人都在一点点变得更有防御性，那就是「该约个会了」的信号。反过来，把不需要即时回应的事情不断拖进会议，同样是浪费。在别人的日历上预定 30 分钟，永远都得有相应的理由。

不同意但执行（Disagree and Commit）

不管你多会说服人，总会有那么一天，你的方案没有被采纳。也许是数据不够充分，也许是领导看到了你没看到的约束，也许组织只是单纯选了另一个方向。这时候你怎么做，决定了你作为资深工程师的成熟度。

有两种最糟的反应。一种是背地里闹别扭——会议上一言不发，散会后却嘀咕「我早说过这会失败」。另一种是暗中拖后腿——因为心里没真正认同，执行起来也就消极应付。这两种都会侵蚀团队，而且决定性地摧毁别人对你的信任。

比较成熟的做法，是亚马逊奉为原则的「不同意但执行（disagree and commit）」。它的意思是：

  1. 在争论的那一刻，全力反对。 保持沉默不是美德。把你所知道的风险明确、有力地摆到桌面上，是你的责任。这个阶段留一手，反而是失职。
  2. 一旦决定落地，就全力以赴地执行。 组织一旦定了方向，你就要像这本来就是你自己的决定一样，全力冲刺让它成功。不要把心里的疙瘩带进执行过程。

把这两件事分开，是关键所在。「说服的阶段」和「执行的阶段」是不一样的——前者要激烈地提出异议，后者要干脆地全力投入。能做到这一点的人，反而会在下一次赢得更大的信任。没有什么资产，比「这个人反对起来很坚决，但一旦定了就绝不背后捅刀」这样的口碑更值钱了。

补充一点：执行承诺，并不意味着要永远咽下自己是对的这件事。如果这个决定后来确实带来了不好的结果，你完全可以带着数据重新回到桌前。只是那时候的依据，必须是新观察到的事实，而不是「我早就说过」。执行承诺和重新讨论并不矛盾。承诺执行，是承诺不在执行上偷懒，而不是永远闭嘴的誓言。

「强烈主张，虚怀若谷」的陷阱

技术圈有一句流传已久的口号——「强烈主张，虚怀若谷（strong opinions, loosely held）」。它最初是未来学家保罗·萨福（Paul Saffo）提出的一种预测态度：对不确定的未来先立一个强假设，但一有新证据出现就毫不留恋地放弃它。这句话本身是健康的建议。

问题在于，这句话在现实中经常被用反了。实际发生的情况是这样的：

  • 在会议上最有自信、嗓门最大地断言的人，主导了整个房间。只有「强烈主张」这半句被践行了。
  • 而「虚怀若谷」那半句却蒸发了。被反驳时，此人不是改变主意，而是在下一个话题上，同样强硬地断言别的东西。
  • 结果，这句口号变成了把自信包装成证据的执照。实际胜出的不是数据，而是嗓门。

这背后还有一个安静却严重的副作用：屋子里最谨慎的人——通常是那种诚实地说「我不确定」的人，或者还在收集数据的新人——的意见会被自动压制。在一个「说得强硬就等于说得对」的文化里，嗓门大的人的失误，会压过安静的人的洞见。这会慢慢侵蚀团队决策的质量。

那该怎么办？不是要抛弃这句口号，而是要真正践行它。

  • 表达意见时，同时说出你的确信程度。仅仅区分「这个我几乎确定」和「这只是个直觉」，就能改变讨论的质量。
  • 提前说出什么会改变你的想法。「如果基准测试跑出 X，我就收回我的立场。」这一句话，能把「虚怀若谷」从一句口号变成一个实际行动。
  • 而当你真的被反驳时，要看得见地改变主意。当面说出「啊，我漏掉了那一点，你说得对」的资深工程师，是在向团队释放一个强烈的信号——在这里，正确比面子更重要。

拥有强烈主张很廉价。诚实地放下它，才是这句话的全部意义。

结语

让技术决策获得通过的能力，不是天生的口才，而是几个可以习得的习惯的总和：用会被审阅的文字（设计文档、RFC）而不是口头来提案；用问题而不是解决方案，先把人们拉到同一边；给经营层成本、风险和时间表，给同事权衡与实现细节；主动为每个决定的代价命名；根据具体情况在文档和会议之间做选择；在争论落败后干脆地执行承诺；以及把「强烈主张」当作一个诚实的假设来对待，而不是当作自信的执照。

如果要说贯穿这一切的一种态度，那就是对清晰表达负责。重要的不是你知道什么，而是让别人理解它、信任它，并和你一起做决定——那才是资深工程师工作的起点。写出好代码只是一半，让组织一起相信这段代码是对的，是另一半。而通常，后一半更难，也更值钱。

参考资料

Discuss on Twitter • View on GitHub