21世纪的“外科手术团队”

免责声明

本文是我个人对软件开发应如何组织的一些看法。本文并非旨在成为一篇学术论文，因此许多陈述为了简洁而故意使用了非常明确和直接的表达方式。我已尽力根据自己的观察和现有资料来介绍这种方法，但我并非商业理论家、专业经理人或社会学家，我可能完全错了。此外，本文不可避免地是从开发人员/架构师的角度撰写的，我也对其他观点持开放态度。我也还没有机会完全按照所描述的那样去实践，所以请带着一定的怀疑态度看待本文。

原始的“外科手术团队”

在弗雷德·布鲁克斯（Fred Brooks）不朽的著作《人月神话》中，他引用哈兰·米尔斯（Harlan Mills）的观点，提出了处理软件开发的最佳团队结构。他建议，“一个大项目中的每个部分都应由一个团队来承担，但这个团队的组织方式应像外科手术团队，而不是屠宰场团队。也就是说，不是团队中的每个人都在独立地处理问题，而是由一个人进行切割，其他人则为他提供一切支持，以增强他的效率和生产力。”

图1展示了建议的团队结构。我添加了“客户”，这显然是原始概念中缺失的。

布鲁克斯进一步描述了成员的角色如下：

“**外科医生** […]（首席程序员）[…]亲自定义功能和性能规范，设计程序，编写代码，进行测试，并撰写文档。” 他还决定与谁合作。他的能力至关重要。

“**副驾驶** […]是外科医生的分身[…]。他的主要职能是作为思想家、讨论者和评估者参与设计。外科医生会向他尝试一些想法，但不受他建议的约束。他对所有代码都非常熟悉。他研究替代的设计策略。他 […]充当外科医生出现意外时的保障。”

“**管理员** […]负责处理金钱、人员、空间和机器，以及[…]与组织行政机构的接口。”

“**编辑**负责将外科医生产生的[文档草稿]进行批评、重写、提供参考文献和书目，经过几个版本进行完善，并监督制作过程。”

“两名**秘书** […]负责处理项目通信和非产品文件。”

“**程序文员** [负责]维护团队在编程产品库中的所有技术记录。[他负责]机器可读和人类可读的文件。”

“**工具匠** […]负责[…]构建、维护和升级其团队所需的专用工具—主要是交互式计算机服务。工具构建者通常会构建专用工具、目录过程、宏库。”

“**测试员** […]既是根据功能规范设计系统测试用例的对手，也是为日常调试设计测试数据的助手。他还会规划测试序列并设置组件测试所需的脚手架。”

“**语言律师** [是]一种编程语言的[大师]。[他]可以找到一种巧妙而高效的使用语言的方法 […][通过]进行小规模研究 […]关于好的技术。”

与同行团队不同的是，“合作伙伴会分担工作，每个人都负责一部分工作的设计和实现。而在外科手术团队中，外科医生和副驾驶[拥有]全部设计和全部代码。这节省了分配[职责]的劳动，并确保了工作的概念完整性。” 此外，“传统团队中的伙伴是平等的，不可避免的[利益和]判断差异必须通过讨论或妥协来解决。[…]在外科手术团队中，没有利益差异，判断差异由外科医生[独自]解决。这两种差异——问题没有被分解以及上下级关系——使得外科手术团队能够[像一个人一样]行动，而团队其余成员的功能专业化是其效率的关键，因为它使得成员之间的沟通模式大大简化。”

现代“外科手术团队”

布鲁克斯的书出版以来已经过去了二十多年。考虑到技术进步，原始模型可以调整为图2所示。

在现代“外科手术团队”中，秘书、编辑和语言律师已被硬件和软件的结合所取代，这使得团队的技术成员数量得以增加，从而提高了其吞吐量。现代“外科手术团队”成员的角色如下：

**架构师**“亲自定义功能和性能规范，设计程序[… ]并撰写文档。”此外，他将架构变更分解为工作单元并分配给团队成员。他不断与开发人员和测试人员就设计进行协商，尽管他应尊重他们的反馈，但最终决定权在他。他可以自己编写代码，但如果他审查并批准合并请求，则不一定需要。他可能不是执行代码合并的人，但他必须拥有否决权，并且这种否决权应该得到尊重。架构师应具备**至少一些“人际交往能力”**（个性特征如较高的经验开放性、中等外向性、较低到中等的神经质和中等的宜人性会有帮助，但可以通过有意识的努力在一定程度上弥补），并且**技术能力至关重要**，因为他负责预测和避免未来的技术问题（架构师在概念上相当于丰田的“shusa”）。理想情况下，作为经验最丰富的人，他应该对招聘和解雇其他团队成员有影响。如果整个团队表现不佳，高层管理人员应**解雇架构师**，并让新的架构师**重组团队**（体育界也使用同样的方法，教练对团队的表现负全部责任）。

