重读《人月神话》（4）-外科手术队伍（The Surgical Team）

问题

需要协作沟通的人员的数量影响着开发成本，因为成本的主要组成部分是相互的沟通和交流，以及更正沟通不当所引起的不良结果（系统调试）。这一点，也暗示系统应该由尽可能少的人员来开发。

【举例：】

让我们设想这样一个场景：在一个拥有200名成员的大型软件项目中，其中包含25位最具能力和经验丰富的项目经理。如果我们选择解雇剩余的175名程序员，并让这些高级经理亲自上阵进行编程工作，会怎样呢？

一方面，原有的开发队伍不是理想的小型强有力的团队，因为通常的共识是不超过 10 个人，而该团队规模如此之大，至少需要两层的管理，或者说大约 5 名管理人员。另外，它需要额外的财务、人员、空间、文秘和机器操作方面的支持。

另一方面，如果采用一拥而上的开发方法，那么原有 200 人的队伍仍然不足以开发真正的大型系统。例如OS/360操作系统——在其巅峰时期，曾有超过1000名工程师共同参与开发，在1963年至1966年间累计投入了约5000人年的工作量。显而易见，即使是200人的团队也远远不够，若按照常规速度推进，可能需要长达25年之久才能完成类似规模的项目。

在软件工程项目管理中，经常面临这样一个两难选择：一方面，小型且精干的团队被认为能够更有效地协同工作，从而实现更高的生产力与更好的成果质量；另一方面，对于那些规模庞大、复杂度极高的系统而言，仅靠少数精英显然无法在预期时间内完成开发任务。这背后隐藏了一个根本性的问题——如何在保持高效的同时应对大规模软件项目的挑战？

Mills 的建议

Harlan Mills 的提议提供了一个崭新的、创造性的解决方案。Mills 建议大型项目的每一个部分由一个团队解决，该队伍采用类似外科手术的方式组建：

10 人程序开发队伍的沟通模式

如何运作

一个由十人组成的小型团队往往面临着这样的情况：其中有七位专业人士致力于解决具体问题，而整个系统的构架却可能是由一到两位核心成员构思完成的。为了更好地理解这一点，我们可以借鉴医疗领域中的外科手术团队运作模式。

首先，在传统软件开发团队中，任务通常会被细分成多个部分，每位成员负责各自领域的设计与实现。这类似于外科手术过程中，主刀医生与助手都需要全面掌握手术方案及所有相关细节。然而，在软件开发过程中，这种分工方式虽然有助于明确责任范围，但也可能导致知识碎片化，使得整体视野受限。

相比之下，在外科手术团队中，成员间的角色定位更为清晰。尽管所有参与者都对手术流程有所了解，但在关键时刻，决策权集中于主刀医生手中。当团队内部出现意见分歧时，外科医生凭借其权威地位迅速作出最终判断，从而避免了冗长的讨论及妥协过程，确保手术顺利进行。这种“非民主”的决策机制保证了行动的一致性和高效性。

其次，高效的外科手术团队还依赖于其他成员高度专业化的职能分工。例如，麻醉师专注于患者生命体征监测，护士则负责器械传递等工作。这种精细化的角色分配使得沟通变得极为简洁明了，每个人都能专注于自己的职责范围内，无需过多干涉他人事务，进而提升了整体工作效率。

对于软件开发团队而言，借鉴这些原则可以帮助我们在保持灵活性的同时，提升项目执行的质量与速度。

团队的扩建

当我们需要面对几百人参与的大型任务时，如何应用外科手术团队的概念呢？

首先，分解技术依然是必不可少的。将一个庞大的任务拆分成若干个小模块。其次，让 200 人去解决问题，按“外科医生”的思路仅仅需要协调 20 个人。

像"外科手术队伍"精干的小型队伍这一理念很有价值。

两个比萨原则

亚马逊的“两个比萨原则”是由其创始人杰夫·贝索斯提出的一种独特的企业管理理念，旨在提高团队效率与创新能力。这一原则的核心思想是：一个团队应该小到可以用两个比萨就能满足所有成员的需求。也就是说，任何工作小组都不应该大到几个比萨都无法填饱所有人的肚子。