7.1 巴比伦塔项目的失败是因为缺乏交流，以及交流的结果——组织。
交流
7.2 “因为左手不知道右手在做什么，从而进度灾难、功能的不合理和系统缺陷纷纷出现。”由于对其他人的各种假设，团队成员之间的理解开始出现偏差。
7.3 团队应该以尽可能多的方式进行相互之间的交流：非正式、常规项目会议，会上进行简要的技术陈述、共享的正式项目工作手册。[以及电子邮件。]
项目工作手册
7.4 项目工作手册“不是独立的一篇文档，它是对项目必须产生的一系列文档进行组织的一种结构。”
7.5 “项目所有的文档都必须是该（工作手册）结构的一部分。”
7.6 需要尽早和仔细地设计工作手册结构。
7.7 事先制订了良好结构的工作手册“可以将后来书写的文字放置在合适的章节中”，并且可以提高产品手册的质量。
7.8 “每一个团队成员应该了解所有的材料（工作手册）。”[我想说的是，每个团队成员应该能够看到所有材料，网页即可满足要求。]
7.9 实时更新是至关重要的。
7.10 工作手册的使用者应该将注意力集中在上次阅读后的变更，以及关于这些变更重要性的评述。
7.11 OS/360项目工作手册开始采用的是纸介质，后来换成了微缩胶片。
7.12 今天[即使在1975年]，共享的电子手册是能更好达到所有这些目标、更加低廉、更加简单的机制。
7.13 仍然需要用变更条和修订日期[或具备同等功能的方法]来标记文字；仍然需要后进先出（LIFO）的电子化变更小结。
7.14 Parnas强烈地认为使每个人看到每件事的目标是完全错误的；各个部分应该被封装，从而没有人需要或者允许看到其他部分的内部结构，只需要了解接口。
7.15 Parnas的建议的确是灾难的处方。[Parnas让我认可了该观点，使我彻底地改变了想法。]
组织架构
7.16 团队组织的目标是为了减少必要的交流和协作量。
7.17 为了减少交流，组织结构包括了人力划分（division of labor）和限定职责范围（specialization of function）。
7.18 传统的树状组织结构反映了权力的结构原理——不允许双重领导。
7.19 组织中的交流是网状，而不是树状结构，因而所有的特殊组织机制（往往体现成组织结构图中的虚线部分）都是为了进行调整，以克服树状组织结构中交流缺乏的困难。
7.20 每个子项目具有两个领导角色——产品负责人、技术主管或结构师。这两个角色的职能有着很大的区别，需要不同的技能。
7.21 两种角色中的任意组合可以是非常有效的：
产品负责人和技术主管是同一个人。
产品负责人作为总指挥，技术主管充当其左右手。
技术主管作为总指挥，产品负责人充当其左右手。