**管理员**通常执行与原始模型相同的职责。此外，他负责执行流程（如SCRUM Master），收集状态报告并维护工作积压。尽管他是架构师的下属，但他们应该协同工作，因为他们是互补的。管理员应具备高水平的“人际交往能力”以弥补架构师可能存在的不足。此外，更加有序和保守（高度尽责和较低的经验开放性）应该有助于平衡架构师（可能的）混乱的创造力，并促进可持续的节奏和流程。架构师和管理员都应将团队与不必要的沟通负担隔离开来，但又不限制团队内部或与其他团队的沟通。

**开发人员**负责编写解决方案。虽然图中未显示，但他们应该根据能力、才华和经验拥有自己的层级。重要的是，至少有一位开发人员能够在危机中替代架构师。

**测试人员**负责设计和自动化系统测试。与开发人员一样，他们应该拥有自己的层级。重要的是，至少有一位测试人员要对正在构建的软件有整体的理解，以便向架构师提供高质量的反馈。测试人员虽然技术能力很强，但很少担任架构师的替代者，因为他们拥有不同的思维模式（构建与破坏）。

**自动化工程师**的职责通常与工具匠相同。此外，如果需要构建和维护硬件原型和测试设备，他应负责。

精英管理

所提出的方法基于四个支柱：

• 能力
• 层级
• 所有权，和
• 尊重

我在《软件开发作为价值领域的研究》和《软件项目失败的心理原因》中已经写过关于能力是软件开发关键基础的内容。

与敏捷软件开发，特别是极限编程不同，我坚持认为层级是人类固有的。人们倾向于接受建立在能力之上的层级，因此不应抗拒它，而应加以利用，因为有了层级，所有权自然而然地随之而来。正如杰拉尔德·M·温伯格（Gerald M. Weinberg）所说：“考虑团队的工作分为两类很有用——致力于实现团队目标的工作和致力于维护团队有效运作的工作[…]。对于社会心理学家来说，这些活动分别被指定为‘任务导向’和‘维护导向’[…]。在某些类型的群体中，并且在编程团队中很常见，群体倾向于选择两个互补的领导者——一个任务专家，负责分配和协调工作；以及一个维护专家，负责解决群体成员之间或个人目标与群体目标之间的冲突。指定领导者，由于他在将外部目标带入团队方面的作用，最常处于任务专家职位，尽管我们知道，如果他未能展现必要的能力，他可能会被群体替换。维护专家——他最有可能成为群体中最有技能的人——可以来自任何地方。他可能不是一个很好的程序员，尽管他也可能如此。他很可能是个女人。”

在对核心家庭的跨文化研究——父亲、母亲和他们的孩子——中，这种任务和维护活动的分工至少在文化理想中通常是存在的。在大多数文化中，包括我们的[…]，理想的父亲是任务专家，理想的母亲是维护专家。”

就像在家庭或部落中一样，现代“外科手术团队”中的层级应建立在能力、才华和天赋之上，并划分明确的职责，以加强对特定工作单元的所有权观念。

在21世纪的外科手术团队中，每个产物都应有一个指定的拥有者。拥有权随之而来的是产物质量的责任，其质量由使用它的人来评估（例如，设计的消费者是开发人员，代码的消费者是需要审查或与之交互的其他开发人员）。极限编程所提倡的共同所有权只有在高度稳定的、有能力的团队中，并且在成员之间建立了人际关系（即友谊）并感到有义务互相支持的情况下，才能作为个人所有权的最高形式出现。在其他情况下，集体所有权将导致公地悲剧，由社会惰化引起。每个团队成员将以最小的努力完成任务，将低质量的后果推给他人（产品产物的质量成为“公地”）。这也是为什么软件开发外包无法提供高质量解决方案的原因。

