异步工作才是最适合程序员的协作方式

不断的 IM 消息和邮件，把时间切的稀碎，而写代码需要一段比较长的时间才能进入状态，所以我们往往在白天根本写不了什么代码，只能在晚上测试，业务，客户都下班后，默默地写代码。

然而，一天的碎片化信息和多任务切换后，我们的精力已经消耗殆尽，晚上写代码的质量不高，写 Bug 效率很高，所以虫子（Bug）都喜欢晚上出来，等白天来临，业务，测试回到工作岗位后，就会发现我们置入的这些 Bug，从而又给我们发消息，准备数据，配合重现和确认，修改代码，再次验证。如果流入生产，就会被客户发现，从而上升到最高等级，必须停下手里的工作去救火。这样，我们的时间就更碎片化了。聪明如你肯定看出来了，这就是一个恶性循环呀。你说那我不会消息可以吗？不行，因为如果没有及时回复别人，在绩效沟通时可能就会得到一个「不善于团队合作」的评价。

我也一直有这样的苦恼，但是最近我加入的一个团队，却颠覆了我的认知。我加入这个团队的角色 Android 端的技术负责人，刚入职很多「杂事」还没有交接到我手上，所以我现在可以说是一名普通的开发。跟你聊聊我典型的一天是什么样子啊。

上午，写 3 个小时代码
下午，写 3 个小时代码
代码写完后，发 Pull Request
查看 GitHub Issues，看看有哪些需求和 Bug，挑选优先级最高的，分析理解，需要明确的就在对应的 Issue 里留言 @同事
看一下之前的 PR，有没有什么问题需要解决的
看一下其他人的 PR，Review 写反馈
下班前的半个小时，查看邮件，简要总结当天完了哪些工作，文字发到 Discord 站会频道里

每周有半个小时全员会议，COO 分享公司的大事，跨团队的一些提问和信息共享，需要详聊的再单独约小会。每月一次回顾会议，增进感情和改进协作方式。

这个公司里，几乎没有点对点的即时消息，几乎没有邮件。有一些需要频繁沟通甚至共创的工作，会结对完成。

我在 2012 年拥抱敏捷开发，后来又做了几年「敏捷教练」，看到敏捷正在被广泛接受，敏捷 12 条原则的第六条一直是我非常认可和鼓励的：

不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。

但是我加入的新团队，却采用「异步工作」的方式，并且运作良好，这有点颠覆我的认知了。但仔细想想，「异步工作」和上面的原则其实不冲突。我们这一代中国人学习英语的方式，带来结果是，读写能力高于听说能力。不仅我们国家这样，很多其他的国家的英语发音也是口音很重的。面对面沟通的时候，老让对方「Pardon」，效率能高到哪里去呢？我们大部分程序员看文档写邮件都没有问题，但要打电话和面对面沟通就头疼了。

另外，如果我们工作中 80% 的内容是传递信息，那么我们就不用采用一种低效的沟通方式。但如果我们工作中的 80%甚至 90%都是独自创造，只有一小部分是需要传递信息的，那么就算效率低一点，影响也不会很大。

那我们来看一下，软件开发这项工作，大部分时间是在独自创造还是传递信息呢。其实没有绝对的答案，开发底层的东西，前者的比重可能会更大一下，做的是面向用户的东西，就需要更频繁地交付和获取反馈。不管是底层框架还是业务团队，在团队内也有分工，有些人擅长干「大活儿」，领导就会把大活儿给他，把其他琐碎的活儿给其他人，这样他才能专注地干好大活儿。

如果我们期望高质量，高效率，高价值，就需要「深度工作」的状态。干「大活儿」，就需要进入「深度工作」。回 IM，邮件都是属于「肤浅工作」，很难带来极大的成就感和满足感。所以你才会觉得一天下来好像忙得上厕所都要小跑，等到了下班的点儿，却很空虚和焦虑，然后就会不由自主地通过加班来弥补。想从工作中创造更大价值，获得更多成就感，推荐阅读《深度工作》这本书。

为什么异步工作有效

其实我们会发现，再好的方法，在某些人身上也不管用，再不好的方法，在某些人身上也管用。在探究「为什么管用」时，其实真正值得关注的是「怎么让它管用」。

