大型编程项目的组织架构

如果项目有n个工作人员，则有(n²- n)/ 2个相互交流的接口，有将近2n个必须合作的潜在团队。团队组织的目的是减少所需的交流和合作的数量，因此良好的团队组织是解决上述交流问题的关键措施。

减少交流的方法是人力划分(division of labor)和限定职责范围(specialization of function)。当使用人力划分和职责限定时，树状管理结构反映出对详细交流的需要会相应减少。

事实上，树状组织架构是作为权力和责任的结构出现。其基本原理—— 管理角色的非重复性—— 导致了管理结构是树状的。但是交流的结构并未限制得如此严格，树状结构几乎不能用来描述交流沟通，因为交流是通过网状结构进行的。在很多工程活动领域，树状模拟结构不能很精确地用于描述一般团队、特别工作组、委员会，甚至是矩阵结构组织。

让我们考虑一下树状编程队伍，以及要使它行之有效，每棵子树所必须具备的基本要素。它们是：

1. 任务(a mission)

2. 产品负责人(a producer)

3. 技术主管或结构师(a technical director or architect)

4. 进度(a schedule)

5. 人力的划分(a division of labor)

6. 各部分之间的接口定义(interface definitions among the parts)

所有这些是非常明显和约定俗成的，除了产品负责人和技术主管之间有一些区别。我们先分析一下两个角色，然后再考虑它们之间的关系。

产品负责人的角色是什么？他组建团队，划分工作及制定进度表。他争取，并一直保证必要的资源。这意味着他主要的工作是与团队外部进行向上的沟通和水平的沟通。他建立团队内部的沟通和报告方式。最后，他确保进度目标的实现，根据环境的变化调整资源和团队的构架。

那么技术主管的角色是什么？他对设计进行构思，识别系统的子部分，指明从外部看上去的样子，勾画它的内部结构。他提供整个设计的一致性和概念完整性；他控制系统的复杂程度。当某个技术问题出现时，他提供问题的解决方案，或者根据需要调整系统设计。用Al Capp所喜欢的一句谚语，他是“攻坚小组中的独行侠(inside-man at the skunk works)”。他的沟通交流在团队中是首要的。他的工作几乎完全是技术性的。

现在可以看到，这两种角色所需要的技能是非常不同的。这些技能可以按不同的方式进行组合。产品负责人和技术主管所拥有的特殊技能可以用不同方式组合，组合结果控制和支配了他们之间的关系。团队的搭建必须根据参与的人员来组织，而不是将人员纯粹地按照理论进行安排。

存在三种可能的关系，它们都在实践中得到了成功的应用。

产品负责人和技术主管是同一个人。这种方式可以非常容易地应用在小型的队伍中，这样的队伍可能有3~6个开发人员。在大型的项目中则不容易获得应用。原因有两个：第一，同时具有管理技能和技术技能的人很难找到。思考者很少，实干家更少，既是思考者又是实干家的太少了。

第二，大型项目中，每个角色都必须全职工作，甚至还要加班。对产品负责人来说，很难在承担全部管理责任的同时，还能抽出时间进行技术工作。对技术主管来说，很难在保证设计的概念完整性，没有任何妥协的前提下，担任管理工作。

产品负责人作为总指挥，技术主管充当其左右手。这种方法有一些困难。很难在技术主管不参与任何管理工作的同时，建立其在技术决策上的权威。

显然，产品负责人必须预先声明技术主管的技术权威，在即将出现的绝大部分测试用例中，他必须支持后者的技术决定。要达到这一点，产品责任人和技术主管必须在基本的技术理论上具有相似观点；他们必须在主要的技术问题出现之前，私下先讨论这些问题；产品责任人必须对技术主管的技术才能表现出尊重。

另外，还有一些技巧。例如，产品责任人可以通过一些微妙状态特征暗示(如，办公室的大小、地毯、装修、复印机等等)来体现技术主管的威信，尽管他身在管理团队之外，但他是决策的根源。

