从前车马很慢，书信很远，一生只够爱一人。我相信大多数人在提笔写信的时候措辞一定比发微信要更审慎，产出的文字质量也更高。这也许隐藏了一些关于沟通效率的秘密。
摘要
同步的沟通手段在面对指数增长的复杂度时注定会失败，顺畅的异步沟通配合工具链才是大规模软件工程项目在协同开发领域得以成功的关键因素之一。
人脑的弱点
不论多模牛逼的技术和工具，配合怎样强力的项目管理意志，那些熠熠生辉的闪光思想最终也只能通过项目中一个一个的普通人落地。但很多项目管理的思路在处理人与人沟通的方式时，确往往忽略了普通人心智负担的上限。这并非人们有意忽视，也许仅仅是我们的神经科学的科技点的却是太慢。
关于人脑的多线程能力究竟有多发达，神经科学目前并无定论，但大家普遍认可的结论是：信息接受和处理是多线程，但是意识是单通道的。举个例子，就如同双耳分听实验，你的双耳收听不同的材料，同一时间你只能听到一种材料。但是另一只耳听到的材料并不会完全过滤掉，当其中包含重要的信息，就会通过前额叶的调节，让你意识到另一只耳中听到的材料。
从辩证唯物主义的角度解释，大脑进化出这样的意识模式，大抵是因为人、哺乳动物甚至脊椎动物在漫长的生物演化历史中对于意识本身的并发性能需求不高，而并发意识（精神分裂？）的代价或者说成本又过于昂贵，以至于通过ATP储能的碳基生物不太可能在地球这个需要大量异构算力环境中发展出真正的并发意识。
需要人一边打电话一边开车的进化场景应该还不超过10年？
从某种意义上讲，我们的大脑不是GPU而是CPU，而且不是RISC指令集而是CISC指令集。
意识的并发度上限令人捉急，意识的切换开销更令人捉急。由于缓存特别是易于存取的高速缓存十分有限，大多数人甚至不能同时做到与他人全双工的聊天，只能一个请求一个响应同步交流，尽量避免大量沟通中的状态占用有限的缓存空间。事实上，大多数人发出请求等待响应的时候，会本能的避免切换上下文，陷入真正的“傻等”or“摸鱼”状态。
沟通的效率黑洞
说到底，在与人沟通这件事情上，生理层面的缺陷限制了我们的并发能力，人类生来就不可能在一次又一次的请求与响应的上下文切换中应对自如。而复杂的分布式系统会让上述过程在眨眼间碎片化，BOOM! 显然，项目推进一段时间后（或者项目的复杂度增长到一定程度后），每个参与者需要维持的沟通链接越来越多，耗费在切换的时间也越来越多，用于思考和coding的时间越来越少。
表现在领导眼中，就是队伍越来越大，出活反而越来越慢，质量还不断下滑。
简单来说，效率黑洞主要源自四方面的原因：
- 频繁打断，于是妨碍了深度工作的开展。
- 在线的优先级优于高产。不在线的人连发声机会都没有，事情就已经决定了。于是大家都得被迫实时在线，被迫参加每个可能有关的会议。
- 造成不必要的压力。实时在线的期望使人们丧失对时间表的控制。工作时间内，大家响应式（reactively）回应各方请求，而不是主动地（proactively）按自己的计划行事。有研究表明，因为常被打断，人们反而会努力把事情做得更快（以写得更少，做得更差为代价），并由此感到更大的压力和困惑。
- 导致低质量的讨论和次优方案。因为需要马上回复，人们没有充分的时间来考虑周全。第一时间给出的方案往往不是你能给出的最优方案。
几乎所有的项目管理工具都试图通过一系列紧密啮合的工具链来改变这一现状，而其核心思想就是将说话这件简单的事情通过文字记录成日志，将沟通异步化。
异步化的例子
在实践异步沟通前，有必要明确异步的语义。
对编程来说，异步有一个非常清晰的定义：当我们要执行一项比较耗时的操作时，不等待操作结束，而是给这个操作一个命令：“当操作完成后，接下来去执行什么。”一个通用的范式是用kafka把请求和响应负载到不同的topic上，在响应中增加对应的请求id,发请求的线程专注于发送请求，处理响应的线程专注于处理响应。如果还能有一套高效的手段让发送请求和处理响应都无状态化（一个简单粗暴的实现方式是把状态全部丢到请求的消息体里，让服务提供方附加在响应消息体中扔回来），则两个线程的性能都可以起飞，甚至可以完全部署在不同的节点上。
对于说话这件事情来说，一个简单的类比就是：有啥想说的，一口气想清楚，然后说完，不等对方反馈，也不依赖对方反馈。这看似对提问者并不友好，因为很多问题是在讨论中逐步提出的，而异步的沟通方式会拖慢单个问题的节奏，暂时降低了效率，但异步的方式会强迫大家留下沟通的日志，如果辅以工具，这些日志会成为后来人的宝贵资产，在整个项目生命周期中不断产生价值。同时，日志天然是可广播的，借助工具的力量会大大提升沟通的效率，对传统一对一的同步沟通形成降维打击。
文档-异步沟通的载体
也许很多人或许没有意识到，文档是一种非常重要异步沟通形式。文档的作者将需要传递的信息通以文字作为日志载体发布出来，而文档的读者并非要在发布的一刻就必须仔细阅读，相反，大多数读者只在遇到问题的时候才会查阅文档用来解决问题。这是一种非常高明的异步沟通手段。但需要几个前提条件：
- 文档天然具有版本属性，需要使用版本管理工具。考虑到人类现有的最可靠的版本管理工具都是服务于源代码的，因此将文档视为源代码的一部分，用编写源代码的方式编写文档是自然而然的想法，而微软的office套件或者wps之流，只能用下图形容
![71b8d3fa6364a67267833f42e12ca34a.jpeg]( "71b8d3fa6364a67267833f42e12ca34a.jpeg")
- 通过文档高效沟通的前提是：文档必须是自组织的。死气沉沉的文档只是大家coding之外的沉重负担，因为缺乏了反馈机制和协同特性，势必变成文档作者的一言堂。考虑到没有负反馈的系统通常都死的比较惨，多人协同工作完成文档的必要性就显得更重要了。这也是为什么文档一定不要用word写的重要原因。
这里自组织其实有一个不太容易get到的点：如果一份文档十分重要，用的人很多，那势必有很多人贡献智慧到这份文档中，活跃的文档自然具有更高的质量；反之，那些没什么用的文档，写的烂点就烂点吧，人生苦短，不要在没意义的事情上浪费太多时间。
- 可搜素的文档对文档的可用性至关重要。在没有专业级别的搜索引擎工具可以借鉴的时代，部署一套elastic用简单的tf-idf模型对文本分析和索引，将极大提升文档的可用性，特别是可达性。
其他异步手段
- issue+todo-作为工作项闭环管理的手段，issue从设计开始就是面向异步的：所有内容和讨论留痕，可以供所有人阅览从创建issue开始的所有记录。通过在文本中添加简单的
@、!、#标记，可以十分方便地把issue同开发者、代码乃至其他issue有机结合起来，形成一张匹配现实世界复杂度的图，而每个人只需要关注其中和自己相关的部分就可以了。这个筛选过程就是gitlab todo。 - Merge Request Review-软件质量提升最重要的环节——代码评审向来是人力黑洞：评审几乎总是意味着一起开会，而开会的效果完全取决于每一位开会的同学对待评审这件事情的重视程度。包括Gitlab在内的很多工具对评审评审过程展开了大量的效率优化工作，包括评审过程记录、评审遗留问题和issue的快速转换、长周期评审、异地（远程）评审等。异步化的评审可以确保每位评审参与者的意见可以充分表达，同时也对评审过程本身提供了许多量化的效果评价指标。
- IM&Mail-邮件和之后的即时通讯工具是伟大的发明，让开发人员可以自主安排响应的时间。但他们可能不是真正的异步沟通，这在下面会有详细的说明。
建立异步沟通文化
本节部分内容翻译自这里
- 💬过度沟通。发消息时尽可能提供充分的信息。用截图或录屏来把问题可视化。清晰地描述你需要对方做什么，什么时间完成。多花几分钟时间增加信息和编辑文字，在异步沟通的环境下能省却几天的往复确认。
- ⏳ 尽早规划，留时间给他人考虑。例如“我希望 2 天后完成这个工作，希望你能提供些建议。”而不是“请在一小时内回复。”
- 📄 始终检查文档共享设置。如果应该能读到文档的人需要申请访问权限，可能会有几小时甚至一天的等待。
- 👈 会议开始前就发起一个会话或文档。共享会议香港信息，讨论关键问题。这样参会者在会议开始前就能知道议题的情况。（可以尝试用 GitLab Issues 或 Wiki 的形式来改善。）
- 👉 会后将讨论和结论文档化。让没有参会的人可以找到这些信息。我们甚至实验录制会议视频，让其他人可以异步“参会”。（我曾经一直想搞一套语音转文字的记录软件，记得Ray Dalio一直介绍桥水的所有会议都有录音，录音会有专人整理成文本。每个人的会议发言都会在事后被检验，影响ta 的 credibility 值，并因此影响 ta 的一票对集体决定的影响力。如果发言被记录，被存档，会议上必然会少很多无关讨论和未经思考的废话。当然，这也会阻止一些灵感被说出来。不过总的来讲，正确的事情太多了，做不过来的，仅仅少做傻事就可以比很多人、很多公司成功了。）
- 🔕 关闭推送通知。仅在特定时间段检查和回复邮件、信息。
- 🤔 高效使用等待时间。（异步沟通的更长的）等待回复的时间并不是什么大问题，总有其他需要你做的工作可以在这段时间进行。
- ✍ 将写作和沟通作为核心技能来提倡掌握。这可以减少沟通中的反复，让人可以更快地触及问题核心。异步工作环境下的每个人都需要长于写作。
- 👏 基于产出和结果评价他人。而不是基于 ta 响应有多迅速或是工作多少小时。
- ⏱摈弃稳定工作时间以及出现在办公室的要求。天然地驱动整个组织按异步沟通的方式运作，因为拍肩膀发起谈话不再可能了。
- 🤝 强调信任、组织、独立和担当。没有这些价值观的话，异步沟通不可能成功。
- 👩⚖️ 采取单人直接负责制的管理和决策模型。这个 Apple 发扬光大的方法是指，对每一个领域，每一个项目，都有单一个体负责。这个人不亲自做所有事，而是组织团队做事，做关键决策，对进度和结果负总体责任。越是减少参与具体决策的人数，分散权威（authority），加大对个人的授权（对 accountability 的不错解释是 the liability created for the use of authority），团队就越高效。
- ⌛️ 设定团队范围内合理的可接受的响应时间要求。Doist 期望大家在 24 小时内应答。
- 📄 优先考虑透明度。所有人都可以看到所有的核心讨论，不管是不是团队一员。高透明度使得人们可以更高效工作的原因是当 ta 需要信息时，ta 不必去向他人索取，而可以自行搜索到。（在以往的工作中我遇到过这样的情况，我感到某个流程不畅，但不知道怎么改进它。一段时间之后在闲聊中得知，其实系统有 xx 功能或者 xx 接口，只是不对工具运维团队和管理员之外的人开放，“如果你需要，可以提出来去申请啊。” 我只想说，我都不知道有某个权限的存在，我怎么去申请该权限…… 我的权限和小道消息来源算多的了，我根本无从得知其他人在工作中遇到了多少类似的障碍，而这常常没法通过询问得到答案。因为他们不知道自己遇到的不便是流程或系统设计如此，还是通过一些流程外的人工申请，本可以更美好一些。）
- 🛠 使用有助于透明、深度工作和异步沟通的工具。例如 GitHub pull request、IRC讨论组。不要用电子邮件。尽管电子邮件可以异步沟通，但是它将信息锁在了人们的收件箱里，其他人无从获知。当人们无法得到所需信息，协作就必然更加低效。
- 🚨 对紧急事件建立单独的沟通渠道，比如电话或者微信群。始终坚持一点：只有在真正紧急的情况下才启用这些渠道，同步沟通应当作为例外，而不是规则。
例外
人的因素
第一个例外，关于人的水平下限。
异步沟通团队核心价值观有一个假设是，别人不必为你的承诺担心，你不会食言，你会说到做到，按时交付。这个假设可真的太强了，很少有组织敢对全员做这个假设。假如我对不同沟通方式下，员工素质和团队生产率这两个变量的关系作图，我想可能是这样的——
当人员水平下限不足时，同步沟通能确保一个可接受的生产率，异步沟通则失灵。
当人员水平逐渐上升，两种沟通方式都可以获得更高的生产率。但异步沟通的生产率提高，对于高级脑力工作者而言更加明显。
当水平高过某一个基准后，同步沟通成为生产率继续攀升的制约因素，而异步沟通因为解放了个体的深度工作可能性，并不会频繁打断工作或是分散注意力，安分地充当一种工具而不是限制。
渐变
从同步到异步的过程中，我们大部分情况下只能掌握自己发起的沟通在哪里进行，却很难对沟通的其他参与者提更多的要求。例如，尽管我们希望用户反馈通过 GitLab API 提成 Issues，和测试团队报上来的问题同样处理，但近一年下来仍难如愿。这样做的好处显而易见：转测试复现方便，@一下就行，对问题的修复或者功能的实现相关的 commit 也能很方便地 mention 这个 issue id。但是这样看问题立刻能知道为啥推不动变革：益处都是自己的，别人只觉得多一事，当然不如少一事。反观那些成功安利的系统，典型的是 Redmine，无需什么广告、培训，只要对某个人群自身有益处，很自然地就会采纳。
异步沟通在一个大环境里，也是相似的。不要试图剧变，或是看不清路线就止步观望，而是观察自身、自己团队所处的局面，找到一个可以行得通的妥协的路，让事情发生，以摸着石头过河。
组织内部，沟通问题是所有问题的替罪羊。但是如何宏观地评价沟通有效性，如何去解决沟通过程中的具体问题，短期看没什么万灵药，长期看不解决必疲于奔命，是个管理当中核心的问题。领导人和管理事，很大一部分就是管理信息流通，这是个技术活，也是个艺术活。
References:
The Remote Manifesto, https://about.gitlab.com/blog/2015/04/08/the-remote-manifesto/
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/
How we Communicate at Automattic, https://watirmelon.blog/2016/07/22/how-we-communicate-at-automattic/
The Nomad City 19 Chats- Marcus Wermuth, https://www.nomadcity.org/the-nomad-city-19-chats-marcus-wermuth/
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
Full List of Employee Tenure at Fortune 500 Companies, https://www.payscale.com/data-packages/employee-loyalty/full-list
The Do’s and Don’ts of Measuring Employee Productivity in the Knowledge Economy, https://doist.com/blog/measure-improve-employee-productivity/
How to Build Trust in the Remote “Workplace”, https://doist.com/blog/trust-remote-workplace/
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
Twist vs. Email: The More Organized Way to Work – Twist Help, https://get.twist.help/hc/en-us/articles/115003654589
The Art of Async: The Remote Guide to Team Communication, https://twist.com/remote-work-guides/remote-team-communication
沟通・软件研究所员工手册，https://handbook.sansi.io/guidelines/communication.html↩
