异步沟通：高效团队的秘诀
今天看到一篇文章：Asynchronous Communication: The Secret to Productive Teamwork，作者 Amir Salihefendic 是 Doist 的创始人和 CEO，发表在团队博客 Ambition & Balance 上。原文网址是：https://doist.com/blog/asynchronous-communication/。
我摘录一些重点进行翻译（引用格式的部分），并且夹带一些私货（括号内的点评 & 非引用格式的部分）。数字分节是我加的。
01 开篇
文章开头写道
- 多个研究表明远程工作比集中在办公室的效率高。
- 效率高的可能原因多种多样，包括省去了高峰时期的通勤时间、避开了办公室的种种干扰（卿培：可能大多指的是无效会议和走过来拍肩膀问问题）、重获对时间的掌控感、有更多的时间可以分配给亲友及爱好（卿培：由此获得了焦虑感的下降、士气的提升，以及降低工作时间段来自这些方面的干扰）。
- 但是，除了通勤时间的变化之外，作者认为其他因素不是直接原因，而是异步沟通（asynchronous communication）的副产品。异步沟通令员工能主动决定何时和队友沟通，而非被动接受打断。
- 作者由此提出，尽管他认为远程工作是未来趋势及主流，但异步沟通对团队生产率的提升很大，不管是否远程团队，都应提倡异步沟通。
随后给出了异步沟通的定义
异步沟通指的是你发出一个消息，并不期待立即得到反馈的沟通方式。
例如你发一封邮件给我，我几小时后才打开，阅读并回复。
作为对比，同步沟通的定义
同步沟通是指你发出一个消息，接收方立即处理这个信息，并马上回复。
面对面的沟通，比如会议，就是典型的完全同步沟通。
IM 聊天可能是同步的，也可能是异步的。配合手机的通知功能，app 会提示新消息，点开即回。甚至雅虎实验室在 2015 年的一个研究（卿培：分析对象是200 万用户，在几个月研究周期内的 160 亿封电子邮件）发现，最常见的邮件回复时间是仅仅 2 分钟（卿培：具体数字是，90%一天内，50%在 47 分钟内，最高频的回复延迟是 2 分钟）。
02 同步沟通的问题
强调同步沟通的工作状态
HBR 文章 Collaborative Overload [1] 写道，过去 20 年间，职员们用于协作的时间增加了 50%。一天当中耗费超过 80%的时间用于和同事沟通的情况并不罕见，平均 6 小时在处理电子邮件，另 15%的时间在开会，Slack 用户（卿培：选它应该是主要用于工作，私人的聊天很少听说用 Slack 的）平均每天发 200 条消息。
大部分知识工作者面临的局面是，要在一天当中参与多个会议，会议之间的时间才能做自己的工作，其间还要留意并处理电子邮件和 IM 软件上的消息。
Slack 宣传自家 app 用户平均每工作日连线超过 9 小时，活跃使用超过 90 分钟。活跃时间和在线时间的比例就已经反映了一个碎片化的分布。
这样的状态带来的问题，作者总结如下
🛎频繁打断，于是妨碍了深度工作的开展。
🗣在线的优先级优于高产。不在线的人连发声机会都没有，事情就已经决定了。于是大家都得被迫实时在线，被迫参加每个可能有关的会议。
😰造成不必要的压力。实时在线的期望使人们丧失对时间表的控制。工作时间内，大家响应式（reactively）回应各方请求，而不是主动地（proactively）按自己的计划行事。有研究[2]表明，因为常被打断，人们反而会努力把事情做得更快（卿培：以写得更少，做得更差为代价），并由此感到更大的压力和困惑。
😣导致低质量的讨论和次优方案。因为需要马上回复，人们没有充分的时间来考虑周全。第一时间给出的方案往往不是你能给出的最优方案。
03 异步沟通的收益
大多数人接受了干扰和打断是工作的一部分，但是有些公司，例如 Doist，GitLab[3]，Zapier[4]，Automattic[5] 和 Buffer[6]，拥抱了更加异步的方法来协作。（卿培：后面四家对协作方式的描述见文末链接。） 让员工掌控何时在线和沟通的核心收益有：
⏰能够掌控工作日=更开心和高产的员工
🤔高质量的沟通而不是不假思索的回复（卿培：学到一个词，knee-jerk response，膝跳反应式的回复，表示不经大脑就有反应了，形象！）
💆♀️更好的规划可以得到更低的压力水平，于是最终能得到更高质量的产出。
🔍深度工作成为默认的工作方式。可以开辟整段的时间来工作，每天集中处理1-3 次消息和会议。
📝自发的文档和更高的透明度。因为大多数的沟通都以书面方式进行，重要的讨论和关键信息很自然地就文档化了，尤其是当这些讨论是在一个公共平台（卿培：作者公司用 Twist，GitLab 用 GitLab Issues 和 Google Docs）进行而非电子邮件往来的话。事后分享和参考这些信息都更方便。例如下图这样的月报，其他人很容易顺着链接进入具体问题看进展和参与讨论。（卿培：看到这里我产生冲动想把月报从企业微信移到 GitLab Issue 进行，毕竟大家主要的工作和输出在那里。图中这样的月报也并非超出了大家的能力范围，意愿所及，都是可能。）
🌏时区平等。跨时区的沟通更顺畅。没有人会因为时差而处在信息劣势，而这也使得公司的招聘池子不再局限于某个时区。
更高的员工留存率（卿培：这条作者没加粗，我也不加粗。）过去五年，大多数 Doist 员工都留了下来，每年留存率超过 90%，高于行业水平。哪怕 Google 这样的企业，提供了各种福利，员工在职时间中位数也仅为 1.1 年[7]（卿培：看了详表[8]，还有Amazon 1.0 年，Apple 2 年，没找到其他大互联网企业的数据。对比一下通用汽车的 10.3 年，施乐的 7.2 年，AT&T 的 7.1 年，AIG 5 年，可口可乐 3.8 年，Oracle 3.2 年，星巴克 2.8 年，很显著了。当然，还有 IBM 这样的奇葩，6.4 年，所以IBM到底是什么行业的🤔）。而获得这样留存度的原因是随处工作的自由。（卿培：这里我只看到了作者的想法，没看到任何定性、定量的分析。毕竟这群一茬一茬换人的互联网新贵也有不少是允许甚至集体组织 work from home 的。只是没有如此激进地除了聚会和少数活动，默认天天 work from home 而已。也许这就是关键？谁知道呢。不是任性老板，谁有条件做这个对比实验啊。）
04 需要同步沟通的场景
纯异步的沟通没有人情味。还是有些场景需要同步沟通，或者同步沟通效果更佳。
Doist 市场部的头，Brenna认为这个异步沟通的文化少了些人性的味道，想念面对面的交流。另一位 Roman 也建议在一部分场合应当采取同步沟通的方式。
经验教训是应当采取混合的沟通方法，在一些场合，例如一对一面谈，团建时使用同步沟通。（卿培：我注意到图里两个“of course！”出现在了作者举例中，而其它三行并没有。这是否意味着作者仍认为代码审核、复杂技术问题的讨论、救火时该采取异步方式？或是这个选择没有定论？）
后文总结了同步沟通的场景清单
希望融洽关系，例如一对一面谈
提供关键的反馈或者讨论敏感话题（卿培：没举例，晋升、加薪和 PIP 显然在此之列）
有很多未知，需要头脑风暴
有很多变量需要一起让所有人拉齐，例如项目启动会
危机应对，例如服务器崩了
总之，作者认为
同步沟通应当是例外，而非规则。
05 Doist 的沟通
Doist 用如下方式来帮助建立人与人之间的关系。
📅 每个人每月与直属上级有至少一次一对一的谈话。
🗣 尝试用 Zoom 面对面视频进行一些无关工作的闲聊。
🗺 年度聚会。
✈️ 新成员飞到 mentor 所在地一起工作一周。
💼 报销同事约在外面一起工作的场地费用。
现在 Doist 不同沟通方式占比是
🔀 70% 异步，用 Twist、Github 和 (Dropbox) Paper
📞 25% 同步，用 Zoom、Appear.in 和 Google Meet
🏝 5% 物理上在一起，例如年会和聚会
06 如何建立异步沟通的文化
从同步转为异步不可能一蹴而就。这个转变需要一系列工具、流程、习惯和文化的重大转变。有些具体的工作有助于这一点。作为团队成员或者是团队领导，都有一些可行的建议。
作为团队成员，可以：
💬过度沟通。发消息时尽可能提供充分的信息。用截图或录屏来把问题可视化。清晰地描述你需要对方做什么，什么时间完成。多花几分钟时间增加信息和编辑文字，在异步沟通的环境下能省却几天的往复确认。
⏳ 尽早规划，留时间给他人考虑。例如“我希望 2 天后完成这个工作，希望你能提供些建议。”而不是“请在一小时内回复。”
📄 始终检查文档共享设置。如果应该能读到文档的人需要申请访问权限，可能会有几小时甚至一天的等待。
👈 会议开始前就发起一个会话或文档。共享会议香港信息，讨论关键问题。这样参会者在会议开始前就能知道议题的情况。（卿培：这点我想某照明控制软件项目的周会，项目经理每次的会议邀请已经把议题清晰列出，和文中的差距只是因工具的局限，无法将议题的背景信息和相关讨论以链接的形式方便地附上。这个在将来可以尝试用 GitLab Issues 或 Wiki 的形式来改善。）
👉 会后将讨论和结论文档化。让没有参会的人可以找到这些信息。我们甚至实验录制会议视频，让其他人可以异步“参会”。（卿培：想到 Ray Dalio 一直介绍桥水的所有会议都有录音，录音会有专人整理成文本。每个人的会议发言都会在事后被检验，影响ta 的 credibility 值，并因此影响 ta 的一票对集体决定的影响力。如果发言被记录，被存档，会议上必然会少很多无关讨论和未经思考的废话。当然，这也会阻止一些灵感被说出来。不过总的来讲，正确的事情太多了，做不过来的，仅仅少做傻事就可以比很多人、很多公司成功了。）
🔕 关闭推送通知。仅在特定时间段检查和回复邮件、信息。
🤔 高效使用等待时间。（异步沟通的更长的）等待回复的时间并不是什么大问题，总有其他需要你做的工作可以在这段时间进行。
作为团队领导，可以：
✍ 将写作和沟通作为核心技能来提倡掌握。这可以减少沟通中的反复，让人可以更快地触及问题核心。异步工作环境下的每个人都需要长于写作。
👏 基于产出和结果评价他人。而不是基于 ta 响应有多迅速或是工作多少小时。我们在另一篇文章写过如何测量员工生产力[9]。
⏱摈弃稳定工作时间以及出现在办公室的要求。这让你可以从世界各地招募人才，而且天然地驱动整个组织按异步沟通的方式运作，因为拍肩膀发起谈话不再可能了。
🤝 强调信任、组织、独立和担当。没有这些价值观的话，异步沟通不可能成功。例如 Doist 的核心价值观中有一条，其他人可以信任你会按时交付，团队成员们无需担心你会食言。Brenna 详细写过远程异步工作的环境里如何建立信任[10]。
👩⚖️ 采取单人直接负责制[11]的管理和决策模型。这个 Apple 发扬光大的方法是指，对每一个领域，每一个项目，都有单一个体负责。这个人不亲自做所有事，而是组织团队做事，做关键决策，对进度和结果负总体责任。越是减少参与具体决策的人数，分散权威（authority），加大对个人的授权（卿培：对 accountability 的不错解释是 the liability created for the use of authority），团队就越高效。
⌛️ 设定团队范围内合理的可接受的响应时间要求。Doist 期望大家在 24 小时内应答。
📄 优先考虑透明度。例如，在 Doist 的所有人都可以看到所有的核心讨论，不管是不是团队一员。高透明度使得人们可以更高效工作的原因是当 ta 需要信息时，ta 不必去向他人索取，而可以自行搜索到。（卿培：在以往的工作中我遇到过这样的情况，我感到某个流程不畅，但不知道怎么改进它。一段时间之后在闲聊中得知，其实系统有 xx 功能或者 xx 接口，只是不对工具运维团队和管理员之外的人开放，“如果你需要，可以提出来去申请啊。” 我只想说，我都不知道有某个权限的存在，我怎么去申请该权限…… 我的权限和小道消息来源算多的了，我根本无从得知其他人在工作中遇到了多少类似的障碍，而这常常没法通过询问得到答案。因为他们不知道自己遇到的不便是流程或系统设计如此，还是通过一些流程外的人工申请，本可以更美好一些。）
🛠 使用有助于透明、深度工作和异步沟通的工具。例如 GitHub pull request、Basecamp 对话、Twist 会话。**不要用电子邮件。**尽管电子邮件可以异步沟通，但是它将信息锁在了人们的收件箱里，其他人无从获知。当人们无法得到所需信息，协作就必然更加低效。[12]
🚨 对紧急事件建立单独的沟通渠道。Doist 建了个 Telegram 聊天室。（卿培：前文提到，机器人发现故障会在这里通知。并且只要求对 Telegram 开启推送通知。）我们也有所有人的电话号码。这些渠道一年大概用上几回。绝大多数的情况都没有紧急到需要立即得到响应。
07 异步沟通是个对现状的艰难挑战
我们知道我们在挑战现状，异步沟通并不是当下的主流。需要进行范式转变，改变事情的运作方式。
我们在赌未来未来成功的公司和团队是那些完成范式转变的。那些不需要员工实时在线、首选异步沟通，从而给员工的深度工作和充电创造空间的团队将获得成功。我们很兴奋地分享我们在这条路上的努力，并且邀请您来一同探索。（卿培：公关真是无处不在。）
更多建设异步沟通文化的内容可以阅读 Twist 远程工作指南——The Art of Async[13]。
08 我的想法
我看了开头，就打开了我们团队的员工手册里关于沟通的那一页[14]。
第一句我们就写了首选异步沟通。为什么？因为这段是从 GitLab 员工手册抄的🙃
这段文字从 2018 年产生至今，始终挂了个 WIP（work in progress）。是我不够关注沟通问题吗？还是这其中需要解决的种种障碍持续缺少变革的土壤？
我想原因有二，一是人员水平的下限有差异，二是文中讲的范式转换是个艰难的过程。
第一个原因，关于人的水平下限。
作者说团队核心价值观有一个假设是，别人不必为你的承诺担心，你不会食言，你会说到做到，按时交付。这个假设可真的太强了，很少有组织敢对全员做这个假设。最近广泛宣传的，可能是 Netflix 的只招成年人吧。假如我对不同沟通方式下，员工素质和团队生产率这两个变量的关系作图，我想可能是这样的——
当人员水平下限不足时，同步沟通能确保一个可接受的生产率，异步沟通则失灵。
当人员水平逐渐上升，两种沟通方式都可以获得更高的生产率。但异步沟通的生产率提高，对于高级脑力工作者而言更加明显。
当水平高过某一个基准后，同步沟通成为生产率继续攀升的制约因素，而异步沟通因为解放了个体的深度工作可能性，并不会频繁打断工作或是分散注意力，安分地充当一种工具而不是限制。
第二个原因，是渐变过程。
过去两年，在异步沟通的问题上，我们试过 Slack（有墙不方便），试过 Microsoft Teams（不配合 Office、OneDrive 的话和其他方案没有优势），试过把会议纪要以 GitLab Wiki 的形式组织，试过坚果云、Google Drive（有墙不方便）共享项目文件。我们看到的结果是有更多的信息从邮件转向 GitLab Issues，渐渐开始有发版本的把关从邮件移到 Merge Request，有更多的协议文档从邮件附件的 doc、pdf 变成仓库里易搜索、易 diff、易引用的 md，其中一些图片的制作，从 visio 变成了 mermaid。
这个过程中，我们只能掌握自己发起的沟通在哪里进行，却很难对沟通的其他参与者提更多的要求。例如，尽管我们希望用户反馈通过 GitLab API 提成 Issues，和测试团队报上来的问题同样处理，但近一年下来仍难如愿。这样做的好处显而易见：转测试复现方便，@一下就行，对问题的修复或者功能的实现相关的 commit 也能很方便地 mention 这个 issue id。但是这样看问题立刻能知道为啥推不动变革：益处都是自己的，别人只觉得多一事，当然不如少一事。反观那些成功安利的系统，典型的是 Redmine，无需什么广告、培训，只要对某个人群自身有益处，很自然地就会采纳。
异步沟通在一个大环境里，也是相似的。不要试图剧变，或是看不清路线就止步观望，而是观察自身、自己团队所处的局面，找到一个可以行得通的妥协的路，让事情发生，以摸着石头过河。
组织内部，沟通问题是所有问题的替罪羊。但是如何宏观地评价沟通有效性，如何去解决沟通过程中的具体问题，短期看没什么万灵药，长期看不解决必疲于奔命，是个管理当中核心的问题。领导人和管理事，很大一部分就是管理信息流通，这是个技术活，也是个艺术活。
References:
1. https://hbr.org/2016/01/collaborative-overload
2. https://www.ics.uci.edu/~gmark/chi08-mark.pdf
3. The Remote Manifesto, https://about.gitlab.com/blog/2015/04/08/the-remote-manifesto/
4. How to Build Culture in a Remote Team - The Ultimate Guide to Remote Work, https://zapier.com/learn/remote-work/how-build-culture-remote-team/
5. How we Communicate at Automattic, https://watirmelon.blog/2016/07/22/how-we-communicate-at-automattic/
6. The Nomad City 19 Chats- Marcus Wermuth, https://www.nomadcity.org/the-nomad-city-19-chats-marcus-wermuth/
7. The Real Problem With Tech Professionals: High Turnover, https://www.forbes.com/sites/forbesbusinessdevelopmentcouncil/2018/06/29/the-real-problem-with-tech-professionals-high-turnover/#52aba9ef4201
8. Full List of Employee Tenure at Fortune 500 Companies, https://www.payscale.com/data-packages/employee-loyalty/full-list
9. The Do’s and Don’ts of Measuring Employee Productivity in the Knowledge Economy, https://doist.com/blog/measure-improve-employee-productivity/
10. How to Build Trust in the Remote “Workplace”, https://doist.com/blog/trust-remote-workplace/
11. How Well Does Apple’s Directly Responsible Individual (DRI) Model Work In Practice?, https://www.forbes.com/sites/quora/2012/10/02/how-well-does-apples-directly-responsible-individual-dri-model-work-in-practice/#1ea2c5dc194c
12. Twist vs. Email: The More Organized Way to Work – Twist Help, https://get.twist.help/hc/en-us/articles/115003654589
13. The Art of Async: The Remote Guide to Team Communication, https://twist.com/remote-work-guides/remote-team-communication
14. 沟通・软件研究所员工手册，https://handbook.sansi.io/guidelines/communication.html↩