《人月神话》笔记：为什么巴比伦塔会失败

（本书非常精彩的一章^_^从巴比伦塔故事开始的）
现在整个大地都采用一种语言，只包括为数不多的单词。在一次从东方往西方迁徙的过程中，人们发现了苏美尔地区的一处平原，并在那里定居下来。接着他们奔走相告说：“来，让我们制造砖块，并他它们烧好。”于是，它们用砖块代替石头，用沥青代替灰泥（建造房屋）。然后，他们又说“来，让我们建造一座带有高塔的城市，这个塔将高达云霄，也将让我们声名远扬，同时，有了这个城市，我们就可以聚居在这里，再也不会分散在广阔的大地上了。”于是上帝决定下来看看人们建造的城市和高塔，看了以后，他说：“他们只是一个种族，使用一种的语言，如果他们一开始就能建造城市和高塔，那以后就没有什么难得倒他们了。来，让我们下去去，在他们的语言里制造些混淆，让他们相互之间不能听懂。”这样，上帝把人们分散到世界各地，于是他们不得不停止建造那座城市。

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

那么，既然他们具备了所有的这些条件，为什么项目还会失败呢？他们还缺乏些什么？两个方面——交流，以及交流的结果——组织。

（一）大型项目中的交流
团队如何进行相互之间的交流沟通呢？通过所有可能的途径。
    ● 非正式途径。
    比如，电话（当然还有email）。
    ● 会议。
    会议中，团队一个接一个地进行简要的技术陈述。这种方式非常有用，能澄清成百上千的细小误解。
    ● 工作手册

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

为什么需要项目工作手册？
技术说明几乎是必不可少的。
（其一，项目成员可以通过它了解项目的来龙去脉，更准确地知道项目的需求和要求。）
使用项目手册的第二个原因是控制信息的发布。控制信息发布并不是为了限制信息，而是确保信息能到达所有需要它的人手中。

项目工作手册的处理机制（更新、分发）
工作手册的实时更新是非常关键的。工作手册必须是最新的。（需要确保项目组成员能方便地获取、阅读工作手册。）

（三）大型编程项目的组织架构
我们先分析一下两个角色，然后再考虑它们之间的关系。
产品负责人（莫非指的就是项目经理？）的角色是什么？他组建团队，划分工作及制定进度表。他争取，并一直保证必要的资源。这意味着他主要的工作是与团队外部进行向上的沟通和水平的沟通。他组建团队内部的沟通和报告方式。最后，他确保进度目标的实现，根据环境的变化调整资源和团队的架构。
那么，技术主管的角色是什么呢？他对设计进行构思，识别系统的子部分，指明从外部看上去的样子，勾画它的内部结构。他提供整个设计的一致性和概念的完整性；他控制系统的复杂程度。当某个技术问题出现时，他提供问题的解决方案，或者根据需要调整系统设计。他的沟通交流在团队中是首要的。他的工作几乎完全是技术性的。

存在三种可能的关系，它们都在实践中得到了成功的应用。
    ● 产品负责人和技术主管是同一个人。
    这种方式可以非常容易地应用在小型队伍中，这样的队伍肯能只有3~6个开发人员。在大型的项目中则不容易获得应用。

    ● 产品负责人作为总指挥，技术主管充当其左右手。
    这种方法有一些困难。很难在技术主管不参与任何管理工作的同时，建立其在技术决策上的权威。这种组合可以使工作很有效。不幸的是它很少被应用。不过，它至少有一个好处，即项目经理可以使用并不很擅长管理的技术天才来完成工作。（这种方式比较适合大型的项目。）

    ● 技术主管作为总指挥，产品负责人充当其左右手。
    这种安排同样能使工作非常有效。这种安排对小型的团队是最好的选择。

（有一句不得不专门摘录下来，也就是本章的最后一段：）
巴比伦塔可能是第一个工程上的彻底失败，但它不是最后一个。交流和交流的结果——组织，是成功的关键。交流和组织的技能需要管理者仔细考虑，相关经验的积累和能力的提高同软件技术本身一样重要。