巴比伦塔的管理教训
《创世纪》中记载，巴比伦塔是人类继诺亚方舟后的第二大工程壮举，也是一个彻底失败的工程。这个项目是全人类一起搭建一个高塔，按理说项目的目标非常清晰，人力也十分充足，优质的材料用之不尽，而且时间足够长是具备非常好的先决条件的，唯一的缺陷可能是当时的建筑技术不足以支持人们建那么高的塔，可是，项目在达到技术限制之前就早早的失败了。
原因很简单，因为突然有一天人们开始使用不同的语言，导致的整个团体缺乏交流，而缺乏交流就导致了争辩、沮丧和群体的猜忌。很快，人类开始分裂，大家不约而同的选择了孤立，甚至连争吵都没有意义了。那巴比伦塔的项目自然也就失败了，在这个过程中，导致失败的主要原因有两个方面，一个是缺乏交流，另一个是缺乏交流之后形成的组织。
大型编程项目中的交流
缺乏交流的项目，往往容易产生进度缓慢、功能不合理和系统缺陷等问题，那么团队应该如何沟通那个呢？
- 非正式途径：清晰的定义小组内部的相互关系，鼓励大量的电话沟通
- 会议：常规项目会议，团队一个接一个的做技术称述
- 工作手册：项目开始阶段应该准备正式的工作手册
项目工作手册
项目手册也就是我们现在经常会用到的需求分析文档+技术说明文档，这个文档应该是每一位编程人员都应该了解的材料，而且内容还必须是时时更新的，并且所有的编程人员也都应该知道修改的内容是哪些。现在流行的tower这类工具是不是就和四十年前作者提出的这个观点很像呢？
大型编程项目的组织架构
假设团队有n个成员，如果每个人都要和其他所有人进行交流，那交流的次数将会是(n^2-n)/2次，这显然是不能接受的，所以就需要组织架构来减少所需要交流和合作的数量，方法就是划分职责。主要关注一下产品负责人和技术主管两个角色以及他们之间的关系：
- 产品负责人：负责组建团队、划分工作和控制进度，确保进度目标的实现，还需要根据环境变化调整团队架构。这意味着他的主要工作是与团队外部进行沟通。
- 技术主管：他对设计进行构思，并勾画内部结构，提供整个设计的一致性和概念完整性。他还控制系统的复杂程度，当某个问题出现时，他提供解决方案或者调整系统设计。他的工作主要是团队内部沟通，几乎全是技术性的。
那么这两种角色会有几种关系呢：
- 产品负责人和技术主管是同一个人
- 产品负责人作为总指挥，技术主管充当副手
- 技术主管作为总指挥，产品负责人充当副手
作者最终的结论是：小型团队最好是技术主管作主，大型团队还是产品负责人作主更合适，一人兼任两职的形式也只适合3-6人的小型团队。其实这是很好理解的，因为技术主管负责保证概念完整性，这可是作者认为决定项目质量最重要的东西，所以大多数情况技术主管作主产品负责人辅助是合理的形式。而少数情况可以让产品负责人当总指挥，但是这种情况下产品负责人也要让技术主管体现出在团队中的权威，产品负责人必须尊重技术，遇到问题要先私下去问技术。这种组合只有一个好处，那就是可以让那些不太擅长管理的技术天才很舒服的完成工作。
以上就是《人月神话》第七章——为什么巴比伦塔会失败，的全部内容
本章作者主要是强调沟通的重要性，认为交流和组织的技能必须被管理者所重视，相关经验的积累和能力提高与编程技术一样重要。简单点说就是，不会沟通的程序员不是好程序员。
