小心那些流于表面的康威定律

如果团队错误解读了康威定律，会带来风险，表面上看建立另一组团队可以完美适配所需的架构，但实际上，却非常不利于工作的快速流动。除此之外，跨团队的工具和沟通之间的关系往往被视而不见，但其实这类工具可以强力推动分形设计。在本节中，我们会识别一系列流于表面的康威定律的应用所带来的潜在问题。

工具驱动的沟通模式

团队使用软件沟通工具的方法，会对团队间的沟通模式带来极大的影响。在致力于构建和运行现代软件系统的组织中，存在一个常见问题，那就是团队和部门的职责边界与他们所使用的工具是不匹配的。有些时候，组织内部存在多种工具，但实际上使用一个就够了（提供一个通用和共享的视图）。而当团队需要独立工具的时候，要求他们使用统一工具也会带来问题。

康威定律告诉我们，组织的产品设计会受到沟通结构的制约，导致这些产品设计成为沟通结构的复制品。因此，我们需要注意共享工具对于团队交互模式的影响。如果我们希望加强团队合作，那么共享工具能帮助我们达成这个目标。如果我们希望在团队间建立清晰的职责边界，那么独立工具（或者相同工具的不同实例）也许是更好的选择。

比方说，我们希望软件开发团队和IT运维团队紧密协作，那么让这两个团队使用独立的问题和事件管理工具在很大程度上会导致团队间沟通不畅。为了帮助这些团队更好地协作和沟通，我们应该选择一个能满足不同团队需求的工具。类似地，也应该尽量避免出现一些特殊的“生产专用”工具，这些工具仅对生产环境拥有安全访问权限的团队开放。如果这些工具同构建的软件存在交互或者度量关系，那么限制访问权限会使得有权限和没权限的团队产生沟通障碍。所以说，工具可以促进也可以阻碍沟通，并进一步影响团队间的交互有效性。

然而，如果两个团队的职责边界并没有交集（当团队的职责非常独特且没有太多需要协作的事情时），那么还坚持使用相同的问题跟踪工具，甚至是相同的监控工具，就没什么太大价值了。特别是，当提供服务的团队并不在组织内部的时候。

总之，不要在脱离团队内部关系优先的前提下，盲目地为整个组织选择单一工具。用一句话来概括就是，独立团队使用独立工具，协作团队使用共享工具。

小贴士

在保证安全的前提下使信息透明。

日志聚合工具为那些没有权限访问生产环境的应用团队提供了一种简单的解决方案来查看生产日志（或者出于调试目的）。这类工具将所有日志导出到一个外部路径，并对日志进行处理和聚合索引（需要的话，也能进行匿名处理），使得搜索日志和查询相关事件的效率相比处理单个日志大幅提升。团队可以在生产安全管控措施生效的同时访问他们所需的生产信息（并非仅仅保证日志以一种安全的方式进行传输）。

多组件团队

很多组织草率地按照康威定律建立了大量不同的组件团队来分别构建系统的各个小部分。组件团队，也被称为复杂子系统团队（参考第5章），仅在某些强依赖特殊技能的场合下能够起到作用。实际上，我们需要面向快速流动进行优化，所以更为推荐流动式团队。我们会在第5章展开讲解更多相关内容。

通过反复的组织结构调整来建立山头或减少人员

过去很多“组织结构调整”的潜在目标都是为了减少员工或者围绕管理者和领导者的权势建立山头。当我们改变组织结构来适应康威定律的时候，我们的目标是改善组织寻找软件系统解决方案的空间（环境、约束等）。这两种方法是相互对立的。对于一家软件“产品”公司来说，组织结构预示了产品架构。结合团队优先方法，出于管理原因定期进行组织结构调整应该成为过去时。

说得严重些，出于管理方便和减少人员投入为目标的常规组织结构调整会让组织有效地构建和运维软件系统的能力荡然无存。忽视康威定律、团队认知负荷和相关的动态风险来进行组织结构的调整，就好比让一个小孩子来做心脏外科手术一样，往往是毁灭性的。