工程团队组织架构图：把团队与其负责的系统对应起来

大多数组织架构图只回答一个问题：谁向谁汇报。工程师很少需要这个答案。事故发生时，他们需要知道出故障的服务归哪个团队负责、谁在值班。设计评审时，他们需要知道一项变更会影响哪些团队，以及这些团队如何协作。一张只有姓名和职位的图，哪个问题都回答不了。

本文绘制一张能回答这些问题的工程组织架构图。它保留了面向人员管理的汇报关系，并加上工程所需的信息：团队类型、负责的系统、值班时间以及团队之间的协作方式。团队部分使用 Team Topologies 的术语，最后说明应该标注什么，以及如何让这张图保持最新。

工程组织架构图应该展示什么

团队超过几个之后，就不要把每位工程师都画进图里，而是每位团队负责人画一张卡片。一张有六十个名字的图是电话簿；一张有八个团队的图才是地图。如果有人需要具体名字，就把每个团队链接到各自的成员名单。

汇报关系并不是全部

Mel Conway 的论文“How Do Committees Invent?”于 1968 年 4 月发表在 Datamation 上。他在介绍这条定律的个人页面上这样概括其论点：设计系统的组织，其产出的设计结构会复制该组织的沟通结构。后来 Fred Brooks 把它称为康威定律，这个名字便沿用了下来。

注意“沟通”这个词。组织架构图展示的是汇报关系，而汇报关系只是人们沟通方式的一部分。两个隶属不同总监、却每天都在交流的团队，对系统形态的影响比他们经理之间的那条线更大。因此，本文的图不仅写出团队向谁汇报，还写出团队之间如何协作。

这条定律也可以作为设计工具。如果两个服务应该保持独立，就不要把它们交给每次变更都必须协调的团队。Conway 的论文还提出了一个推论：最初的设计很少是最好的，所以组织需要足够灵活，能随着设计一起调整。

团队类型与交互模式

Matthew Skelton 和 Manuel Pais 提出的 Team Topologies 为团队提供了一套精简的通用词汇：四种团队类型，以及团队之间的三种交互方式。

三种交互模式：

• 协作（Collaboration）。 两个团队在一段明确的时间内紧密合作，共同探索新事物，例如一个 API 或一种实践。这种方式成本很高，所以要给它设定结束日期。
• X 即服务（X-as-a-Service）。 一个团队提供某样东西，另一个团队在很少交互的情况下使用它，例如部署流水线。
• 促进（Facilitating）。 一个团队帮助并指导另一个团队，例如在对方采用新的测试方法时。

Team Topologies 网站本身也给出了提醒：这套方法不是用来设计新组织架构图的。它描述的是工作如何在团队之间流动。把它的词汇用作图上的标签，而不是把它当成重画每一条汇报线的理由。

把归属信息放在一处

只写在图上的归属信息会过时。把权威数据源放在工程师平时就会查看的地方，再让组织架构图在团队层面反映它。

在 Backstage 这样的服务目录中，每个组件都必须指定一个所有者：在目录描述符格式里，spec.owner 是必填字段，所有者是单一实体，通常是一个团队。在代码仓库中，CODEOWNERS 文件把路径映射到负责的人或团队；当一个非草稿状态的拉取请求修改了他们的代码时，GitHub 会自动请求代码所有者评审。

如果图和服务目录不一致，通常服务目录是对的，而这张图早就该评审了。

示例：一家网店的工程部门

一家网店的工程部门有一位 VP 和两位总监。Product Engineering 管理三个团队：同为流对齐团队的 Checkout 和 Search，以及负责支付处理和欺诈评分的复杂子系统团队 Payments。Platform Engineering 管理负责 CI/CD、Kubernetes 集群和可观测性技术栈的 Platform 团队，以及负责人职位仍然空缺的 Developer Experience 团队。

本季度有两项协作正在进行。Payments 和 Checkout 正围绕 3-D Secure 展开协作，持续到第二季度末。Developer Experience 正在促进 Checkout 迁移到契约测试。

