巴比伦塔的管理教训
通过巴比伦塔工程的失败，我们可以学到很多同软件工程相关的东西。首先我们先来评估这个项目所拥有的资源（先决条件）：
1. 清晰的目标？ 是的， 尽管幼稚得近乎不可能。 而且， 项目早在遇到这个基本的限制
之前，就已经失败了。
2. 人力？ 非常充足。
3. 材料？ 在美索不达米亚有着丰富的泥土和柏油沥青。
4. 足够的时间？ 没有任何时间限制的迹象。
5. 足够的技术？ 是的， 金字塔、 锥形的结构本身就是稳定的， 可以很好分散压力负载。
对砖石建筑技术，人们有过深刻的研究。 同样，项目远在达到技术限制之间， 就已经失败了。
那么，既然他们具备了所有的这些条件，为什么项目还会失败呢？他们还缺乏些什么？
两个方面——交流， 以及交流的结果——组织。 他们无法相互交谈， 从而无法合作。 当合作
无法进行时， 工作陷入瓶颈。
大型编程项目中的交流
一．非正式途径
清晰定义小组内部的相互关系和充分利用电话，能鼓励大量的电话沟通从而达到对所书写文档的共同理解。
二．会议
常规项目会议。会议中，团队一个接一个地进行简要的技术陈述。 这种方式非常有用，能澄清成百上千的细小误解。
三．工作手册
在项目的开始阶段，应该准备正式的项目工作手册。
工作手册是什么？
项目工作手册不是独立的一篇文档，它是对项目必须产出的一系列文档进行组织的一种结构。项目所有的文档都必须是该结构的一部分。这包括目的、外部规格说明、接口说明、技术标准、内部说明和管理备忘录。
为什么需要工作手册？技术说明几乎是必不可少的。如果某人就硬件和软件的某部分，去查看一系列相关的用户手册。 他发现的不仅仅是思路， 而且还有能追溯到最早备忘录的许多文字和章节， 这些备忘录对产品提出建议或者解释设计。 对于技术作者而言， 文章的剪裁粘贴与钢笔一样有用
巴比伦塔可能是第一个工程上的彻底失败，但它不是最后一个。交流和交流的结果—组织， 是成功的关键。 交流和组织的技能需要管理者仔细考虑， 相关经验的积累和能力的提高同软件技术本身一样重要。