“在团队或者公司的成长过程中，通常有哪些流程和体系的瓦解失控没有被及时设法解决？”

这是我最近在一个高增长工程（Engineering for High Growth）座谈会上向来自Dropbox、Facebook、Stripe和Lyft的领导者们提出的问题。与会的各位成员分别用不同的阐述方式给出了同一个答案：沟通是团队增长过程中最为常见的受损点之一。

随着团队的发展，分享想法并且确保大家都达成共识变成了一件难事，曾经有效的沟通模式和习惯开始失效。

在我和工程师们合作并帮助他们提高工作效率时，沟通失败的事例屡屡出现：

某个产品团队可能已经准备好为客户交付一项高优先级的功能，但在发布时却需要“乞求”基础设施团队帮忙移除最后一个障碍；

一个平台开发团队可能升级了某项服务的后台代码，导致那些由于缺乏文档而单纯依赖API行为假设的客户端无法工作；

又或者某个团队在没有详细了解配置文件中特殊配置项来龙去脉的情况下，贸然更新从而引发大规模系统预警和报错；

……

这些事件看起来彼此孤立，但是它们都遵循了一样的模式：沟通缺失导致的知识差距严重影响了团队的执行力。

任何像与会者公司一样经历着超高速增长，尤其是员工数量平均每年2到3倍增加的公司里，沟通体系的崩塌会更为迅速。同样的问题也在其他类型的公司里一样上演，只不过相对缓慢。于是各种工程资源浪费的现象开始涌现，软件质量急速下降，而客户的抱怨日渐增长。

为什么沟通会失败？

我初到Quora，Qoyala和Quip工作时，这些创业公司都只有不到三十位员工。直接走到同事办公桌前就可以讨论设计方案，或者只需要转过身来就可以大家一起商讨决策。我知道团队里谁是哪块代码或者产品的专家，而且每个工程师都对大部分的产品和代码逻辑谙熟于心，相同的知识背景使得讨论和答疑都变得很容易。在这一段时期里，我们的沟通成本并不高。

然而这样低成本且有效的沟通在公司成长过程中逐渐变成一种奢侈，原因如下：

首先，需要沟通的总人数增加了。

Frederick Brooks 在《人月神话》里描述了这种效应：人与人的相互交流次数根据团队大小而成倍增长（这就是为什么有时候给一个项目增加更多的人手并不能促使项目更快地完成）。

信息分享不再是口口相传，而是需要组织一个正式会议。

其次，团队成员之间的沟通成本增加。

随着团队的增长，对产品和代码的平均熟悉程度也在降低。新人们不知道过去那些决策的历史背景，资深的成员则需要花费更多精力来了解正在发生的一切。

你跟其他同事的联系不再那么紧密，你也许会羞于向他们随意提问，而选择保留着所有问题并且只在正式会议中提出。

同时，问题也变得更加难以阐述清晰：

项目的历史渊源有哪些？

它又会影响到其他哪些项目？

谁知道这些事情？

而对未来变化有着强烈主见的干系人又是谁？

琐碎而繁杂的事情逐渐累积，交谈和讨论的成本日趋增高。每个人不得不花费更多时间在沟通上，这样留在将事情做好的时间自然会更少。

个人效率的降低，转而增加了团队必须为了达成业务目标而进行扩张的压力。

扩张，意味着将更多的时间消耗在发布招聘信息、面试筛选、选拔以及组织新人入职上……这些工作当然都很重要，但都不是直接作用于打造产品的，而且更多新人的加入意味着沟通成本会直线增长。

在我离开Quora和Ooyala之际，公司的员工数量都已处于成倍增长状态。正如其他相同大小的公司一样，同一项工作职责会交由更多的个人和团队一起分担。虽然小组内仍可以进行快速决策，但是更大的决策就需要通过组织会议来让各干系人共同参与。

在更大的公司里，沟通成本螺旋上升更甚。你可能需要为了推动项目的进展去协调不同团队的工作时间，需要走到另外一个办公楼去开会，甚至需要飞去另外一个城市或者和异地的同事通过视频会议沟通。

沟通过程中的摩擦越来越强意味着：很多必需的沟通没有发生。

Michael Lopp，Pinterest的工程部负责人，在他的书《Managing Humans》里做了相似的描述：“当团队的组织大小各不相同时，以前那些系统性的，促进完成文化和战略工作的，能够帮助决策重大事件的信息交流和沟通，再也不会发生。”

减少沟通成本

随着公司野心和机遇的增长，团队也需要同步成长以迎接挑战。以Google和Facebook为例，它们的体量和资源使它们能够更为轻松地面对那些小型创业公司所不能处理的问题。

在高沟通成本的情况下，任何能够降低这些成本的措施都具有极大价值。所以我们如何能降低沟通成本呢？ 如下是一些策略：

1）雇佣高效工作者

更多地招聘高效工作者，协调项目需要的沟通总量就会相对较低。每个人都可以把大部分的工作时间用来把事情做好上。这样的精简保证了团队有足够的资源来解决重要问题，而每个工程师的工作会更有效率。

2）投资新员工培训

团队扩张时，新员工入职培训是一个给新员工们灌输做好事情以及做正确决策概念的好时机，并能达到事半功倍的效果。确保每个新员工都能知道核心代码抽象 (core abstractions)、开发工具、业务流程和公司目标，这些会作为他们以后决策和交流的背景知识。

3）投资能降低沟通摩擦的工具

工具的易用性和流畅度非常重要——越容易用于沟通，人们就会越愿意使用。

确保使用合适的工具来分享状态更新、反馈代码审查意见、追踪代码缺陷、用户问题以及其他种种信息的交流。

4）用异步沟通取代亲自会面

定期一对一交流和会面是需要的，但总会有一些议程混乱的会议发生，而且有些为了信息交流而每周重复的会议完全可以被协作文档来代替。异步讨论对交流有更少的破坏性，产生更少的间接花销，并且能够允许团队成员更集中关注在自己的工作流上不被打断。我们只需要高效地进行那些真正需要面面同步和交谈的会议。

5）通过轻量级设计文档来分享知识

写一篇简明的设计文档是一个传达信息和征求反馈的好办法。它远比组织一个信息发布会议花费更少的时间和精力，而且还比完成某个成果后再获取反馈更为经济，同时这些设计文档以后也会成为新入职员工的知识库。如果想法或计划的沟通可以很轻量化且不需要太多的正式会议，大家肯定会更愿意把分享信息作为工作的一部分。

6）打造文化一致，松散耦合的团队

Reed Hastings把这一哲学作为Netflix企业文化获得成功的一个重要因素。如果发展策略和目标定义明确且众所周知，我们就可以减少跨职能团队的会议同时确信各团队之间仍然是认知和目标一致的。

其中一个方法就是：大家对哪些是最重要的业务度量都有一致认可（例如，注册人数 vs 注册人数增长率，平均响应速度 vs P0问题响应速度，解决的缺陷数量 vs 遗留的缺陷数量），当团队之间意见不一致，疲于争执优先级时，以这些度量为衡量标准，尽力移除项目障碍并保证项目进展。

在团队增长的各个阶段，降低沟通成本意味着花更少的时间和精力在协作工作上，花更多时间在把事情做好上。任何时候我们都不能忽视对沟通成本的控制。

原文地址：http://www.theeffectiveengineer.com/blog/communication-first-casualty-of-teams-growth

本文译者：姚晶 aka 歪歪（点融黑帮），点融Fincore团队高级项目经理。毕业于法国工程师学校，PMP，CSM，CSPO，宇宙关爱程序猿成长协会成员。敏捷实践者，喜欢旅行，喜欢神奇的事物。