本文主要是介绍第七章 问什么巴比伦塔会失败，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
1.巴比伦塔项目的失败是因为缺乏交流以及交流的结构-组织。
交流
2.“因为左手不知道右手在做什么，从而进度灾难、功能的不合理和系统缺陷纷纷出现。”由于存在对其他人的各种假设，团队成员之间的理解开始出现偏差。
3.团队应该以尽可能多的方式进行相互之间的交流：非正式的进行简要技术陈述的常规项目会议，共享的正式项目工作手册[以及通过电子邮件]。
项目工作手册
4.项目工作手册“不是独立的一篇文档它是对项目必须产生的一系列文档进行组织的一种结构”。
5.“项目所有的文档都必须是该[工作手册]结构的一部分。”
6.需要尽早和仔细的设计工作手册结构。
7.事先制定良好结构的工作手册“可以将后来书写的文字放置在合适的章节中”，并且可以提高产品手册的质量。
8.“每一个团队成员应该了解所有的材料（工作手册）。”（我现在想说的是，每个团队成员应该能够看到多有材料，网页即可满足要求。）
9.实时更新是至关重要的。
10.工作手册的使用者应该将注意力集中在上次阅读后的变更以及关于这些变更重要性的评述上。
11.共享的电子手册是能达到所有这些目标的，更好的、更加低廉的、更加简单的机制。
12.仍然需要用变更条和修订日期来标记文字；仍然需要后进先出的电子化变更小结。
13.X强烈的认为使每个人看到每件事的目标是完全错误的；各个部分应该被封装，从而没有人需要或者被允许看到其他部分的内部结构，只需要了解接口。
14.X的建议的确是灾难的处方。
组织结构
15团队组织的目标是为了减少必要的交流和协作量。
16.为了较少交流，组织结构包括了人力划分和限定职责范围。
17.传统的树状组织结构反映了权利的结构原理-不允许双重领导。
18.组织中的交流是网状，而不是树状结构，因此所有的特殊组织机制都是为了进行调整，以克服树状组织结构中交流缺乏的困难。
19每个子项目具有两个领带角色-产品负责人，技术主管或结构师。这两个角色的只能有很大的区别，需要不同的技能。
20.两种角色的任意组合都可以是非常有效地：
（1）产品负责人和技术主管是同一个人；
（2）产品负责人作为总指挥，技术主管充当其左右手；
（3）技术主管作为总指挥，产品负责人充当其左右手。
这篇关于第七章 问什么巴比伦塔会失败的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