这张图的读法如下：

• 从上到下，汇报关系。 VP、两位总监和五位团队负责人。连线只表示谁向谁汇报，别无他意。
• 卡片颜色，团队类型。 琥珀色表示流对齐团队，玫瑰色表示复杂子系统团队，蓝色表示平台团队，紫色表示赋能团队。团队层级以上的管理者保持灰色。
• 每个团队下方，工程视角。 团队负责的服务、值班时间，以及当前与其他团队的交互方式。
• 虚线卡片表示空缺职位。Developer Experience 还没有负责人，这张图如实标出，而不是把空白藏起来。

需要标注什么

• 按大家实际的叫法写团队名。 如果事故频道里叫“Checkout”，图上就写 Checkout。
• 负责的系统，使用服务目录、仪表板和告警中的名称。
• 值班时间以及升级路径。
• 每项协作的交互模式和结束日期。
• 虚线汇报关系，例如一位隶属安全团队、却每天与 Payments 一起工作的安全工程师。
• 团队跨多个地点或时区时，标出地点或时区。
• 在图上直接写明上次评审的日期。

常见错误

• 只有人没有团队。 一棵名字树无法告诉任何人出问题时该找谁。
• 没人负责的系统。 如果某个服务不在任何团队名下，这本身就是发现。在下一次事故替你分配之前，先把它分配出去。
• 共同负责。 两个负责人通常等于没有负责人。Backstage 要求单一所有者是有原因的。
• 没有终点的协作。 协作本应在一段明确的时间内进行。一直不结束的协作，往往说明两个团队之间的边界划错了地方。
• 负担过重的团队。 一个负责十几个服务和两套值班轮换的团队，什么都会做得慢。Team Topologies 把团队的认知负荷视为设计时必须考虑的上限，而组织架构图能让这种负荷一目了然。
• 没人更新的图。 每次组织调整、每个新服务上线时都要更新，并定期评审。

组织架构图展示谁负责什么，却不展示各个系统如何组合在一起。要表达后者，请绘制 C4 模型图或微服务架构图，并按照不会过时的架构图中的做法让两者都保持最新。

在 Archboard 中构建

1. 使用 Google 或 GitHub 登录，并新建一张图，或者从组织架构图模板开始。
2. 添加组织架构图节点包中的 员工 卡片表示 VP，并填写姓名、职位、部门和地点。
3. 用加号手柄添加人员：下方添加下属，侧面添加同级，上方添加上级。图会自动从上到下排布。
4. 为每个正在招聘的职位添加一张 空缺职位 卡片。
5. 把每位团队负责人的卡片颜色设为对应的团队类型，团队层级以上的管理者保持灰色。
6. 在每位团队负责人下方添加基础节点包中的 文本，写明团队类型、负责的系统、值班时间和当前的交互模式。

这个示例共用 8 个图表节点，在 Free 套餐的限制之内。文本不计入这个限制。组织架构图制作页面介绍了分享和导出。

常见问题

工程组织架构图应该展示每一位工程师吗？ 团队不多时可以。超过这个规模后，只展示团队及其负责人，并把每个团队链接到各自的成员名单。这样图更易读，也不必频繁改动。

如何表示虚线汇报的上级？ 从第二位上级画一条虚线，实线留给负责绩效评估的上级。在 Archboard 中，来自第二位上级的连线会变成虚线，布局仍以第一位上级为准。

组织架构图和团队拓扑有什么区别？ 组织架构图展示汇报关系。团队拓扑展示团队类型以及团队之间如何交互。两者都画，或者像示例那样在组织架构图上注明交互方式。

服务归属应该记录在哪里？ 记录在服务目录或 CODEOWNERS 文件中，让工具和人员都能找到。组织架构图在团队层面反映这些信息。

工程组织架构图应该多久更新一次？ 每次组织调整、新增团队或新服务时更新，并定期评审，例如每月一次。把上次评审的日期写在图上。

免费开始 — 1 个席位，无需信用卡。