解读亚马逊的文档文化

神译局是36氪旗下编译团队，关注科技、商业、职场、生活等领域，重点介绍国外的新技术、新观点、新风向。

编者按：众所周知，亚马逊开会的高效沟通是出了名的。这其中主要的原因是他们强调书面沟通的重要性，也就是要过会的人需要提前准备6页纸的文档，把开会要讨论的所有事项以及相关材料都浓缩在里面，而参加会议的人一开始都要先用20分钟阅读文档，然后双方开展质询答辩。在亚马逊工作的Justin Garrison分析了这种文档文化对改进流程的作用。原文发表在其个人博客上，标题是：The Document Culture of Amazon。

划重点：

阅读文档在亚马逊的文化和流程当中已经根深蒂固

提前发邮件通知注意会议其实没什么用，大家平时都很忙

以文档为中心的会议有很多好处，但也存在一些局限

在亚马逊工作期间，我观察到我们对文档的使用方式非常独特。关于六页纸备忘录以及公关/FAQ的文章已经有很多了，所以这里我不会再把注意力放在文档格式上面了，而是会想分享一下我们的流程是怎么从基于文档的会议中受益的。如果你希望自己的公司也采用以文档为基础的开会做法的话，我还帮大家明确了一些需要改进的地方。

其实我想写这篇博客已经有一段时间了，结果最后是Jaana的推文给了我要分享自己想法的动力。

开会前大家先默默地看一下文档，这是有史以来最好的主意了。我不知道为什么这在行业当中并不常见。

— Jaana Doganヤナドガン( @rakyll ) 2021 年 3 月 10 日

我的角色是 AWS Container Services 高级开发人员后援（Sr. Developer Advocate），所以我的经验可能跟亚马逊其他领域和角色有所不同。我参与的大部分会议都是从阅读一份文档开始的。这需要“这次会议本来可以······”并把它颠倒过来。大多数时候，如果没有文档的话，就没有会议。

根据会议的不同，这份文档可以是六页纸备忘录、公关/常见问题解答、一页纸想法、帮助找到问题解决方案的叙述，甚至是充满了图表、图形以及要点的服务点评。这份文档要跟根据会议受众和目的进行调整。

阅读文档在我们的文化和流程当中已经根深蒂固，以至于我们的日程安排工具都有自动创建文档的复选框。如果我要了解新服务或新功能发布的情况，我会找那份文档，而不是看电子邮件或给产品经理打电话。

对我来说，有趣的部分不在于文档的格式，而在于它是怎么用的。会议从阅读开始。根据文档长度的不同，我们会先看十分钟到半小时不等。如果会议的文档很长（最长为 6 页），而且参加者众多，会议会安排足够的时间供大家阅读和讨论。

阅读文档是会议预定时间的一部分。我在很多地方工作过，我曾经试着提前把会议的一切都先记录下来。我写过经过深思熟虑的电子邮件，共享过文档链接，并写过详细的 wiki 页面。除了在亚马逊的会议外，所有的会议我得到的是以下三种结果之一：

• 没人看电子邮件/文档，我被迫在会议上解释一切；

• 倒是有人看了文档但却不记得里面讲了什么了，因为他们是在几天前或几小时前看的；

• 至少有一个人提出了一个我可以通过电子邮件回答的问题。

在我加入亚马逊之前，这些是在会上看东西预期的部分好处之一。

• 会议所有的信息都包含在文档里面了；

• 原本就不指望大家有时间看；

• 文档在每个人的脑海中都是新鲜的。

我在实践中发现还有其他一些好处：

• 演讲者，也包括我自己在内，不必为在大家面前演讲而感到紧张。

• 文档有助于消除很多偏见，不管是支持还是反对写这份文档的人的偏见。

• 你用自己的声音去阅读所有内容，文档不会存在口音、声音障碍或残障（比如口吃或听力损伤）等口头交流障碍。

• 在了解会议的主要内容时，不会出现“你能看到我的屏幕吗”、不会有背景噪音或通话音频中断的情况。

