我第一次听说“外科手术式团队”是在《人月神话》中：

“Harlan Mills建议大型项目的每一个部分由一个团队解决，但是该队伍以类似外科手术的方式组建，而非一拥而上。也就是说，同每个成员截取问题某个部分的做法相反，由一个人来完成问题的分解，其他人给予他所需要的支持，以提高效率和生产力”。

用下面这张图可以更直观的理解这个“外科手术团队”的组织方式（图中的“外科医生”、“副手”等的职责分工这里就不赘述了，翻翻《人月神话》或者上网查查就清楚了。）：

角色

当然，我们实际中的外科手术团队不会有这么多专门的角色，一般都是一人身兼多职。

例如，有一个团队中，项目经理承担了“管理员”和“编辑”的角色，承担了几乎全部的对外工作——和“外科医生”一起与业务部门探讨核心业务方向与逻辑、与行政部门沟通职场/调休/考勤等问题、与领导沟通汇报项目进度等等，从而让其他人得以专注于自己所擅长的和承担的团队内部工作。

有时候，团队成员也会在不同的角色之间“轮岗”，最常见的就是大家轮流来做“工具维护人员”或者“编辑”，我们也曾尝试过轮流来做“副手”甚至在某些比较小的功能需求上轮流做“外科医生”，以期锻炼团队、培养后备人才，效果也还不错。

外科医生

不管怎样分配角色，既然是“外科手是团队”，就一定会有“外科医生”。《人月神话》将这个角色称为“首席程序员”，我们今天一般称为“架构师”。

这个角色一般是由团队中技术最好、最熟悉业务的人来承担。这二者缺一不可。光是技术好却不熟悉业务，很容易做出技术华丽、但不适合业务的方案来。而熟悉业务但技术能力一般的话，则常有心有余而力不足之憾。

“外科医生”往往也是“编程语言专家”，或者更宽泛一点来说，往往也是“技术专家”。一方面，如前所说，“外科医生”一般会由团队中技术最好的人来担任，技术最好的人很自然会成为“编程语言专家”或“技术专家”；另一方面，作为没有正式任命、因而也没有真正的上级对下属的权力的“外科医生”，出类拔萃的技术能力带来的权威和领导力是他一切权力的来源，因而他也必须让自己成为“编程语言专家”和“技术专家”。

副手

但是，“外科医生”无法兼任“副手”。

“副手”这个角色有两重意义：一方面是为“外科医生”提供参谋和建议，另一方面则是作为后备的“外科医生”，在必要时接手部分甚至全部的工作。

这个角色适合团队中对技术或业务有一方面突出、但另一方面略有不足的成员。这样，他们可以用自己突出的一方面为“外科医生”提供帮助，也可以通过向“外科医生”学习来弥补自己不足的一面。

有那么两个团队，那些出色的“副手”们在“外科医生”离开后顺利的接过了接力棒，不仅保证了项目有条不紊的继续推进，而且自己也多次获得公司的嘉奖（有些奖项甚至是原先的“外科医生”都没有得过的哈哈哈）。

管理员

对程序员来说，与人沟通常常是件非常麻烦而头疼的事情，比调试一万行代码都麻烦和头疼。跨团队甚至跨部门的沟通就更不用说了。如果是频繁的被打断，更加令人烦躁不安。

因此，在团队中设立一个“管理员”角色是非常必要的。他需要负责团队成员内与团队之外的沟通与协调，从而把团队成员解放出来，使其能专注于自己在项目中的工作。

这个角色一般也不适合由“外科医生”兼任，在我所接触过的团队中，一般是由产品经理甚至项目经理来扮演“管理员”的橘色——这时，除了报销、考勤等工作外，与沟通业务需求、对接其他项目团队、向领导汇报计划和进度等，也会由他们一并处理。

但是这种情况下，“管理员”和“外科医生”必须合作无间，否则容易出现内耗。

优点和缺点

优点

外科手术团队的最大优点在于：一个好的“外科医生”可以把项目、系统和团队带领到也许是前所未有的高度上。

