巴比伦塔的失败主要是因为交流不畅，语言不通使得复杂的工程在交流模块变得更加的复杂，过度的交流影响了建筑的效率以及概念的完整性。软件产品也是一样的，一个软件产品的复杂度并不比巴比伦塔低，从分析到设计到开发到测试，整个流程下来，完全可以说软件产品就是一个小型的巴比伦塔（建筑工程），所谓软件工程的工程二字，也可以说是因为它的复杂程度吧。
文中针对交流方面提出了两个问题，一个是如何保证必要的交流，另一个是如何避免不必要的交流。看上去保障必要交流比避免不必要的交流要简单的多。那么如何避免不必要的交流呢？文中提到了一种简单易行的方式就是划定成员职责范围，当每个人都有自己独立的职责时，就不存在“不必要”的交流了，每个人在自己的范围内进行交流发言，明确分工任务，从而减轻复杂的交流。
那这是不是就意味着，不属于自己范围的问题就不可以提出呢？当然不是的，要知道在开发过程中，所谓交流，不是有问题沉默，有问题要及时的提出来，争吵比沉默要来的实在，适当的询问是可以提高开发效率的。
但是这个过程，也并不是随心所欲的，擅自的猜测有时会影响团队成员之间的关系，文中给出了一个解决办法——工作手册，详细的工作手册也是增加效率的一个重要途径，查询手册可以帮助团队成员解决很多细小的问题。
而对于一个小型团队来说，主要是以架构师或者是技术主管为首脑，对于学生团队，则要以能力较强的程序员为首脑，这样的分布更有利于开发中问题的解决，该程序员要有足够的权威决定产品的各项功能以及完整架构，如此方可实现项目的高效实现。
大学期间我看到了很多团队都是以“精”为重，他们到处招揽人才，能力水平几乎没有什么区分，在各个专业都是“大佬”级别的存在，这样的团队，没有一个确定的领导者，而在团队会议中，各种问题也是层出不穷，每个人都有自己的想法，这就导致了项目开发中的各种交流问题以及决定问题。
所以我觉得，在组建团队的时候，切忌全部成员都是“大佬”级的人物，一定要突出一个首脑，这样的团队在工作的时候才不容易出现分歧