亚马逊的文档文化 (2021)
2021年3月15日
亚马逊的文档文化
发布于 2021年3月15日 • 6 分钟 • 1257 字
我在 Amazon 工作期间，观察到我们使用文档的方式非常独特。关于 six-pager 和 PR/FAQ 的文章已经有很多了，所以我不会重点介绍文档格式，但我想分享一下我们的流程是如何从基于文档的会议中受益的。如果您希望为您的工作场所采用基于文档的会议，我也发现了一些需要改进的地方。
我一直想写这篇博文，Jaana 的推文终于给了我分享想法的灵感。
我的职位是 AWS Container Services 的 Sr. Developer Advocate，所以我的经验可能与其他领域和 Amazon 的其他职位有所不同。我的大多数会议都以阅读文档开始。这颠覆了“这个会议本来可以……”的说法。大多数时候，如果没有文档，就不会有会议。
根据会议的不同，文档可以是 six-pager、PR/FAQ、关于某个想法的 one-pager、帮助找到问题解决方案的叙述，甚至是包含图表和要点的服务审查。文档会根据会议的受众和目的进行调整。
阅读文档已经深深地融入了我们的文化和流程中，以至于我们的日程安排工具都有复选框来自动创建文档。如果我要了解一项新的服务或功能发布，我会查找文档，而不是通过电子邮件或电话联系产品经理。
对我来说，有趣的部分不在于文档的格式，而在于它的使用方式。会议从阅读开始。根据文档的长度，我们阅读的时间从 10 分钟到半小时不等。如果会议有一个很长的文档（six-pagers 是最长的）并且有很多与会者，会议将会安排足够的时间来阅读和讨论。
阅读文档是安排好的时间的一部分。我曾在很多地方工作过，我尝试提前为会议记录下所有内容。我写过经过深思熟虑的电子邮件，分享过文档链接，并且编写了详细的 wiki 页面。在我所有 Amazon 之外的会议中，我遇到了以下三种结果之一：
- 没有人阅读电子邮件/文档，我不得不在会议上解释所有内容
- 有些人阅读了文档，但忘记了它说了什么，因为他们是在几天或几小时前阅读的
- 至少有一个人有一个问题，我本可以通过电子邮件回答
在我开始在 Amazon 工作之前，这些是对会议中阅读的一些预期好处。
- 会议的所有信息都包含在文档中
- 不希望人们自己花时间阅读
- 文档在每个人的脑海中都是新鲜的
我在实践中发现的其他一些好处是：
- 演示者，包括我自己，不必对在人们面前演示感到紧张。
- 文档有助于消除许多对撰写文档的人的偏见，无论是支持还是反对。
- 你用自己的声音阅读所有内容，并且文档中不存在诸如口音、声音抽搐或残疾（例如口吃或听力丧失）等声音交流障碍。
- 在理解会议的主要内容时，不会出现“你能看到我的屏幕吗”、背景噪音或通话音频断开的情况。
- 有大量的当前和过去的文档。想看看 Amazon EKS 或 AWS Lambda 的 PR/FAQ 是什么样的吗？它存在。
- 不希望你在会议之外保留文档信息。反馈和讨论发生在会议期间。评论可以异步回答。如果需要更多讨论，那么文档将被修改，并且将安排一个新的会议来阅读和讨论它。
- 如果提前提供了文档，并且我在会议开始时有冲突，我可以提前阅读文档并在会议开始后 10-20 分钟加入会议，而不会错过任何内容。
- 在家阅读文档一直是获得 10-20 分钟锻炼的好方法。
基于文档的会议有一些局限性。我注意到的第一个是，如果你的写作水平不是很好，那么你在沟通你的想法时会处于劣势。Amazon 有很多内部培训来帮助你编写好的 Amazon 文档，但即使经过培训，它仍然需要一个良好的基础。我非常感谢我多年来为 How-To Geek 和 _Cloud Native Infrastructure _ 写作的实践。即使有这样的背景，我的第一次 one-pager 审查仍然令人生畏。
我被告知“如果没有文档，什么都做不成。” 这包括会议。如果没有文档，我们会取消会议。
虽然文档可以创建一个更公平的竞争环境，但它也是一个很高的准入门槛。即使对于小的想法、功能或迭代，你可能需要的第一件事就是文档。我的观点可能有些偏差，因为在我目前的职位上，我不编写生产服务代码，但我确实会影响服务的功能、设计和定位。我有很多反馈和想法，但我没有实施它们。
阅读大量的历史文档可以令人大开眼界，但也很容易混淆，因为大量的文档和评论会让人难以追踪服务的谱系。我不止一次发现自己正在阅读一份我认为听起来与现有服务相似的文档，但 20 分钟后才意识到该文档_就是_针对该服务的，并且我没有查看文档的日期，或者我不知道产品的代号。
我有幸与服务团队合作，并提供有关新功能和服务的直接反馈。我阅读的大多数文档都非常有趣。Amazon 的许多团队没有直接的产品投入。但是，他们仍然需要编写文档来与他们的团队沟通计划。并非所有文档都很有趣，但它们对于决策过程至关重要。
我已经多次说过，Amazon 拥有成为一家出色的 remote-first 公司的基础。基于文档的流程为位于多个时区的员工提供了与西雅图的员工相同的背景信息。会议中的讨论能够实现更快的反馈循环，但缺点是，如果笔记和问题没有记录在文档中，那么它们可能会限制异步参与的潜力。
我从来没有参加过 Amazon 的现场会议。据我所知，以文档为中心的会议在过渡到远程需求方面非常成功。但内容并不是唯一重要的东西。
像许多大型组织一样，Amazon 使用很多工具进行沟通。在没有交叉搜索或集中组织能力的情况下，通常很难在如此多的工具中找到分散的文档。我可以看到像 Command E 这样的工具可以提供很大的帮助。这在使用我每周参与的众多开源和社交平台时会更加困难。我目前在 53 个 Slack 工作区中拥有一个用户。💀
即使存在一些需要改进的地方，我也想不出一个我工作过的地方不会从基于文档的会议中受益。我相信通过更多的实践，我会更好地用更 Amazonian 的风格写作。
我非常喜欢不必为会议做准备，因为我确信文档会给我参与所需的背景信息。我知道召集会议的人投入了他们的时间，所以他们不会浪费我的时间。我用我创建的会议和我写的文档来回报同样的周到。
感谢所有审查过本文档的人。☺️ 横幅图片来源 pixbay