书面交流是远程工作的超级力量

远程工作环境与办公室不同。不同的环境需要不同的通信系统。适应远程工作现实的通信系统可以带来惊人的好处：(甚至)更高的生产力，长期的竞争优势，以及更好的工作与生活平衡。

异步书面通信是最适合远程工作的工具。我们非常习惯在办公室里相互交谈，在工作聊天中期待立即得到回应，整天开会，以至于我们试图在家里通过放大和松弛来复制这一点。

在等待即时回复的同时懒洋洋地互相写信，或者每天安排多个缩放会议，从长远来看，远程工作都会失败。

在Unspash上使用Sack或Microsoft Teams等同步聊天方式拍摄的照片不像与坐在你旁边的队友交谈：它更难发起。当你身边有队友的时候，仅仅交谈要比打字提问容易得多。这会导致快速而简单的事情被拖得太久，因为队友会首先尝试自己解决它。

发起这件事太容易了。当是来自不同部门的人时，在办公室里，他通常会先和自己的队友核实一下。但现在，直接找到源头也同样容易。所以你会收到垃圾邮件。

每个人都希望立即得到回应。这只是聊天而已。它的设计是为了给我们一种紧迫感。即使不是很紧急的时候。

你会失去你的历史。即使你在聊天中花时间向某人解释公司的概念，它也不会以一种有组织的或可发现的方式保存在任何地方。它将丢失在聊天日志中。很快，你就会发现自己又在解释同样的事情了。

它提倡保密。人们天生害羞，不愿向其他队友展示自己的弱点。因此，他们会将问题和最新信息大多保存在私人聊天或私人房间中。

视频会议也有问题：一次只能有一个人发言。在现实中，不只是一个人可以说话，每个人都能理解。这是一个软件限制。

不要边说边说。实际上，在大型会议中，你可能会对会议中的一群人低声说些什么。你不能在视频会议中这样做。

这一切都让视频会议给人的感觉更像是一场讲座。真正的讨论更难促成(尽管并非不可能)。

视频通话很累人。摄像机聚焦在你的脸上，每个人都一直在看着你。你不能走神或走神让你的大脑休息一下。

即使我们抛弃了聊天和视频通话的具体工具，我们仍然存在同步通信的潜在问题。也就是说，希望其他参与者在非常有限的时间跨度内做出响应的交流。

当预计每个人都在任何时候都有空时，打断别人并立即得到答案的成本比自己寻找答案的成本要低。无论是在第三方文档中，还是在公司的内部文档中。

也就是说，如果内部文档甚至存在的话。当每个人都希望被问到事情的时候，为什么要努力恰当地记录任何事情呢？

计划是另一个罪魁祸首。大多数人不会提前对他们的任务进行适当的深入计划。他们更喜欢定义最终目标，并在过程中发现问题和细节。他们知道他们永远不会陷入困境，人们会准时回答他们的问题。

这在组织中形成了一种中断文化。它自我滋养得如此之深，以至于这个组织不可能真正不受干扰地运转。因为整个组织都依赖于此，所以它成为文化的一部分。一旦你有了打断的文化，即使是世界上最好的沟通者也无法改变它。

工作时间的灵活性也会被打破。因为每个人都依赖于每个人都能在工作日内被打扰，所以你有一个工作日。

你的工作日时间必须与其他所有人保持同步。因此，您放弃了实际工作时间灵活性的能力。

在家里工作，梦想着中午去接你的孩子，和他们一起出去玩，然后晚些时候回去工作？忘了它吧。你很快就会被困在某件事上，没有人会在那里支持你。更不用说你会让你的同事陷入困境，因为你不会在下午回答他们的问题。

真正的遥控器也是不可能的。当你需要每个人同时都有空的时候，你不可能现实地把来自美国、欧洲和印度的团队成员放在一起。

异步写作与聊天消息不同。它寿命更长，瞄准更多的潜在受众，而且很容易被发现。

