重读《人月神话》（8）-为什么巴比伦塔会失败？（Why Did the Tower of Babel Fail?）

据《创世纪》记载，巴比伦塔是人类继诺亚方舟之后的第二大工程壮举，但巴比伦塔同时也是第一个彻底失败的工程。

巴比伦塔的管理教训

这个项目具备了几乎所有成功的先决条件：

• 有清晰的目标，尽管目标理想化到了近乎不可实现的地步；

• 人力资源非常充足；

• 材料资源丰富，如美索不达米亚地区的泥土和柏油沥青；

• 时间上也没有明显的限制；

• 技术方面同样不成问题，金字塔和锥形结构本身具备良好的稳定性，能够有效分散压力，砖石建筑技术经过了深入研究。

然而，项目在触及这些基本限制之前就已经宣告失败。

究其原因，项目欠缺的是两个至关重要的因素：有效的沟通与合理的组织。缺乏沟通意味着无法有效地协作，一旦合作受阻，工程便停滞不前。从历史记载中可以推断，沟通不足导致了大量的争论、沮丧情绪以及集体间的猜疑。很快，原本团结的部落开始分化，成员们宁愿选择孤立也不愿意继续无休止的争执。

大型编程项目中的交流

如今，类似的问题依然存在。由于团队内部缺乏有效的沟通，导致了进度延误、功能不合理和系统缺陷频出。各个小组在工作中逐渐调整了自己的程序功能、规模和速度，这些调整或明或暗地改变了输入输出约定。

例如，负责程序覆盖功能的团队发现该功能使用率低，于是降低了其执行速度。然而，这一变动直接影响到了正在设计依赖该功能的监控程序的其他同事。因此，这类变更需要从系统整体的角度来评估，并且应该公开透明地发布变更信息。

团队应如何加强彼此间的沟通？需通过一切可能的渠道进行：会议、电话、工作手册等。现如今我们有了更方便的文字处理和文档协作工具，但保持文档的更新和有效获取仍然很重要。

项目工作手册

项目工作手册并非单一文档，而是对一系列必需产出的文档进行组织的结构，涵盖了目的、外部规格说明、接口说明、技术标准、内部说明和管理备忘录等内容。良好的文档结构不仅便于追踪设计思路，还有助于未来产品的文档编制。合理设计工作手册，确保文档有序且信息更新及时，便于检索。

项目工作手册的另一个重要作用在于控制信息发布，确保信息准确传达至需要的人手中。通过编号备忘录和树状索引结构，可以提高信息检索效率。随着项目规模的扩大，文档管理难度呈指数级上升。采用活页夹和计算机编辑系统可以帮助实时更新文档，通过标记变更内容和附带变更摘要来减少理解障碍。

当文档量庞大时，使用微缩胶片可以有效减少存储空间，并简化归档工作。然而，微缩胶片不便标注与批注，作为补充手段较为合适。现代技术中，直接访问文件并记录修订日期和变更标识是可行的选择，用户可通过显示终端查阅更新，维护变更小结以便随时查看。

工作手册的本质并未改变，仍是项目文档的集合，但分发机制和查询方法的改进有助于提升工作效率。精确完整的接口定义能进一步优化文档管理，有助于预防和纠正接口错误。

大型编程项目的组织架构

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

减少沟通障碍的方法是通过人力分工和职能专业化。当实行分工和职能专业化时，树状管理结构所需的详细沟通就会减少。实际上，树状结构反映了权力和责任的分配，但沟通结构更加网状，不受此限制。

考虑一个树状编程团队及其有效运作所需的要素：

1. 任务；

2. 产品负责人；

3. 技术主管或架构师；

4. 时间表；

5. 人力分工；

6. 接口定义。

其中，产品负责人和技术主管的角色尤其重要。产品负责人负责团队构建、资源配置和进度管理，主要与外部沟通；技术主管则专注于设计和技术问题解决，确保设计的一致性和完整性，主要在团队内部沟通。

这两种角色需要不同的技能组合。在小型团队中，一人身兼多职较为常见，但在大型项目中，这几乎不可能实现，因为同时具备管理和技术能力的人才稀缺，且每个角色都需要全职投入。

另一种模式是产品负责人作为领导者，技术主管作为助手。此模式要求产品负责人支持技术主管的技术决策，并在团队中建立技术主管的权威。第三种模式是技术主管作为领导者，产品负责人作为助手，这种模式在大型项目中较为有效。

巴比伦塔可能是最早的工程失败案例之一，但它不是最后一个。沟通和由此产生的组织是成功的关键，管理者必须重视沟通和组织技能的培养，正如重视软件技术的发展一样。