分布式软件团队协作技巧：减少会议，异步优先

作者 | Sumeet Gayathri Moghe

译者 | 平川

策划 | Tina

本文要点

• 在分布式团队中，以会议为中心的工作方式可能会破坏深度工作和流程、包容性、工作灵活性，长期来看还会妨碍知识共享。会议也不适合规模化。异步协作是这种以会议为中心的方法的有效替代方案。
• “异步优先”并不意味着“仅限异步”。也就是说，要充分认识异步沟通和同步沟通模式的优势，并根据需要做出选择。当然，大多数情况下默认采用异步协作方式。
• 要采用异步优先的方法，就必须找到可行的异步协作替代方案，例如用现代化的任务看板代替状态更新会议，或者用可以自行安排观看节奏的视频代替入职培训。
• 对当前团队使用分布式工作实践的成熟度做基线评估，帮助你确定异步协作可以在哪些方面带来改进。
• 为了加速向“异步优先”转变，请务必记录工作流程，简化决策过程，创建团队手册，并进行会议审计。你是在分布式团队中工作吗？如果是，你就会知道，开会是一件非常耗时的事。虽然会议可能有其价值，但如果我们把它们作为默认的工作方式，就可能会在无意中导致团队日历的碎片化。安排被打乱可能会降低生产力，对于需要有时间专注于深度工作的知识工作者来说尤其如此。

在本文中，我们将讨论异步协作的好处及其实现方式。

会议实在是太多

“我们的会议太多了！”作为分布式团队的领导者或成员，你可能经常会听到这样的抱怨。如果你上次听到这个词是在开会的时候，那没什么可奇怪的。大流行增加了我们参加会议的次数，而许多团队一直是采用以会议为中心的协作方法。

设计讨论、状态更新、电话报告、日常站会、计划会议、开发启动、初步验收（desk check）、演示、审核和回顾，平均每个软件开发迭代都包含这样几次“同步”保障。而且，我们的会议还不止这些！

即时交谈、故障排除会议、头脑风暴、问题解决和决策——这些都成为分布式团队的会议。

2021 年至 2022 年期间，我对印度 1800 多名技术人员进行了非正式调查，希望借此了解他们的分布式工作模式。

除其他问题外，那次调查还要求受访者估计他们每周参加多少个小时的会议。此外，该调查还要求人们估计他们每天查看即时消息的次数。我们收到的回复令人震惊。

• 技术人员平均每周要花 14 个小时开会，相当于每年要花 80 天开会。你可能已经猜到，最有经验的技术人员会面临更大的会议负担。
• 根据反馈，人们平均每天要被打断 18 次。罪魁祸首是什么？即时通讯——我们用来“快速响应”的工具。

部分调查结果

本质上讲，软件开发是一个创造性的过程，无论你是在写代码、制作交互还是设计屏幕。领导软件团队也是一种创造性的活动。我们中的许多人会把时间花在构建技术路线图、阐明架构决策、原型设计、设计算法和分析代码上。正如 Paul Graham 在他 2009 年发表的文章中所指出的那样，软件开发是“创客”工作（即创造性工作），它需要“创客时间表”。“你不可能在一个小时内写好程序。这几乎不够工作准备的时间，”Graham 那天说。在创客时间表上，时间“至少要以半天为单位”，而会议和干扰可谓生产力的克星。

不出所料，我在调查中也遇到了这种看法。技术人员希望平均每周深度工作 20 个小时，但实际上只有 11 个小时。想象一下，如果我们能以某种方式找回那些失去的深度工作时间，每个团队能取得多大的成就。

现在我们来看下“异步优先（async-first）”协作。这个概念很简单，就是优先考虑异步协作而不是同步协作。我通过以下三个基本原则来描述它。

1. 会议是最后的依仗而不是最初的选项。
2. 以文字作为分布式团队信息沟通的主要方式。
3. 团队中的每个人都非常习惯沟通中的合理延迟。

如果你对第一项原则感到惊讶，我能理解。在许多组织环境中，会议确实是领导者开展工作的主要工具。不过，对于以下两点，我相信我们可以达成共识。

• 对于团队中的大多数人来说，随时开会可能会导致工作被打断，一天都不安心，甚至效率低下。作为领导者，我们有责任为我们的团队创造一个工作环境，让他们能够体验到心流状态。
• 许多会议之所以效率低下，是因为缺乏准备，缺少记录跟踪，对应参会人员的识别也不够准确。当我们采用“异步优先”方法时，我们也必须能够在需要时为同步交互做好准备。这可以帮助我们思考需要谁参加会议，以及如何将会议结果传达给没有参会的人。