为了活得更久，文本需要意识到更大的读者群体背景。聊天室通常只考虑一两个读者，这些读者具有理解你谈话内容的背景，而长寿的文本应该考虑整个潜在的读者群体。现在，以及未来的某个时候。

为了文本寿命更长，目标受众更广，它需要假设较少的预先存在的读者上下文。聊天消息在特定时间以一/两个读者为目标。因此，他们假设这些读者拥有对他们来说明确的当前上下文。

异步写作不假定特定的人上下文，也不假定当前事件知识。令人惊讶的是，这并不一定会使文本变得更长或更难写。

例如，我们假设团队中有一个数据库问题，在此场景中，MySQL实例偶尔会因为内存不足错误而失败。仅为您的团队编写，他们知道现在的问题是什么，以及它是什么数据库。其他人可能不知道哪个DB有问题(假设您也在某个地方使用MongoDB)，他们不知道问题是什么。

对于不会持续很长时间的聊天上下文而言，一条足够的消息可能是：我今天将修复数据库。异步文本等价物将在系统中记录问题，将其标记为今天正在处理，文本为"；MySQL Out Out Memory Issue"；(今天的文本为"；MySQL Out Out Memory Issue"；)。

这篇文章不长，但它包含了任何局外人可能需要了解的所有背景，而不需要联系任何人询问我们在什么数据库上有问题？问题是什么？我们从什么时候开始知道它的？谁在上面？等等。

可发现性是该通信系统的下一个重要部分。你需要让将来可能需要你的作品的每个人都能很容易地找到你的作品。

依赖全文搜索通常不是一个好主意。你需要有适当的组织体系。任务描述放在哪里？系统设计文档放在哪里？他们都住在一个地方还是每个项目？或者可能是大型组织中的每个部门？

每家公司都有某种系统，通常也是以他们的知识共享为指导的。不管是吉拉，大本营，星期一还是别的什么地方。您只需确保系统的一致性和紧密性，以便项目中的新人能够自我发现他们需要的一切。

这里也以MySQL问题为例，让我们假设一个新的团队成员得到了这项任务。该任务使用标记"；数据库"；、"；基础设施"；进行标记。他可以跟随数据库标签查找最近完成的任务，看看是否有明显的可疑之处。

他没有发现，所以他决定检查一下是不是有数据分析师做了什么诡异的事情。他转到数据分析团队的任务列表，找到了新的仪表板标签(Tag"；new Dashboard&34；)。这些看起来是一个很好的线索，他发现在问题开始的当天就完成了一个新的仪表盘任务。

现在他需要查看这个仪表板，但它使用的是他不熟悉的可视化系统。他前往数据团队维基，在那里他找到了一份关于我们如何使用可视化系统的文档。他设置了他的凭据并进入查看查询。

你知道我要做什么了吧。当一切都很容易访问和明显时，您可以专注于任务本身，而不会中断流程。

想象一下这样一种场景，在每一步中，你都必须停下来问某人：来自数据基础设施的雷蒙：嘿，我们如何使用可视化工具编辑仪表盘？

在这种情况下，您依赖于其他人可用并记住所有答案。在你得到答案之前，你的流程经常被打断，没有任何进展的途径。你不能把注意力集中在弹性工作时间上，因为你必须让所有的团队成员随时待命。

在这篇文章中，我描述了为什么在我看来，像我们在办公室所做的那样，同步通信不是远程通信的最佳选择。然后，我演示了如何通过编写进行异步通信来修复大多数同步通信的罪魁祸首。

同步通信虽然远程依赖于聊天和视频通话，但它们都是试图模仿办公室对话的次要通信工具。但事实并非如此。

同步通信既累人，又重复，而且剥夺了远程工作的大部分好处(如弹性工作时间、从世界各地招聘等)。

异步通信允许无中断地自我发现：无需上下文切换即可进入深度聚焦会话，从而提高工作效率。

异步通信更好地保存了公司知识：教程和指南不断完善，因此人们不会在同一件事上浪费时间两次。

你有一个地方可以通过写作获得知识，而不是在私人电话或聊天室中很快就会丢失的私人知识