引言

英文原文：The Best Developer Team Structure

在灭火行动中，有一种经典的“水桶阵型”——队员们排成一列或几列，将水桶从水源处依次传递到火灾现场。这种协作模式甚至不需要语言交流，但它显然不适用于软件开发。

Scott 根据自身经验，针对软件开发团队的结构总结了以下几点建议。这些建议不一定全面，但值得参考。

组织架构与项目经理（PM）

组织架构是完成工作的工具，你需要合适的工具来提升工作效率。没有永远最佳的组织架构，每一个项目都有最适合它的架构。

  • 项目类型决定架构：我个人的工作经历主要集中于网站早期开发，这是一门非常特定的工作，因此偏向于敏捷（Agile）/ 迭代的工作模式。如果你是为银行或者航空公司做开发，肯定需要不同的工具和组织架构。
  • 最佳配比：根据经验，通常 3-5 个开发者 围绕一个 项目经理（Project Manager, PM） 能够达到最佳的工作效率。
  • PM 的真实定义：PM 是一个过于复杂并且常被滥用的术语，坦率地说，我非常讨厌这个词。这里所说的 PM 是指“解释、阐明项目需求的人”。从产品战略的角度，PM 需要有强烈的想法，清楚需要构建的是什么；但他们更重要的任务是权衡从客户到设计师等全部利益相关者（Stakeholders）的需求，并据此制定计划。
  • 工程师与 PM：工程师可以是 PM，我也见到过很多成功的案例，但需要注意的是，实际上他们的职能完全不同。

  • 团队 vs 一群人：作为一个 PM，你需要理解“团队”和“一群人”之间的区别：

    • 团队：工作方式更像一个单位。团队中有角色之分（比如四分卫、组织后卫、游击手等等），但每个人都为了同一个目标努力完成自己的任务。
    • 一群人：指很多聚集在一起的人，而非一起工作的人。
    • 目标：你需要构建的是一个团队，而非一群人。

团队规模与拆分

组建团队的方式有很多种，这里列举一些常见策略：

  • 强制结对编程（Pair Programming）；
  • 通过将项目按组件分解，保证多人同时作业；
  • 技术设计与编码分离；
  • 降低 在制品（Work-in-Progress, WIP） 能够驱动结对乃至多人编程项目。
注：保持低的 WIP 度是一个非常神奇的解决方案。当你不知道该做什么时，降低 WIP！

团队拆分原则

每当团队增长到 7-10 个开发者 时，我总会将它分为两个团队。不论是什么项目，10 人的团队都过于庞大，这时候你需要以子团队为行动单位。

  • 自然划分：团队划分应该很自然，需要能够明显地区分两个团队。
  • Pizza 原则：有个非常有名的原则叫做“Pizza 原则”，就是说：如果两张 Pizza 喂不饱你的团队，那么它太庞大了！
  • 沟通成本：记住，团队复杂度不是线性的，而是指数式的。当你有更多的员工、更多的团队，花费在沟通上的时间也就会更多。

组建方式

新团队的组建不能凑合，不是随便雇 5 个人就能称之为一个团队。最好的方式是“有丝分裂”（类似于举荐/内部推荐）。

关键角色：架构师与团队主管

首席架构师（Chief Architect）

如果你拥有多个团队，那么就需要有人来担当“首席架构师”一职。随着时间和团队人数的增长，这会很自然地成为一个任务。

  • 角色定位：首席架构师不需发号施令，这只是一个头衔，但总需要有人顶着这个头衔！记住，他绝不是“软件设计之神”。
  • 招聘影响：如果你真的认为架构师是“神”，你会失去招聘好员工的机会，因为好的员工应该对“什么是好的软件设计”有自己的观点。
  • 核心职责：这个角色更像是“软件设计协调者”，帮助所有人取得架构设计的共识。首席架构师如果做得称职会非常辛苦，因为他需要车前马后地与人辩论，并最终保证大家得到共识，但这正是关键！
  • 例外情况：如果你的公司非常大，就像财富 500 强那样，也许这时候你需要有一个能轻而易举地决定软件架构的“软件设计之神”，但我并没有这样的工作经验。

团队主管（Team Lead）

根据经验，最好还需要有一个“团队主管”。

  • 职责分离：这个职位应该从项目经理那里分离出来。经理负责绩效考核，主管负责帮助员工完成工作。
  • 灵活性：当然，团队主管的职责更应该依项目而定，有时甚至不是必须的。

团队文化与软管理

  • 磨合期：团队从组建到揉合一般需要 六周 时间。这仅仅是针对公司的正式员工，新员工融进团队的时间还会更长。
  • 化学反应：不要害怕修改团队的组织架构。和运动一样，队员间的化学反应非常重要！有些人在一起工作时能发出更高的工作效率。
  • 兴趣驱动：让员工做自己关心的事也很重要，致力于自己关心的工作通常也能带来更高的工作效率。我通常会安排合适的人去做他喜欢的工作。
  • 脏活轮值：当然，没有任何人愿意做的事，应该让所有人都轮流去做。如果你的团队是真正的团队，这就不会是什么问题，他们会愿意投入这些“肮脏”的工作。
  • 软管理（Soft Management）：最后，随着组织的增长，“软管理”会变得越来越重要。你需要将组织或者公司的使命、价值观、愿景这样的东西文档化，比如写在纸上或者 Wiki 上。只有愚蠢的老板会认为这是在浪费时间。
说明：本文原文发表于 2013 年，部分观点基于当时的开发环境。虽然敏捷开发与团队管理的基本原则依然适用，但在当今 DevOps 与远程协作普及的背景下，具体实践可能需要结合现代工程文化进行调整。