【人月神话】读书笔记第7章 为什么巴比伦塔会失败

1、引言

     巴比伦塔这个项目有很多的先决条件：一是，清晰的目标，二是充足的人力，三是充足的材料，四是没有时间限制，五是足够的技术。

     那为什么还失败呢？---缺乏交流和组织。

2、大型项目中的交流

     随着工作的进行，许多小组慢慢的修改自己程序的功能、规模和速度，他们明确或者隐含地更改了一些有效输入和输出结果用法上的约定。例如A模块根据统计报告显示某个功能很少被利用，于是降低了它的速度，而其实B模块有可能很大程度上依赖于A模块的这个功能。因此需要从系统角度来考虑和衡量该变化，以及公开、广泛地发布变更结果。

     那么团队如何进行交流和沟通呢？

     第一，非正式途径。清晰定义小组内部的相互关系和充分利用电话，达到对所书写文档的共同理解。

     第二，会议。团队一个个地进行简要的技术陈述。这种方式非常有用，能澄清成百上千的细小误解。

     第三，工作手册。在项目的开始阶段，应该准备正式的项目工作手册。

3、项目工作手册

      是什么？项目工作手册是对项目必须产生文档的一系列文档进行组织的一种结构。包括目的、外部规格说明、接口说明、技术标准、内部说明和管理备忘录。

      为什么？第一，项目工作手册记录的是思路，可以对产品提出建议或者解释设计。因此正确而规范的文档结构很重要。第二，控制信息发布。确保信息能够到达所有需要它的人的手中。因此一是要对所有的备忘录标号，从而通过标题列表检索是否有需要的信息；二是，用树状的索引结构来维护发布列表。

       处理机制。随着项目规模的扩大，技术备忘录的问题以非线性增长。每个编程人员都应该了解所有材料。工作手册的实时更新非常重要。一是打印文档，每次变更需要重新打印，很难做到。因此可以使用活页夹的方式，仅仅需要更换变更页。文档变更需要在页面山标记发生改变的文本，分发的变更页上附带简短、独立的总结性文字，对变更的重要性以及批注进行记录。但是有可能文档特别多。二是，采用微缩胶卷。维护工作很简单。从管理的角度来看，笨拙的文字归档工作能够确保所有变更都被阅读，这正是工作手册要达到的目的。而读者不能再微缩胶卷上做强调、标记和批注。对作者来说，采用文档方式与读者沟通更为有效，对读者来说，文档也更加方便使用。微缩胶卷可以作为文字工作手册的补充。

        现在如何入手？采用可以直接访问的文件。在文件中，记录修订日期记录和标记变更标识条。维护变更以“后进先出的方式LIFO”提供访问。编程人员可以每天阅读，如果错过了一天，就可以第二天多花一些时间，可以停下来查询变更的文字。有人认为编程人员仅仅了解自己负责的部分，而不是整个系统的开发细节时，工作效率最高。这种方法的先决条件是精确和完整的定义所有接口。一个好的信息系统不但能暴露接口错误，还能有助于改正错误。

4、大型编程项目的组织架构

     团队组织的目的是减少所需的交流和合作的数量，因此良好的团队组织是解决上述交流问题的关键措施。减少交流的方法是人力划分和限定职责范围。当使用人力划分和职责限定时，树状管理的结构反映出对详细交流的需要会相应减少。

     树状组织架构是作为权力和责任的结构出现，其基本原理---管理角色的非重复性--导致了管理结构是树状的。但是交流的结构师网状的。

     树状编程队伍，要行之有效，每颗子树所必须具备的基本要素。是：任务，产品负责人，技术主管，进度，人力的划分，各部分之间的接口定义。

     产品负责人：组建团队、划分工作及制定进度表，争取并一直保证必要的资源。主要的工作是对上的沟通和平行的沟通。他建立团队内部的沟通和报告方式，最后，确保进度目标的实现，根据环境的变化调整资源和团队的构架。

     技术主管：对设计进行构思，识别系统的子部分，指明从外部看上去的样子，勾画它的内部结构。提供整个设计的一致性和概念完整性；控制系统的复杂程度。当某个技术问题出现时，提供问题的解决方案，或者根据需要调整系统设计。沟通交流工作在团队中是首要的。他的工作工作几乎完全是技术性的。

    两者的组合存在三种可能关系：

    第一，是同一个人。优点：减少了二者之间的沟通交流成本，有绝对的权威。缺点，同时具有管理和技术的人很难找到；大型项目中，每个角色必须全职工作，甚至还要加班。对于产品负责人来说，很难在承担全部管理职责的同时，还能抽出时间进行技术工作；对于技术主管来说，很难在保证设计的概念完整性、没有任何妥协的前提下，担任管理工作。

    第二，产品负责人作为总指挥，技术主管作为左右手。缺点，技术主管不参与任何管理工作，很难建立其在技术决策上的权威。因此，产品负责人必须预先声明技术主管的技术权威，支持后者的技术决定。两人必须在基本的技术理论上具有相似观点，并且在主要的技术问题出现之前，私下讨论这些问题；产品负责人对技术主管的技术才能表现出尊重。另外，可以让技术主管通过一些方式做决策，体现威信。这种方式好处在于，各司其职，专一专注；可以使用不擅长管理的技术天才。

    第三，技术主管作为总指挥，产品负责人作为左右手。好处，专一专注。缺点，不适合大型的项目。我个人感觉，可能是因为大型项目系统架构复杂，需要多个子系统协同工作，每个子系统由一个团队负责。这时候彼此的沟通和协调更为重要。