所以，下次你想和同事合作的时候，与其去开会，不如考虑下，一种速度慢一点的异步媒介是否会更有效。你可以使用支持内置讨论区、Wiki、录制视频甚至收发消息和电子邮件的协作文档。

下面我将探讨下，为什么你和你的团队将受益于这种异步优先的思维方式，以及如何在你自己的环境中采用它。

异步优先的六大优势

自从大流行引发的远程工作革命以来，知识工作者现在希望雇主提供灵活的工作地点和时间。尽管有许多雇主要求员工回办公室办公，但可以这样假设，我们本就有一些同事对我们来说永远是远程的。除此之外，即使在经济衰退时期，企业也难以完全填补空缺的技术职位。市场终将回升，在某个时候，科技人才会显得更加稀缺。公司将不得不从其他能够招到人的地方招聘，并使他们融入到自己的团队中。技术团队“默认就将是分布式的”。有鉴于此，“异步优先”协作方法较当前以会议为中心的方法的优势就体现出来了。

在异步优先的文化中，我们偏爱行动。我们会在当下做出最好的决策，记录下来，然后继续前进。重点是把事情做好。如果出了问题，我们会从中吸取教训，进行重构和调整。对行动的偏爱提高了团队做出并记录决策的能力。毕竟，决策是高绩效团队的能量之源。

除了这些好处之外，异步优先文化还能帮助你提高会议效率。当你把会议当作最后的手段时，你所参加的会议就是你所需要的。你找回了自己的时间和注意力，并让那些少数的、目的明确的会议对每个参加的人都有用。

异步优先并非仅限异步

采用异步优先并不意味着同步交互没有价值。异步和同步协作之间的良好平衡会使团队受益。在分布式团队中，这种平衡应该偏向于异步，以免每个人的日历上都有一年 80 天的会议。话虽如此，你也不能忽视同步协作的价值。

书面沟通的速度慢，你有足够的时间深思熟虑。你可以独自写一些东西，并分享给你的同事，而不必打电话。它还能让你达到在快节奏实时对话中无法达到的深度。你写的所有内容都可以在将来重用和引用。这就是异步沟通非常有效的原因。让我们看几个例子。

1. 想象一下，架构师记录使用新库的提案并用文字从各个维度（例如集成计划、测试、验证、风险和替代方案）进行了描述。这可以在短时间内帮助整个团队和业务利益相关者参与进来。
2. 当团队成员在他们的工作流程中记录项目时，通过诸如会议纪要、架构决策记录、提交消息、拉取请求、创意论文或设计文档等，他们就构建了项目团队的集体记忆。这有助于你追溯项目，解释项目是如何到达当前状态的。
3. 上面的每个例子都可以从团队成员和领导者的协作中受益。例如，当领导者提议使用新库时，团队成员可以在 Wiki 页面上发表评论，分享关注点、想法、反馈和建议。使用类似的方式，初级团队成员可以创建拉取请求来触发代码审查，而团队领导者必须在审查拉取请求时提供有用的反馈。如此一来，书面沟通就成了一种协作实践。另一方面，同步沟通可以帮助你解决紧急问题。这就需要借助实时消息或视频会议了。不过，并非所有的活动都是紧急的。将同步工作模式应用于非紧急活动，通常要付出工作流中断的“代价”。这就是为什么我们必须在同步和异步之间进行平衡！

同样，当你必须在短时间内处理许多话题时，或者当你想要获得自发的、未经过滤的反应和想法时，你就会希望采用同步方式。你肯定也会同意，大多数人都希望与同事建立一些“人类”的联系，特别是在远程和分布式团队中。这也是同步沟通的优势所在。

异步 vs 同步沟通——价值平衡

所以请记住——“异步优先”并非“仅限异步”。要根据需要对团队的协作模式进行权衡取舍。为正确的目的选择合适的模式。

采用异步优先的障碍

异步优先的概念看似简单。少见面，多书面，接受延迟——咒语很简单。然而，我发现许多团队在采用这种方法时都遇到了困难。这有几方面的原因。

