《人月神话》-巴比伦塔为什么会失败？

1.巴比伦塔的管理教训

这个故事在很多方面和不同层次都是非常深刻和富有教育意义的。让我们将它仅仅作 为纯粹的工程项目，来看看有什么值得学习的教训。这个项目到底有多好的先决条件？他们 是否有：
（1） 清晰的目标？是的，尽管幼稚得近乎不可能。而且，项目早在遇到这个基本的限制 之前，就已经失败了。
（2）人力？非常充足。
（3）材料？在美索不达米亚有着丰富的泥土和柏油沥青。
（4）足够的时间？没有任何时间限制的迹象。
（5）足够的技术？是的，金字塔、锥形的结构本身就是稳定的，可以很好分散压力负载。 对砖石建筑技术，人们有过深刻的研究。同样，项目远在达到技术限制之间，就已经失败了。

那么，既然他们具备了所有的这些条件，为什么项目还会失败呢？他们还缺乏些什么？ 两个方面：交流，以及交流的结果—— 组织。他们无法相互交谈，从而无法合作。当合作无法进行时，工作陷入了停顿。通过史书的字里行间，我们推测交流的缺乏导致了争辩、沮丧和群体猜忌。很快，部落开始分，大家选择了孤立，而不是互相争吵。

2.大型编程项目中的交流

团队如何进行相互之间的交流沟通呢？通过所有可能的途径。

（1）非正式途径
清晰定义小组内部的相互关系和充分利用电话，能鼓励大量的电话沟通，从而达到对 所书写文档的共同理解。

（2）会议
常规项目会议。会议中，团队一个接一个地进行简要的技术陈述。这种方式非常有用，能澄清成百上千的细小误解。

（3）工作手册。
在项目的开始阶段，应该准备正式的项目工作手册。

3.项目工作手册

项目工作手册不是独立的一篇文档，它是对项目必须产出的一系列文档进行 组织的一种结构。 项目所有的文档都必须是该结构的一部分。这包括目的、外部规格说明、接口说明、 技术标准、内部说明和管理备忘录。

技术说明几乎是必不可少的。如果某人就硬件和软件的某部分，去查看一系列相关的用户手册。他发现的不仅仅是思路，而且还有能追溯到最早备忘录的许多文字和章节，这些备忘录对产品提出建议或者解释设计。对于技术作者而言，文章的剪裁粘贴与钢笔一样有用。

使用项目手册的第二个原因是控制信息发布。控制信息发布并不是为了限制信息，而是确保信息能到达所有需要它的人的手中。

4.大型编程项目的组织架构

树状组织架构是作为权力和责任的结构出现。其基本原理——管理角色的非重复性导致了管理结构是树状的。但是交流的结构并未限制得如此严格，树状结构几乎不能用来描述交流沟通，因为交流是通过网状结构进行的。在很多工程活动领域，树状模拟 结构不能很精确地用于描述一般团队、特别工作组、委员会，甚至是矩阵结构组织。
让我们考虑一下树状编程队伍，以及要使它行之有效，每棵子树所必须具备的基本要 素。它们是：

（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）

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

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

那么技术主管的角色是什么？他对设计进行构思，识别系统的子部分，指明从外部看 上去的样子，勾画它的内部结构。他提供整个设计的一致性和概念完整性；他控制系统的复 杂程度。当某个技术问题出现时，他提供问题的解决方案，或者根据需要调整系统设计。

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

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

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

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

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

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