• 当前和过去的文档是一笔宝贵的财富。想了解 Amazon EKS 或 AWS Lambda 的 PR/FAQ 是什么样的？你能找到。

• 并不指望你在会议之外记住文档的信息。反馈和讨论是在会议期间进行的。评论可以用异步的方式回复。如果需要更多的讨论，那文档会进行修订，并安排一次新的会议让大家阅读和讨论。

• 如果会议开始时间跟我日程发生冲突，在提前把提供文档给我的情况下，我可以提前阅读那份文档，然后在10-20 分钟后加入会议也不会错过任何内容。

• 在家中阅读文档正好是进行 10-20 分钟锻炼的好办法。

在会议开始时阅读文档也是进行一些锻炼的好办法！

我正在努力让这个变成一种新习惯。就算是踩10 分钟也足以让我的心率加快。

请别在意那些线🙈

-——Justin Garrison（@ rothgar ），2021 年 1 月 15 日

以文档为基础的会议也存在一些限制。我注意到的第一点是，如果你不是一个很好的作者的话，那在沟通自己想法方面就会处于劣势。亚马逊有很多内部培训可以帮助你写出好的亚马逊文档，但即便有培训，这仍然需要有好的基础。我非常感谢自己多年来给 How-To Geek 和 Cloud Native Infrastructure写东西的实践。但即便有这样的背景，我的第一篇一页纸仍然令人紧张不安。

有人告诉我“如果没有文档，就不算完成。” 这包括会议在内。如果没有文档，我们会取消会议。

虽然文档可以创造一个更公平的竞争环境，但同时也是一个很高的进入门槛。哪怕是很小的想法、功能或迭代，你需要的第一个东西就是就是文档。我的观点可能会有偏差，因为我目前的角色并不写生产服务代码，但我的确会影响服务的功能、设计和定位。我有很多反馈和想法，但实现的不是我。

有大量可用的历史文档可以查阅，这可以给人启迪，但用太多的文档和评论来跟踪服务的沿袭也可能会令人困惑。有时候我看着一份文档觉得它看起来跟某现有的服务很相似，后来直到20 分钟后才意识到这份文件就针对该服务的，而我连文档的日期都没看，或者我也不知道产品代号。

我倒是享受了一个好处，可以跟服务团队合作并就新功能和新服务提供直接反馈。我读到的大部分文件都非常的有趣。亚马逊的很多团队都没有直接的产品输入。但是，他们仍然需要编写文档来跟团队就计划进行沟通。不是说所有的文档都很有趣，但它们对决策过程至关重要。

我曾多次说过，亚马逊有成为一家伟大的远程优先公司的基础。基于文档的流程为跨时区的员工提供了跟西雅图的员工相同的上下文。会议中进行的讨论可以促进更快的反馈循环，但缺点是如果文档没有把备注和问题记录下来的话，会限制异步参与的可能性。

我个人倒没有亲自参加过亚马逊的会议。据我所知，以文档为中心的会议在过渡到远程需求方面非常成功。但内容并不是唯一重要的东西。

跟很多大型组织一样，亚马逊应用了大量工具来进行交流。如果没有交叉搜索或集中组织文档的能力的话，往往很难找到分布在这么多工具当中的文档。我可以看到像 Command E 这样的工具提供了很多的帮助。对于像我这样每周都要用很多的开源和社交平台的人来说，这可能会更加困难。我目前加入了53 个Slack 工作区。💀

就算仍存在可以改进的地方，但我想不出我工作过的地方当中有哪个不能从基于文档的会议中受益。我相信，通过更多的实践之后，我会更加擅长用更为亚马逊的风格写作。

不需要为会议做准备是我非常喜欢的一件事，因为我很有信心文档会为我提供参与会议所需的上下文。我知道，召集会议的人已经投入了自己的时间，所以他们不会浪费我的时间。我则会用我创建的会议以及我写的文档来回报同样的体贴。

译者：boxi