• 每个人都认同的协作模式才会起作用。那样才会产生“网络效应”。如果一些人以异步优先的方式工作，而其余的人以会议为中心的方式工作，你就不太可能获得你想要的好处。
• 团队已经习惯了许多在日历上重复出现的同步做法——例如站会、私下商议、电话报告和计划。如果不仔细考虑，很难用异步过程取代这些惯常的做法，同时仍然保留其价值。
• 协作模式的任何变革都会导致一段时间的迷惑与混乱。在此期间，团队在看到任何好处之前会首先看到生产力的下降。没有为这种生产力下降做好计划的团队可能在得到好处之前就放弃了变革。因此，任何新的工作方式想要持续下去，首先需要业务部门和团队的支持。然后，还必须一次又一次地实践，确保你在引入新的做事方式时不会失去任何价值。异步优先协作也是如此。

工作方式的成功变革需要什么

和你的团队一起开启“异步优先”

假设业务部门和团队都看到了会议太多的问题，那么你应该已经从这些利益相关者那里得到了一些支持。为了对你关注的领域划分个优先级，我建议你对团队做个调查，看看他们最看重那六个好处中的哪一个。

反思团队当前协作实践的状态是为异步优先做准备的一个好方法。我建议问下面这四组问题。

• 你在工作过程中创建工件时有多勤奋、多仔细？例如，决策记录、提交消息、自述文件和拉取请求。在异步优先文化中，这样的工件是基础。
• 你对自己主持的会议纪律要求有多严格？想想那些预先设定好的议程、指定的主持人、时间盒和会议记录。人们是否可以心安理得地拒绝那些他们不会增加或获得价值的会议？会议规模是否通常很小，8 人或更少？有效的会议是有效的异步优先工作方式的一个附带效果。
• 你有多少时间可以用于深度工作？你每天想要多少时间？团队想要的时间和已经得到的时间之间有多大的差距？
• 让一个人加入你的团队有多容易？一个人在访问了你的系统后，第一次提交需要多少时间？入职流程是对工作方式记录是否完善的一个测试。上述问题将帮助你为团队的分布式工作实践成熟度建立一条基线。它还将帮助你确定你可以有针对性的进行改进的领域，以实现向异步优先方式的转变。我建议使用一个调查工具来评估这个基线，因为那样比较简单，而且……嗯…异步！

将调查结果发布给团队，并突出显示差距，以便每个人都能清楚地了解差距在哪。这样一来，你就可以清楚地了解为什么使用异步优先，以及希望获得什么好处。

基本转变

根据我的经验，每个团队向异步优先工作方式的转变过程都不一样。实际上，在完成我所推荐的基线活动后，团队通常会选择不同的领域利用异步协作进行改进。我建议每个团队都做一些基本的转变。

定义工作流程

在工作中，我们都认可“自组织团队”和“自主权”的重要性。然而，正如 Cal Newport 在其著作《没有电子邮件的世界》中所说，知识工作是“工作执行”和“工作流程”的结合。虽然每个人对自己的工作执行都应该有自主权，但团队必须明确定义他们的工作流程，而不是让人去猜测。例如，请看下图，这是我当前所在的团队采用的双轨开发方法。它阐述了每个人的责任，以及工作如何在我们团队的系统中流转。我们还设置了团队任务板来贯彻这个工作流程。

定义工作流程，避免异步优先团队中出现混乱

当你以这种方式记录开发过程时，它会减少由于不知道谁该做什么或下一步该做什么而需要召开的会议。对于团队的新成员，它也是一份现成的参考。你不需要开会向新同事解释开发过程。一次编写，多次运行！

把决策推到最底层

团队做出的每一项决策往往都需要召开会议。这种协调不仅是有成本的，而且还会导致数次工作中断。这也会导致团队不愿意承担风险。首先，与团队一起定义项目上下文中不可逆决策的类别。这样的类别很少，不要为此感到惊讶。持续交付实践已经非常成熟，几乎所有的软件决策都是可逆的，除了那些具有财务、遵从性或监管影响的决策。只有这些决策需要共识式决策。其他可逆决策可以采用更轻量级的方法。

例如，每当有人想要决定某件事并希望寻求其他人的意见时，他们可以写下决策记录并邀请其它人进行评论。如果这个决策是可逆的，而且又没有什么顾虑，他们就会按照可行的建议行事。你甚至可以按照特性或能力线，将大型团队组织成两到三个人的短期小型团队，如下图所示。每个小团队都有一个直接负责人（DRI），对团队决策负责。DRI 的地位应该和团队中的其他人对等，他应该是“同侪之首”（FaE）。这种组织方式有三个明显的特点。

