交流的缺乏导致了争辩、沮丧和群体猜忌。很快，部落开始分裂——大家选择了孤立，而不是互相争吵
缺少相互沟通会导致进度灾难、功能的不合理和系统缺陷
对程序功能的修改要从系统角度来考虑和衡量，及时做公开，告知
项目工作手册
是项目文档的集合，包括目的、外部规格说明、接口说明、 技术标准、内部说明和管理备忘录，帮助后来者了解产品设计
事先将项目工作手册设计好，能保证文档的结构本身是规范的
控制信息发布：确保信息能到达所有需要它的人的手中，对所有的备忘录编号或者树状的索引结构
记录修订日期记录和标记变更标识条
编程人员仅了 解自己负责的部分，而不是整个系统的开发细节时，工作效率最高，先决条件是 精确和完整地定义所有接口
大型编程项目的组织架构
团队组织的目的是减少不必要交流和合作的数量
减少交流的方法是人力划分和限定职责范围
树状组织架构:
- 任务(a mission)
- 产品负责人(a producer)
- 技术主管和结构师(a technical director or architect)
- 进度(a schedule)
- 人力的划分(a division of labor)
- 各部分之间的接口定义(interface definitions among the parts)
产品负责人:
- 主要的工作是与团队外部，向上和水平地沟通，建立团队内部 的沟通和报告方式
- 组建团队，划分工作及制订进度表，要求资源，确保进度目标的实现，根据环境的变化调整资源和团队的构架
技术主管:
- 提供整个设计的一致性和概念完整性,控制系统的复杂程度
- 对设计进行构思，确定内部结构。
- 提供技术问题的解决方案，或者根据需要调整系统设计。
- 他的沟通交流在团队中是首要的。他的工作几乎完全是技术性的
产品负责人和技术主管的组合方式
产品负责人和技术主管是同一个人:
- 只适用于几个人的小团队开发
- 同时具有管理技能和技术技能的人很难找到，大型项目中，每个角色都必须全职工作无法保证还能抽空做别的
产品负责人作为总指挥，技术主管充当其左右手：
- 实现难度在建立技术决策上的权威
- 必须对技术主管的技术才能表现出尊重，支持他的技术决定
- 在主要的技术问题出现之前，私下讨论它们,达到在基本的技术理论上具有相似观点
- 一些技巧 通过一些微妙状态特征暗示来(如，办公室的大小、地毯、装修、复印机等等)体现技术主管的威信
- 这种组合可以使工作很有效 项目经理可以使用并不很擅长管理的技术天才来完成工作
技术主管作为总指挥，产品负责人充当其左右手：
- 小型的团队是最好的选择
- 参考 外科手术队伍
对于真正大型项目中的一些开发队伍，产品负责人作为管理者是更合适的安排