巴比伦塔之前在诸如未解之谜之类的故事中看过很多次，其实也有不同的版本。有这本书中介绍的这种版本，也有另外一种说法，那就是上帝为了惩罚人类建造巴比伦塔的行为让世界上的人区分了各种语言。但是，作为一个例子抽象的表达，怎么描述以及最初的故事原本是什么样子并不重要了。
其实，我一直觉得有趣的一点就是建造的方式。如果从我思考的角度来出发，或许我会选择一个高耸入云的大山作为基础。兴许，这样的起点其实就已经超过了巴比伦塔当时的成就了。
看了故事已经描述的几条条件，我觉得这一章节可能描述的主要内容或许是有效的沟通。从上面画出来的文字看，看书前的一些猜测还是得到了证实的。
这本书出版的时候已经是几十年前了，当时的技术条件还是有一些古老，如今的技术以及计算机服务产品太多，我们面临的环境已经比之前好太多。技术条件，也已经不能够同日而语了。
关于项目工作手册，总体的感觉应该是像一个巨大的wiki。但是，从定义来看，似乎又有些不像。
从我现在接触到的管理工具或者系统来看，没有看到一个合适的工具来形象化这里提出来的项目手册。或许，摆脱一个大一统的管理束缚，从这个手册需要做的事情角度去思考会有更多的可借鉴性。
信息的维护是面向整个项目中所有工作的，因此还是有一些难度。如果只是看软件的实现，条件兴许更好一些。再次想到了高德纳提出来的文学编程，很多工作中需要考虑的问题在这样的工作模式中得到了很好的解决。
针对手册编辑维护本身，如今的技术支持下已经没有了之前的那些不便。现在的在线文档以及wiki等都能够提供这样的帮助。
其实，这里提到的可以访问的文件还是很粗糙的。如今的在线文档之类的产品如果出现在当时，可能是一种轰动性的产品。
如果进行系统的拆分开发，可能会遇到一些沟通交流的问题。这个也正好映射到了当前的章节标题所引入的主题上。如果要让这样的工作更好做，其实更前面章节中提到的标准化是很好的手段。
交流很容易出现无效的沟通，或者有一些人的时间会因此耗费浪费。前面几个章节中提出来的几种会议，其实有时候就会引入这样的问题。如何解决呢？限定职责范围是一种方式，另一种方式则是前面提到的会议之前的充分准备以及资料分发。
这里看到了一个比较符合我现在的职业角色的描述，但是从这个描述中我也看到了一些需要提升的空间点。
团队的组织不仅仅是把人员聚拢起来，更重要的是选择合适有效的人员。
关于产品责任人以及技术主管的职责分工，可能有多重模式，随着工作内容的不同、团队大小的变化等会有不同的组合方式。
团队的能力，有时候不仅仅是体现在具体人员的能力上。沟通配合的有效和高效也是很重要的一方面，因此在高效的团队中出现的应该更多的适合做而不是冲突。
给真正的决策人员建立威信，这个是团队运作中几个关键核心人员需要考虑的问题。
交流的成果是这里提到的组织，其实我觉得这样的翻译或许又是一个问题翻译。或许，这里的原始表达是organization。或许，这里能够表达出来的不仅仅有一个组织的概念，也有安排的意思。因此，沟通交流的结果应该是最终团队下一步的决策。