这种组合可以使工作很有效。不幸的是它很少被应用。不过，它至少有一个好处，即项目经理可以使用并不很擅长管理的技术天才来完成工作。

技术主管作为总指挥，产品负责人充当其左右手。Robert Heinlein在《出售月球的人》(The Man Who Sold the Moon)中，用一幅场景描述了这样的安排：

Coster低下头，双手捂着脸，接着，抬起头。“我知道。我了解需要做什么—— 但每次我试图解决技术问题时，总有些该死的笨蛋要我做一些关于卡车合同，或者客户电话，或者其他一些讨厌的事情。我很抱歉。Harriman先生，我原以为我可以处理好。”

Harriman非常温和地说：“Bob，别让这些事烦你。近来好像睡眠不大好，是吗？告诉你吧，我将在你的位子上干几天，为你搭建一个免于这些事情干扰的环境。我需要你的大脑工作在反向量、燃油效率和压力设计上，而不是卡车的合同。”Harriman走到门边，扫了一圈，点了一个可能是、也可能不是办公室主要职员的工作人员。“嘿，你！过来一下。”

那个人看上去有些惊慌，站了起来，走到门边说道，“什么事？”

“把角落上的那个桌子和上面所有的东西搬到本层楼的一个空的办公室去，马上。”

他监督着Coster和他的桌子移到另一个办公室，看了看，发现新办公室的电话没有接上。接着，想了一下，搬了一个长沙发过来。“今晚我们将安装一个投影仪、绘图仪、书架和其他一些东西，”他告诉Coster。“把你工程所需要的东西列一个表。”他回到了原来的总工程师办公室，愉快地想了想如何进行工作组织，以及是否有什么不妥。

过了四个小时，他带Berkeley进来，与Coster会面。这位总工程师正在他的桌子上睡觉，头枕在臂弯里。Harriman慢慢地退出去，但Coster醒了过来。“喔，对不起，”他有点不好意思地说，“我肯定是打了个瞌睡。”

“这就是我给你带来长沙发的原因，”Harriman说道。“它更加舒适。Bob，来见一下Jock Berkeley。他是你新的下属。你仍是总工程师，毫无疑问的老板。Jock负责打理其他事情。从现在起，除了建造登月飞船这样的微妙细节外，你不需要担心其他任何问题。”

他们握了一下手。“Coster先生，我只想问一件事，”Berkeley严肃地说，“所有你需要做的事，我都无权过问—— 你即将进行一个技术演示—— 但是看在上帝的份上，能否记录一下，从而让我了解一下。我将会把一个开关放在你的桌上，它会开启我桌上的一个密封的录像机。”

“好的！”Coster正看着他，Harriman想，够年轻的。

“如果要做任何非技术的事情，不需要自己动手。只需按一下按钮知会一声，就会有人把这些事情完成！”Berkeley扫了Harriman一眼。“老板说他想同你谈一谈实际的工作。我得先走，去忙去了。”他离开了。

Harriman坐了下来，Coster整了整衣服，说道：“喔！”

“感觉好一些了？”

“我喜欢Berkeley这小伙子的样子。”

“太好了！不用担心，他现在就是你的孪生兄弟。我以前用过他。你可以认为你正住在一个头等的疗养院里。”^[2]

这个故事几乎不需要任何的分析解释，这种安排同样能使工作非常有效。

我猜测最后一种安排对小型的团队是最好的选择，如同在第3章《外科手术队伍》一文中所述。对于真正大型项目中的一些开发队伍，我认为产品负责人作为管理者是更合适的安排。

巴比伦塔可能是第一个工程上的彻底失败，但它不是最后一个。交流和交流的结果—— 组织，是成功的关键。交流和组织的技能需要管理者仔细考虑，相关经验的积累和能力的提高同软件技术本身一样重要。