人月神话——第二篇阅读笔记
关于项目的执行，作者先是提出了一些问题——“假设一个项目经理已经拥有行事规范的结构师和许多编程实现人员，那么他如何确保每个人听从、理解并实现结构师的决策？对于一个由 1000 人开发的系统，一个 10 个结构师的小组如何保持系统概念上的完整性？”
首先要有文档化的规格说明——手册。手册是产品的外部规格说明，它描述和规定了用户所见的每一个细节；同样的，它也是结构师主要的工作产物。随着用户和实现人员反馈的增加，手册的内容是需要不断修改的，对实现人员而言，修改的阶段化是很重要的，因此在进度表上应该有带日期的版本信息。手册的内容不应该试图支配具体的实现过程。规格说明的风格必须清晰、完整和准确。用户常常会单独提到某个定义，所以每条说明都必须重复所有的基本要素，所以所有文字都要相互一致。这往往使手册读起来枯燥乏味，但是精确比生动更加重要。
会议是必需的。作者认为把会议分成两个级别：周例会和年度大会是一种非常有效的方式。周例会是每周半天的会议，由所有的结构师，加上硬件和软件实现人员代表和市场计划人员参与，由首席系统结构师主持。会议中，任何人可以提出问题和修改意见，但是建议书通常是以书面形式，在会议之前分发。新问题通常会被讨论一些时间。重点是创新，而不仅仅是结论。该小组试图发现解决问题的新方法，然后少数解决方案会被传递给一个和几个结构师，详细地记录到书面的变更建议说明书中。接着会对详细的变更建议做出决策。这会经历几个反复过程，实现人员和用户会仔细地进行考虑，正面和负面的意见都会被很好地描述。如果达成了共识，非常好；如果没有，则由首席结构师来决定。这需要花费时间，最终所发布的结论是正式和果断的。周例会的决策会给出迅捷的结论，允许工作继续进行。如果任何人对结果过于不高兴，可以立刻诉诸于项目经理，但是这种情况非常少见。举办这种会议有以下好处——使得大家对项目相关的内容比较了解，不需要安排额外时间对人员进行培训；没有人是“顾问”的角色，每个人都要承担义务；当问题出现时，在界线的内部和外部同时寻求解决方案；正式的书面建议集中了注意力，强制了决策的制订，避免了会议草稿纪要方式的不一致；清晰地授予首席结构师决策的权力，避免了妥协和拖延。随着时间的推移，一些决定没有很好地贯彻，一些小事情并没有被某个参与者真正地接受，其他决定造成了未曾遇到的问题。年度大会便是解决这些问题的存在。这些“收获的节日”不仅可以解决决策上的问题，而且使决策更容易被接受。每个人都在倾听，每个人都在参与，每个人对复杂约束和决策之间的相互关系有了更透彻的理解。
作者提到在大型编程项目中的交流是一个比较重要的因素。团队进行相互之间的交流沟通有以下途径——清晰定义小组内部的相互关系和充分利用电话，能鼓励大量的电话沟通，从而达到对所书写文档的共同理解；常规项目会议。会议中，团队一个接一个地进行简要的技术陈述。这种方式非常有用，能澄清成百上千的细小误解。在项目的开始阶段，应该准备正式的项目工作手册。
项目工作手册不是独立的一篇文档，它是对项目必须产出的一系列文档进行组织的一种结构。项目所有的文档都必须是该结构的一部分。这包括目的、外部规格说明、接口说明、技术标准、内部说明和管理备忘录。技术说明几乎是必不可少的。如果某人就硬件和软件的某部分，去查看一系列相关的用户手册。他发现的不仅仅是思路，而且还有能追溯到最早备忘录的许多文字和章节，这些备忘录对产品提出建议或者解释设计。对于技术作者而言，文章的剪裁粘贴与钢笔一样有用。使用项目手册的第二个原因是控制信息发布。控制信息发布并不是为了限制信息，而是确保信息能到达所有需要它的人的手中。
关于程序空间，作者认为——“由于规模是软件系统产品用户成本中如此大的一个组成部分，开发人员必须设置规模的目标，控制规模，考虑减小规模的方法，就像硬件开发人员会设立元器件数量目标，控制元器件的数量，想出一些减少零件的方法。同任何开销一样，规模本身不是坏事，但不必要的规模是不可取的。
对项目经理而言，规模控制既是技术工作的一部分，也是管理工作的一部分。他必须研究用户和他们的应用，以设置将开发系统的规模。接着，把这些系统划分成若干部分，并设定每个部分的规模目标。由于规模－速度权衡方案的结果在很大的范围内变化，规模目标的设置是一件颇具技巧的事情，需要对每个可用方案有深刻的了解。聪明的项目经理还会给自己预留一些空间，在工作推行时分配。
显然，在速度保持不变的情况下，更多的功能意味着需要更多的空间。所以，其中的一个技巧是用功能交换尺寸。这是一个较早的、影响较深远的策略问题：为用户保留多少选择？程序可以有很多的选择功能，每个功能仅占用少量的空间。也可以设计成拥有若干选项分组，根据选项组来剪裁程序。任何一系列特殊选项被合并在一起进行分组时，程序需要的空间较少。这很像小汽车。如果把照明灯、点烟器和时钟作为整个配件来标明价格，则成本会比单独提供这些选择所需要的成本低。所以，设计人员必须决定用户可选项目的粗细程度。在内存大小一定的情况下进行系统设计时，会出现另外一个基本问题。内存受限的后果是即使最小的功能模块，它的适用范围也难以得到推广。在最小规模的系统中，大多数模块被覆盖（overlaid），系统的主干占用的空间，会被用作其他部分的交换页面。它的尺寸决定了所有模块的尺寸。而且将功能分解到很小的模块会耗费空间和降低性能。所以，当可以提供 20 倍临时性空间的大型系统使用这些模块时，节省的也仅仅是访问次数，仍然会因为模块的规模引起空间和速度上的损失。这样后果其实是——很难用小型系统的模块构造出非常高效的系统。第二个技能是考虑空间－时间的折衷。对于给定的功能，空间越多，速度越快。这一点在很大的范围内都适用。也正是这一点使空间预算成为可能。项目经理可以做两件事来帮助他的团队取得良好的空间－时间折衷。一是确保他们在编程技能上得到培训，而不仅仅是依赖他们自己掌握的知识和先前的经验。特别是使用新语言或者新机器时，培训显得尤其重要。熟练使用往往需要快速的学习和经验的广泛共享，也许它应该伴随特别的新技术奖励或者表扬。另外一种方法是认识到编程需要技术积累，需要开发很多公共单元构件。每个项目要有能用于队列、搜索和排序的例程或者宏库。对于每项功能，库至少应该有两个程序实现：运行速度较快和短小精炼的。上述的公共库开发是一件重要的实现工作，它可以与系统设计工作并行进行。
关于文档，作者进行了解释和分析。每份文档的准备工作是集中考虑，并使各种讨论意见明朗化的主要时刻。如果不这样，项目往往会处于无休止的混乱状态。文档的跟踪维护是项目监督和预警的机制。文档本身可以作为检查列表、状态控制，也可以作为汇报的数据基础。在许多软件项目中，开发人员从商讨结构的会议开始，然后开始书写代码。不论项目的规模如何小，项目经理聪明的做法都是：立刻正式生成若干文档作为自己的数据基础，哪怕这些迷你文档非常简单。接着，他会和其他管理人员一样要求各种文档。首先，书面记录决策是必要的。只有记录下来，分歧才会明朗，矛盾才会突出。书写
这项活动需要上百次的细小决定，正是由于它们的存在，人们才能从令人迷惑的现象中得到清晰、确定的策略。第二，文档能够作为同其他人的沟通渠道。项目经理常常会不断发现，许多理应被普遍认同的策略，完全不为团队的一些成员所知。正因为项目经理的基本职责是使每个人都向着相同的方向前进，所以他的主要工作是沟通，而不是做出决定。这些文档能极大地减轻他的负担。最后，项目经理的文档可以作为数据基础和检查列表。通过周期性的回顾，他能清楚项目所处的状态，以及哪些需要重点进行更改和调整。作者并不是很同意销售人员所吹捧的“完备信息管理系统”——管理人员只需在计算机上输入查询，显示屏上就会显示出结果。有许多基本原因决定了上述系统是行不通的。一个原因是只有一小部分管理人员的时间——可能只有 20%——用来从自己头脑外部获取信息。其他的工作是沟通：倾听、报告、讲授、规劝、讨论、鼓励。不过，对于基于数据的部分，少数关键的文档是至关重要的，它们可以满足绝大多数需要。项目经理的任务是制订计划，并根据计划实现。但是只有书面计划是精确和可以沟通的。计划中包括了时间、地点、人物、做什么、资金。这些少量的关键文档封装了一些项目经理的工作。如果一开始就认识到它们的普遍性和重要性，那么就可以将文档作为工具友好地利用起来，而不会让它成为令人厌烦的繁重任务。通过遵循文档开展工作，项目经理能更清晰和快速地设定自己的方向。