通过我的观察和实践，我觉得下面这几点很重要：

结构化表达
高度透明
鼓励全栈
开发者测试我们一个个展开聊聊。

结构化沟通

程序员的工作中主要打交道的无非产品经理，业务分析师，客户，测试工程师，还有其他程序员，比如前后端联调，系统间联调等。沟通场景主要有几类：

需求获取，澄清和验收
Bug 重现，确认和验收
接口定义，联调

不管是书面沟通还是面对面沟通，文字和声音都只是传递信息的一种媒介而已。真正决定沟通效率的，是沟通的内容本身是否结构化。就好比外卖时效性很高，但送过来的是一坨屎。

所以你看优秀的开源项目，在提需求和缺陷的时候，都要遵循一定的格式。这里吐槽下国内的工具厂商，为了满足所有人的需求，往往做的大而全，几十上百个字段，一看就头大了，填的时候就很敷衍，真正重要的信息都靠 IM 一问一答一点点榨取出来，真的还不如一个消息模板好用。还有考核缺陷率，为了维护良好的同事关系，测试人员也不会直接上系统给开发人员提缺陷，而是先用 IM 沟通，导致很多低效的一来一回的对话。

高度透明

还记得前面提到的第六条敏捷原则吗？

不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。

在我看来，传递信息更有效的方式，是把信息放在人人都能轻松获取的地方。这就是为什么 Trello 类的看板工具，飞书/Slack/Discord 类的 IM，Notion 这样的团队知识管理工具，现在这么火爆的原因。要有团队的共享知识空间，重视知识积累。我刚加入新公司的时候，体验设计师就发给我 3 个他录制的视频，讲解他在 Zeplin 上是如何组织设计图的。要怎么找到布局，图片，字体和颜色等参数。这样就不用每来一个新人都去问他了。

鼓励全栈

人的眼界越小，越对其他东西缺少敬畏。所以才会有程序员鄙视链，用 Mac 的鄙视用 Windows 的，用 Terminal 的鄙视用 GUI，用 Vim 的鄙视用 IDE，甚至用外接键盘的鄙视用自带简单的。前端说后端不就是增删改查吗？后端说前端不就是堆堆页面吗？但是出了问题，总觉得自己这块没问题，问题在对方那边？这不合逻辑啊，问题不是应该更容易出在比较复杂的那边吗？你可能会说，我这边是更复杂，但是我聪明又细心啊。那就更可怕了，你跟不聪明又不细心的人一起工作，你确定真的不是因为你跟他是一类人吗？其实，你拥有的一切，都是因为你「值得」拥有，说难听点就是你「只配」拥有这样的。所以，停止抱怨你的老板，领导，同事，也不要抱怨你的对象了。唯一有效方法，是去提高自己，你才会拥有更好的。

如果你是前端，你去精进前端技术，你就会遇到更好的后端。很简单，精进了之后你可能会拿到更好的 Offer，你遇到更优秀的领导和同事的几率就会更大一些。另一个方向是，反正都很简单，就去学习一下，去做全栈，前后端都一个人做了，这样就可以避免跟别人扯皮。如果你们是技术栈，前后端都用现成的框架，比如前端用 React，后端用 SpringBoot，那真的不难学。甚至你用 React 都不应该称自己为前端工程师，真正的前端工程师是开发 React 的人，真正的后端工程师是开发 SpringBoot 的人，我们都是业务开发工程师。

开发者测试

测试代码就是产品代码的使用说明书，并且是自动化的回归测试。开发者在编写测试代码时，对业务的理解会更加清晰，代码质量会更高，其他人在使用到别人的代码时，可以通过阅读测试代码来更好地理解每个方法的输入输出，在需要修改时，也有信心去修改，因为只要修改后测试还能运行通过就基本没有问题，测试不通过就去修复测试就好了。

怎么开始尝试

团队约定一个静默时段，比如每天上午的三个小时，不要开会，不要发消息回消息。那你说要是团队外有紧急的事怎么办？可以轮流值班，每周有一个人来处理对外沟通的事。想要探讨更多，可以来周三晚上的直播，也欢迎来 K+ 深圳峰会现场交流。