在做项目的时候，难免有分歧。有的人就觉得自己的好，想要应用自己的东西，画蛇添足，造成混乱。那么如何避免呢？
结构式最好牢记是开发人员承担创造性和发明性的实现责任，所以结构师只能建议，而不能支配；时刻准备着为所指定的说明建议一种实现的方法，同样准备接受其他任何能达到目标的方法；对上述的建议保持低调和平静； 准备放弃坚持所作的改进建议。结构师如何避免画蛇添足——开发第二个系统所引起的后果？是的，他无法跳过二次系统。但他可以有意识关注那些系统的特殊危险，运用特别的自我约束准则，来避免那些功能上的修饰；根据系统基本理念及目的变更，舍弃一些功能。项目经理如何避免画蛇添足？他必须坚持至少拥有两个系统以上开发经验结构师的决定。同时，保持对特殊诱惑的警觉，他可以不断提出正确的问题，确保原则上的概念和目标在详细设计中得到完整的体现。
那么规划了这么多，光说不做是不行的。而且，要展现在书面上，文件中，最好有个项目手册。能让所有人都明白整个的架构和一些细节，都能理解。这和我们的统一建模语言UML课所学的差不多。都是做出能让客户和工程师都能理解并且进行交流的东西。手册、或者书面规格说明，是一个非常必要的工具，尽管光有文档是不够的。手册是产品的外部规格说明，它描述和规定了用户所见的每一个细节；同样的，它也是结构师主要的工作产物。手册不但要描述包括所有界面在内的用户可见的一切，它同时还要避免描述用户看不见的事物。规格说明的风格必须清晰、完整和准确。
同事们的交流也很必要。交换想法，共同发现一些bug，解决他们。会议是必要的。会议中，任何人可以提出问题和修改意见，但是建议书通常是以书面形式，在会议之前分发。新问题通常会被讨论一些时间。重点是创新，而不仅仅是结论。该小组试图发现解决问题的新方法，然后少数解决方案会被传递给一个和几个结构师，详细地记录到书面的变更建议说明书中。最后留有测试的时间，保证客户能够很好的使用。那么如何进行有效的交流和组织呢？
清晰定义小组内部的相互关系和充分利用电话，能鼓励大量的电话沟通，从而达到对
所书写文档的共同理解。
常规项目会议。会议中，团队一个接一个地进行简要的技术陈述。这种方式非常有用，
能澄清成百上千的细小误解。
在项目的开始阶段，应该准备正式的项目工作手册。项目工作手册不是独立的一篇文档，它是对项目必须产出的一系列文档进行组织的一种结构。项目所有的文档都必须是该结构的一部分。这包括目 的、外部规格说明、接口说明、技术标准、内部说明和管理备忘录。技术说明几乎是必不可少的。如果某人就硬件和软件的某部分，去查看一系列相关的用户手册。他发现的不仅仅是思路，而且还有能 追溯到最早备忘录的许多文字和章节，这些备忘录对产品提出建议或者解释设计。对于技术作者而言，文章的剪裁粘贴与钢笔一样有用。
现在一切准备就绪，那么项目的组织架构怎么按安排？作者建议每个子树的基本要义：
1. 任务（a mission）
2. 产品负责人（a producer）
3. 技术主管和结构师（a technical director or architect）
4. 进度（a schedule）
5. 人力的划分（a division of labor）
6. 各部分之间的接口定义（interface definitions among the parts）
产品负责人和技术主管是同一个人。产品负责人作为总指挥，技术主管充当其左右手。技术主管作为总指挥，产品负责人充当其左右手。
预计项目时间，作者列举了很多专业人士分析的数据，我觉得可以搬过来进行参考借鉴：
图 8.1 讲述了这个悲惨的故事。它阐述了 Nanus 和 Farr2 在 System Development
Corporation 公司所做研究，结果表明该指数为 1.5，即，
Weinwurm3的 SDC 研究报告同样显示出指数接近于 1.5。
现在已经有了一些关于编程人员生产率的研究，提出了很多估计的技术。 Morin 对所
发布的数据进行了一些调查研究 4 。这里仅仅给出了若干特别突出的条目。
图 8.1：编程工作量是程序规模的函数
Portman 的数据
曼彻斯特 Computer Equipment Organization（Northwest）的 ICL 软件部门的经理 Charles Portman，提出了另一种有用的个人观点 5。他发现他的编程队伍落后进度大约 1/2，每项工作花费的时间大约是估计的两倍。这些估计通常是非常仔细的，由很多富有经验的团队完成。他们对 PERT 图上数百个子任务估算过（用人小时作单位）。当偏移出现时，他要求他们仔细地保存所使用时间的日志。日志显示事实上他的团队仅用了百分之五十的工作周，来进行实际的编程和调试，估算上的失误完全可以由该情况来解释。其余的时间包括机器的当机时间、高优先级的无关琐碎工作、会议、文字工作、公司业务、疾病、事假等等。简言之，项目估算对每个人年的技术工作时间数量做出了不现实的假设。我个人的经验也在相当程度上证实了他的结论。
Aron 的数据
Joel Aron，IBM 在马里兰州盖兹堡的系统技术主管，在他所工作过的 9 个大型项目（简要地说，大型意味着程序员的数目超过 25 人，将近 30,000 行的指令）7 的基础上，对程序
员的生产率进行了研究。他根据程序员（和系统部分）之间的交互划分这些系统，得到了如
下的生产率：
非常少的交互 10,000 指令每人年
少量的交互 5,000
较多的交互 1,500
该人年数据未包括支持和系统测试活动，仅仅是设计和编程。当这些数据采用除以 2，以包括系统测试的活动时，它们与 Harr 的数据非常的接近。
Harr 的数据
John Harr，Bell 电话实验室电子交换系统领域的编程经理，在 1969 年春季联合计算机会议 的论文中，汇报了他和其他人的经验。这些数据如图 8.2、8.3 和 8.4 所示。这些图中，图 8.2 是最数据详细和最有用的。头两个任务是基本的控制程序，后两个是基本的语言翻译。生产率以经调试的指令/人年来表达。它包括了编程、构件测试和系统
测试。没有包括计划、硬件机器支持、文书工作等类似活动的工作量。生产率同样地被划分为两个类别，控制程序的生产率大约是 600 指令每人年，语言翻译大约是 2200 指令每人年。注意所有的四个程序都具有类似的规模——差异在于工作组的大小、时间的长短和模块的个数。那么，哪一个是原因，哪一个是结果呢？是否因为控制程序更加复杂,所以需要更多的人员？或者因为它们被分派了过多的人员，所以要求有更多的模块？是因为复杂程度非常高，还是分配较多的人员，导致花费了更长的时间？没有人可以确定。控制程序确实更加复杂。除开这些不确定性，数据反映了实际的生产率——描述了在现在的编程技术下，大型系统开发的状况。因此，Harr 数据的确是真正的贡献。图 8.3 和 8.4 显示了一些有趣的数据，将实际的编程速度、调试速度与预期做了对比。
OS/360 的数据
IBM OS/360 的经验，尽管没有 Harr 那么详细的数据，但还是证实了那些结论。就控制程序组的经验而言，生产率的范围大约是 600～800（经过调试的指令）/人年。语言翻译小组所达到的生产率是 2000～3000（经过调试的指令）/人年。这包括了小组的计划、代码构件测试、系统测试和一些支持性活动。就我的观点来说，它们同 Harr 的数据是可比的。Aron、Harr 和 OS/360 的数据都证实，生产率会根据任务本身复杂度和困难程度表现出显著差异。在复杂程度估计这片“沼泽”上的指导原则是：编译器的复杂度是批处理程序的三倍，操作系统复杂度是编译器的三倍 8。
Corbato 的数据
Harr 和 OS/360 的数据都是关于汇编语言编程的，好像使用高级语言系统编程的数据公布得很少。Corbato 的 MIT 项目 MAC 报告表示在 MULTICS 系统上，平均生产率是 1200 行经调试的 PL/I 语句（大约在 1 和 2 百万指令之间）/人年。该数字非常令人兴奋。如同其他的项目，MULTICS 包括了控制程序和语言翻译程序。和机器指令：千字其他项目一样，它产出的是经过测试和文档化的系统编程产品。在所包括的工作类型方面，数据看上去是可以比较的。该数字是其他项目中控制程序和翻译器程序生产率的良好平均
值。但 Corbato 的数字是行/人年，不是指令！系统中的每个语句对应于手写代码的 3 至 5
个指令！这意味着两个重要的结论。
对常用编程语句而言。生产率似乎是固定的。这个固定的生产率包括了编程中需要注释，并可能存在错误的情况.
使用适当的高级语言，编程的生产率可以提高 5 倍。