最后一个支柱是尊重。架构师和管理员不应将开发人员、测试人员和自动化工程师视为可替换的“螺丝钉”（即“资源”）。架构师作为团队的领头人需要知识渊博且经验丰富，但这并不意味着开发人员或测试人员不是。通常，开发人员（或测试人员或自动化工程师）与架构师之间的唯一区别在于，后者愿意将设计写下来，而前者同样有才华、知识渊博且经验丰富，却“专注于代码”。没有相互尊重，团队将无法非常有效，因为内部冲突会不断地将其撕裂。不幸的是，真正的尊重需要诚实地赢得，这使得团队组建过程成为一项挑战。

资源是效率的关键要素

外科手术团队构成了一个组织中一个连贯、独立、有生命力的单位。就像复杂生物体中的细胞一样，它有自己的身份和议程。为了高效工作，它不仅需要稳定的物理环境（温度、压力、湿度等），还需要有盈余的营养物质。在这种情况下，“盈余”并不意味着“无限”，而是“随时可用”。身体细胞主要独立运作，只需从周围的体液中摄取营养物质，而无需获得中央权威的许可。同时，身体中不太核心的权威只需确保循环中的营养物质水平保持相对稳定。这是一个非常简单有效的系统，沟通最少，监管开销很轻。

在制造业领域，这个想法体现在大野耐一（Taiichi Ohno）的“库存超市”。在软件开发领域，这个想法可以非常简单地实现，因为大部分所需库存都可以快速购买。这意味着，为了让它发挥作用，外科手术团队应管理自己的库存预算，形式是管理员持有的公司信用卡。每当团队需要任何东西（无论是硬件、软件、云服务、培训、商务旅行，还是仅仅是汽水和比萨）时，都应该能够直接购买，而无需组织其他部门的批准（因为采购流程可能需要数月）。为了控制开支，年支出上限+收据应该足够了。

规模化

扩大解决方案规模需要多次重复层级模式，如图3所示。重要的是要保留层级结构，由首席架构师居于顶端，完全负责整个产品，并由产品管理员作为他的下属对等者。这形成了一个工程师驱动的组织，责任追随技术能力。

在描绘的情况下，日常沟通主要发生在管理员之间，而技术/战略沟通主要发生在架构师和产品所有者/分析师之间。这使得每个人都能专注于其核心职责。

为了使这种组织结构有效，它**需要遵循产品的技术结构**（反向康威法则），以便人际沟通路径跟随软件沟通路径。到目前为止最有效的方法是采用一组“文档”，这些文档遵循并支持统一的组织技术结构，如图4所示（正如温斯顿·W·罗伊斯（Winston W. Royce）所说：“管理软件开发的第一条规则是残酷执行文档要求。”）。

图示的“文档”不需要正式化为纸质形式或任何文档格式（例如，产品待办事项列表是在产品生命周期中积极维护的一组记录），但所有权和引用顺序需要清晰。

稳定的团队很重要

弗雷德·布鲁克斯（Fred Brooks）将概念完整性指定为软件系统的主要质量。据他所说，这只有在系统由一个人或一个紧密合作的小团体设计时才能实现。对于架构师、开发人员和测试人员来说，拥有整个系统/子系统的知识也有很大的性能优势。通过长期从事同一个产品，人们不仅能迅速获得技术知识，还能获得领域知识，从而减少必要的沟通，并加快每天需要做出的所有小决策。在产品之间调动人员通常会对此产生重大影响，因为人们保留信息的能力是有限的。

最有害的业务策略之一是将人视为“现成可替换的资源”，并经常在产品/子系统之间调动他们，以提供100%的利用率。这种策略几乎总是适得其反（这里对这种现象有很好的解释），因为如图5所示，每个被调到新产品的人都需要一个适应期才能变得有生产力。这个适应期通常足够长，其成本（以生产力损失衡量）超过了让这个人暂时空闲的成本。

在人员流动方面还有另一个（长期的）成本。调动人员需要他们反复地将大量知识和信息重新加载到大脑中。虽然年轻人可能能够快速做到这一点，但对于年长者来说并非如此，他们希望从对某个子系统或应用程序的深入了解中获得长期收益。在稳定的团队中，人们可以通过降低每单位生产力的努力来将获得的知识货币化，如图6所示。

在图7中描绘了在团队切换情况下，努力与生产力之比。

在这种情况下，努力与生产力之比始终很高。这会造成智力疲劳，影响绩效和动力。如果这种情况持续下去，人们会意识到这种精神疲劳不值得，然后会换一份不太累的工作。这对公司来说是双倍的生产力损失。此外，在产品/子系统之间频繁调动开发人员/架构师会让他们倾向于短期而非长期收益。换句话说，质量会直线下降，因为他们将不会是未来从中受益的人。