1. 个体仍然可以采用异步决策技术，但当存在意见分歧时，DRI 可以发挥决定性作用；
2. 缩小了沟通范围，尤其是当你需要开会的时候。小团队对它正在构建的东西有自己的决定权。他们做出决策，然后在一个所有其他小团队都能看到的地方分享决策记录。
3. 为了促进知识共享，增加团队弹性，人员仍然可以在不同的小团队之间轮转。这样可以提高决策的自主性，同时还可以帮助团队成员熟悉整个代码库。

将大型团队组织成小团队，缩小决策范围

创建团队手册

高质量的文档是异步协作的催化剂。每个软件团队都应该有一个地方来存储团队的知识和文档，包括决策记录、报告、说明书、设计文档、建议等。我称之为“团队手册”。如果你的团队已经使用了一些广泛应用的工具，则可以使用它们来实现这个目的，如 Confluence、GitLab、SharePoint、Notion、Almanac、Mediawiki 等。

花一些时间和你的团队一起规划手册的初始结构，通过组织轻量级的谷仓建造活动创建第一个版本。自此之后，团队就有了自己的手册，就像他们拥有代码库一样。随着团队需求的变化对团队手册进行改进和结构调整。

团队手册示例

减少会议数量

已经在一起工作过一段时间的团队通常会积累很多固定程序和承诺。在分布式团队中，这些承诺以会议的形式出现在团队日历上。对于团队来说，每个冲刺要预留 10 个小时的会议，这种情况很常见。为了采用异步优先，就要精简团队的会议列表，只保留必要的会议，这是有帮助的。我使用一个我称之为“ConveRel 象限”的框架来帮助团队确定哪些会议是必要的，哪些会议可以用异步沟通代替。

其框架是一个标准的 2x2 矩阵。X 轴代表沟通的性质。右边是“传达（conveyance）”，一个例子是单向信息传递。左侧是“汇聚（convergence）”，一个例子是在一个研讨会上做出一个高风险的决策。

Y 轴表示参与沟通的人之间的关系强弱。上半部分表示强关系，下半部分表示弱关系。

你可以将团队会议绘制到这个矩阵的象限中，以确定当采用异步优先时它们将如何变化。

• 如果你只是想把信息传达给与你关系密切的人，那就不要开会。相反，通过共享文档或维基页面，或通过发送电子邮件或消息，只要使信息可以通过网络访问即可。这事再简单不过了。大多数状态更新和报告电话都属于这个象限。
• 如果你们的关系很弱，那么你就可能需要一些互动来建立这种关系。传递信息可以是建立友情的一种手段。当关系变强后，再用异步交互代替这些交互。
• 如果你们的关系很弱，而你又希望在一个决定上达成一致，我建议你默认采用会议的方式。
• 最后，如果你们的关系很牢固，并且希望在一个决定上达成一致，那么你们应该异步收集所有的输入，会议之外做能做的事情就在会议之外做，只在最后一步时才聚在一起。

ConveRel 象限

使用 ConveRel 象限进行简单的会议审计，不仅可以帮助你确定可以用异步流程替换的会议，还可以帮助你改进你选择保留的会议。

有了这些基本的转变，你就可以做一些最大的改进，从而帮助你异步开展工作。现在，你可以与团队一起评估你通过临时视频会议进行的每一项实践，并找出异步替代方案。这需要时间，所以每个开发周期都要做一两个改进，然后看看进展如何。

小 结

异步优先协作可以帮助你的分布式团队变得更高效、更包容、更周到、更有趣。不过，这不是一夜之间可以完成的。我们中的许多人都默认采用了同步工作方式，因为它模仿了疫情前我们所处的办公室文化。据我们了解，那会让团队日历上满是会议！

如果你希望帮助你的团队更多地采用异步工作方式，那么你不仅必须获得他们的支持，还必须获得业务部门的支持，这样你才能获得变革所需的空间。作为变革过程的一部分，检查团队的协作过程，并确保找到可行的异步替代方案。这样做的目的不仅是减少中断，而且要保留同步方式给团队带来的价值。

在指导这种转变时，要注意反思。评估团队分布式工作成熟度的基线活动将帮助你标记起点。从这一点来看，受你影响所进行的每一项变革都应该有助于推动团队实现它所寻求的利益。首先与你的团队合作，记录你的工作流程，简化决策过程，创建团队手册，并进行会议审计。这些初始工作可以奠定一个不错的基础，让你可以针对每个协作过程进行其他比较小的迭代改进。

原文链接：

https://www.infoq.com/articles/asynchronous-collaboration-software-teams

声明：本文由 InfoQ 翻译，未经许可禁止转载。