“外科医生”可以把项目方向统一在一个正确的轨道上，把系统质量控制在较高的水平上，也能让团队成员水平芝麻开花节节高。上次做业务系统优化改造时，我们团队就是一个外科手术团队。这位尽职尽责的“外科医生”花了一个月时间分析业务、老系统，并反复地与团队成员讨论技术和业务、讲解他的优化升级思路，最终提出了一个非常优秀的系统架构方案。在开发过程中，这位“外科医生”担纲编写了新系统的核心框架，并牵头推动团队的设计评审、代码评审和技术分享，不仅使得系统质量保持在一个较高水准，同时也让团队成员获益匪浅。可以说，没有这位“外科医生”，这个业务系统优化改造项目不会有最后的成功。

当然，要取得这样的成功，需要万事俱备、不欠东风：“外科医生”自身水平高、态度好，团队内、外工作能够顺利开展，团队成员也能积极跟上他的节奏，等等。如果这些条件有所欠缺——例如“外科医生”水平不行、做出了错误的设计，或者团队成员不配合、虽有好的方案却执行不下去，那么项目前途就一片灰暗了。

我们有过一支团队，开始时还一切顺利，但是随着“外科医生”态度转变——她渐渐地倦怠了，对项目、系统和团队问题基本都以“嗯”“就这样吧”“都行”来应付——系统以肉眼可见的速度开始“腐化”，项目逐渐失去了方向和控制。这也算是“人治”这把双刃剑的效果吧。

但是，也有办法可以预防或者避免这类问题。首先，“外科医生”的选任上，应当选择技术、业务和工作态度都是团队内的顶尖的那位。这样一位人才，可以让项目和团队攀登到“人治”的巅峰。此外，团队里还有“副手”、还有“管理员”，他们是与“外科医生”一起工作的。预防“外科医生”犯下这样那样的错误，或在“外科医生”无法承担职责时接替他的工作，就是“副手”的职责之一，也许是最重要的职责了；而“外科医生”处理团队内外的协调、沟通工作时，有时需要“管理员”来充当润滑油。我们那位担任“管理员”的项目经理就为“外科医生”和业务部门之间的沟通协调做了很好的协调和缓冲，没有她的话我们那位脾气急的“外科医生”恐怕分分钟要和业务同事拍桌子吵起来。

外科手术团队还有其它的一些优点。这种团队成与大多数团队的人员组成是相似的：若干产品人员担任“管理员”，一位资深或高级研发担任“外科医生”，几位中级研发担任“副手”，几位中级和初级研发担任“程序职员”、“工具维护人员”，再加上几位QA同事充当“测试人员”。这种产品、资深、高/中/初级研发、QA的人员搭配可以说是大部分团队的标配了。因此，在现有团队基础上组织外科手术团队，可以说是水到渠成的。

之所以说是水到渠成，还有一个原因在于，组织外科手术团队不需要像敏捷或精益团队那样增加工作流程、提高管理成本。相反的，外科手术团队会把大部分全局性的、管理性的工作交给“外科医生”和“管理员”处理，其他人专注于分配给自己的工作，从而提高个人和团队的工作效率，也便于“外科医生”和“管理员”了解和把控项目进度。 这也是外科手术团队的一个优点：整体上付出较小的管理成本，获得工作效率的大幅提升。当然，虽然整体上的管理成本不高，但是对“外科医生”和“管理员”来说，他们投入的时间精力可能要成倍地增加。这也是外科手术团队需要解决的一个问题。

缺点

对外科手术团队来说，最大的困难不是“外科医生”的选任。所谓“十室之邑必有忠信”，无论有没有正式任命，每一支团队必定都有一个这样的角色。也不是团队内、外的协调沟通，即使同层级上沟通不来，也可以由更高层来处理——就像孙悟空搞不定的妖怪可以请观世音如来佛出山一样。

最困难的是让团队成员也能积极跟上“外科医生”，让团队成员——包括“副手”、“管理员”等——愿意主动的遵循他的要求、理解他的思路、跟上他的节奏：这是我过往的团队经验中最困难的一项工作。只有把这项工作做好，“外科医生”提出的一切的项目和系统的方向、规划才有可能变成现实。毕竟，仅靠“外科医生”一个人，写不完系统的全部代码、做不了项目的全部工作。

但是，在调动团队成员的积极性方面，据我的经验来看，外科医生团队往往不如敏捷团队做得好。不过这个下次再说吧。