在产品之间调动开发人员的最后一个负面方面是，它使得满足开发人员的基本需求变得不可能。我在《软件开发作为价值领域的研究》中写道，开发人员的基本需求是收入、自主权、精通和目标。在同一个产品上工作更长时间可以让开发人员对其产生情感依恋。看着它随着时间的推移通过有用的功能而成长，满足了目标的需求。能够逐步改进它满足了精通的需求。能够规划并执行开发路线图满足了自主权的需求。所有这些都放大了所有权、责任感和自豪感。然后这些都消失了，剩下的只是成为一个可替换的齿轮的沉闷感觉。质量下降，士气下降，开发人员流失增加，侵蚀就开始了。

小型团队很重要

原始的“外科手术团队”由10人组成。人们多次观察到，最有效的团队由5到9人组成，最大人数约为12人，超过此人数团队会自然分裂成更小的团队。另一个启示是普莱斯定律，该定律指出，在创造性工作中，一半的产出来自于所有贡献者数量的平方根。在新“外科手术团队”中，他们应该是架构师、高级开发人员和高级测试人员。

规模化限制

“规模化的外科手术团队”方法有其局限性。考虑到每个层级最多有12名下属，最大的有效系统开发团队最多只能由约122人组成，形成三个层级，如图3所示（10个12人的团队 + 首席架构师 + 产品管理员），这与“邓巴数”大致吻合。在此人数范围内，每位架构师都可以根据需要直接参与代码编写，并且首席架构师可以支持或临时替代任何架构师（或在极端紧急情况下甚至参与代码编写）。在这种情况下，每个主管实际上都可以完成他负责完成的工作。

将人数推高到此点之上将导致两种结果。保持扁平的层级结构会使团队规模超过12人，并导致它们自然分裂成子团队，从而减少团队内部合作。这也会超出架构师的管理能力。这种降低的团队完整性会对生产力产生非线性影响（增加团队成员不仅会收益递减，甚至会产生负面的生产力影响）。另一方面，构建层级结构需要引入中层管理，这会将首席架构师与所构建的解决方案分离，并在组织中引入真相的温床。此外，很难精确地将职责分配给中层管理者（中层架构师？），因为他们通常不与系统架构对齐。在这种情况下，中层管理者需要通过印象而非结果来证明其职位合理性，产生信息噪音。此时，办公室政治通常会启动，并对公司产生负面影响。

“规模化的外科手术团队”的规模限制并不限制公司的规模。一家公司可以通过雇佣许多**大部分自主的**“规模化的外科手术团队”来开发许多独立的产品（系统）。为了成功，每个产品都需要有**独立的发布周期**，以避免昂贵的协调，并且每个“规模化的外科手术团队”都需要将产品间的集成视为与第三方产品集成，通过狭窄、明确定义、稳定且向后兼容的API进行（高质量的设计在这里很重要），如图8所示。

公司应该有一个非常通用的愿景，关于产品在其生命周期中如何互操作（一个路线图），但应该广泛接受暂时的分歧。换句话说，应该普遍接受在任何时候某些东西都不会以最佳方式或预期的方式工作。这是产品套件的感知质量与常常令人望而却步的紧密产品间协调成本之间的权衡，后者会导致同步发布。

多少产品？

为了回答这个问题，我们假设每个产品在其生命周期中可以朝着少数几个相互排斥的方向发展（例如，2个）。为了使其更具体，让我们想象一个后端数据存储服务可以开发成更像数据库，或者更像消息代理，但实际上不能同时兼顾。现在，假设一个公司有少量互操作的产品（例如，4个）。有了这些数字，我们就有 2*4 = 8 种整个套件的可能路线图可供分析。这是一个可管理的数字，但残酷的真相是，由于每个产品很可能需要与其他所有产品合作，因此需要分析的可能系统排列的数量是 4*4*2 = 32，或者更一般地：

产品数量**² * 每个产品的平均可能方向数。

由于二次函数增长迅速，因此需要分析的可能排列数量，即使对于小数字，也很快会超出人类认知能力。这意味着每个公司互操作的产品数量应该是“屈指可数”的。当然，如果产品完全独立，则上述限制不适用。

历史

• 2020年9月11日：初始版本