限制非必要沟通

康威定律的一个核心内涵指出，并非所有的沟通和协作都是有价值的。因此，定义“团队接口”并设定预期，哪些工作依赖于紧密协作，而哪些不需要，这是非常重要的。很多组织认为沟通总是越多越好，但事实并非如此。

我们需要的是特定团队间更为聚焦的沟通。我们同样需要识别那些意料之外的沟通，并进一步寻找根本原因。正如Manuel Sosa和她的同事在2004年对飞机制造业进行研究所发现的，“管理者应该集中精力在模块化系统中，理解被人忽略的设计接口背后的原因，以及难以预测的团队互动。”

Mike Cohn作为Scrum产品开发方法的创始人之一，提出了一些问题，来评估组织内团队之间沟通的健康度：“这种架构是否最小化了团队间的沟通路径？这种架构是否鼓励团队进行沟通？”

在此，Cohn试图弄明白一件事，从逻辑上讲，根据软件架构设计，如果两个原本不应该彼此沟通的团队正在进行沟通，那么一定是哪里出了问题。是不是API设计得不够好？是不是平台不合适？是不是组件存在缺失？如果我们能够保持团队间低频沟通，甚至是在零沟通的前提下依然可以安全、有效和快速地构建和发布软件，那么我们就应该这样去做。这一点直观地体现在图2.5中，这同Henrik Kniberg的“Real Life Agile Scaling”是一个道理。

制约沟通的一个简单方法就是，将团队安排在办公室的不同区域、不同楼层，甚至不同大楼。如果团队主要通过及时通信软件进行虚拟沟通，那么团队间沟通的信息量和模式可以作为识别那些与软件架构所预期的交互不匹配的沟通情况。

团队内部高频沟通，两个合作团队之间可以保持中频沟通，而大多数团队间应该做到低频沟通。

类似地，如果有一个大团队同时负责系统的两块独立业务，那么有必要将团队拆分为两个小团队来专门负责其中之一，尽管这仅适用于相同团队成员工作在不同系统的场景。如果在设计上就要求整个团队工作在多个系统组件上（比如，一个新服务和一个旧组件），那么请保持他们在一起工作（参考第8章来了解更多有关旧软件系统的长期“维护连续性”模式）。

有些时候，两个或多个团队感觉需要围绕软件进行沟通，纯粹是因为他们各自负责的系统代码托管在同一个版本控制库里面，或者是这些代码属于同一个应用或者服务。但是这些部门在逻辑上应该是彼此独立的。当这种情况发生时，我们需要使用“破裂面”模式（这一点将在第6章介绍）把软件拆分为更小的部分，并纳入独立的版本控制库中。

并非每个人都需要彼此沟通

自从有了开放式办公区，特别是无处不在的即时通信工具，人与人之间可以随时随地保持沟通。这时我们往往不经意间就会陷入一种需要跟每个人（也就是将提取有用信息的责任推给了消费者）进行沟通才能完成工作的沟通和交互模式中。从康威定律的视角来看，这将会给软件系统带来意想不到的后果，特别是在缺少模块化设计的子系统之间。

如果一个组织认为“每个人都需要看到每条对话消息”“每个人都需要参加大量的站会”“每个人都需要出席会议”，这样才能完成决策过程，那么我们的组织设计肯定出问题了。康威定律表明，这种多对多的沟通会产生单体、杂乱、高度耦合和相互依赖的系统，并会阻塞快速流动。也就是说，过多的沟通并不一定是好事。