康威：委员会是如何产生的？
注意：本文翻译仅为个人学习，未获原作者或版权方允许。
在发表的33年后，作者的话
可能这篇论文最出色的一个地方，是在倒数第三段中的论点。为了省去你从45段中找到这个论点的时间，我现在就告诉你：
任何设计系统的组织（这里定义的不仅仅是信息系统），将不可避免的产生一个设计，这个设计的结构是组织通信结构的副本。
虽然经常被引用在软件项目管理领域，但事实证明，这是一个还具有广泛适用性的原则。我邀请你来读这篇论文，然后寻找到一些应用。我当下的兴趣是复杂的社会问题，包括福利，劳动力市场准入，住房，教育和毒品。在你读完这篇论文后，可以思考一下，我们各个政府的结构，是如何影响他们对这个系统的。
Melvin E. Conway
1968年，F. D. Thompson Publications, Inc 版权所有。经 Datamation 杂志许可转载，在1968年4月出版。
那种从不同部分中创造一个整体的智力活动，想必就是系统设计了。无论这种特定的活动是作为主要武器系统的设计规范，还是形成应对社会问题的建议，亦或是计算机编程，在一般的活动中，很大程度上是相同的。
通常，设计组织的目标是创建和组装一个文档，它包含了相关的结构化信息主体。我们可以称之为系统设计。它通常是为想要在系统设计的指导下进行一些活动的发起人制作的。例如，一个公职人员可能希望提出立法来避免最近的灾难重演，所以他任命一个团队去解释这场灾难。或者制造商需要一个新产品并且指定一个产品规划的活动去指出什么是需要引进的。
设计组织可能不会参与构建他所设计的系统。通常，在公共事务中，有一些政策会阻止一个团体按照自己的建议行事，而在私营行业中，则经常恰恰相反。
假设人们必须执行自己的建议或者这项任务将落在别人身上的知识可能会影响个别设计师需要做出的某些设计选择，似乎是合理的。大多数设计活动需要不断地做出选择，其中大多数选择可能不只是设计决策；他们可能也会是设计者对他自己未来的个人选择。正如我们接下来会看到的，在传统管理环境下的激励措施，可以刺激颠覆发起人意图的选择。[1]
设计的阶段
在设计工作的初始阶段更多关注的是设计活动的结构而不是系统自身。[2]在一些初始的里程碑完成之前，没有办法进行全面的设计活动。他们包括了：
- 理解发起人和真实世界在设计的活动和设计的系统的界限；
- 实现系统组织的初步概念，以便可以有意义的分配设计任务组。
我们将详细的看到，组织设计团队的行为本身就意味着设计决策已经做出，无论是明确的还是其他的。给定任何设计团队组织，有一类设计替代方案不能被这样的组织有效地追求，因为不存在必要的沟通路径。 因此，不存在既有组织又无偏见的设计团队。
一旦选择了设计团队，就可以将设计活动委派给组织的子分组。每次委托完成和某人调查范围缩小时，可以有效追求的设计方案类别也缩小了。
一旦定义了活动的范围，协调的问题就产生了。任务组之间的协调，尽管看起来会降低小组内个人的生产力，但是为单独任务组将他们的工作整合到统一系统的设计中，提供了唯一可能性。
因此，系统设计工作的生命周期通过以下阶段进行：
- 通过基本规则绘制边界；
- 初步系统概念的选择；
- 根据这些概念组织设计活动和任务委派；
- 委派任务之间的协调；
- 将子设计合并到一个设计中。
给定的设计可能不直接通过这个列表执行。可以想象，它可能在发现新的，明显优越的设计概念之后重组；但这种不确定的变现是贬损的；而且自愿放弃创作的行为本身，是痛苦和代价高昂的。当然，从历史学家的角度来看，这个过程是不断重复的。这个观点产生了一种观察：永远没有足够的时间把一件事做到完美，但是永远有足够的时间来完成它。
设计系统
任何有价值的系统都是由更小的子系统相互连接所构成的。系统的表述，如果是描述这个系统内部发生的事情，就必须描述系统与外界世界的连接，并且必须描述每个子系统和他们是如何互相联系的。再往下一层，我们可以将每个子系统当做是系统。我们继续往下，让这种规模缩小，直到理解起来足够简单，不需要再去分解。
举个例子：一个横穿大陆的公共交通系统包括公共汽车、火车、飞机、各种类型的路权、停车场、出租车、码头等。这是一个非常异构的系统；也就是说，子系统特别多样化。往下一层，以飞机为例。可能拥有结构、推进、配电、通信和有效载荷包装的子系统。推进子系统有燃料、点火和启动子系统，诸如此类。
这可能不是很明显，一个理论在这种意义上也是一个系统。它与观察事件的外部世界有关，它必须阐明这种关联，至少是不存在矛盾的。它由通过同样方式互相关联的子理论组成。例如，对坠机事故的调查试图产生一种解释复杂事件的理论。它可能是由多个子理论组成，包括：飞机路径描述、无线电通信、损坏方式以及事件发生时与附近物体的关系。反过来，这其中的每一个理论，都是一个故事，它可以将其进一步分解为更精细的细节，直至证据单元的级别。
线性图。图1通过线性图的方式展示了这个系统——一个有分支（显）和节点（圆圈）的Tinker-Toy结构。每个节点是一个子系统，它通过分支与其他子系统通信。反过来，每个子系统可能包括一个可能被类似结构描述的结构。在系统人员中越来越流行的术语接口是指图1中用线代表的，子系统之间的通信路径或分支。或者，接口是一个插头或者法兰，通过它来耦合从不同节点出来的路径。
相关的两者
线性图符号是有用的，因为它提供了一个抽象，和我们在考虑的两个实体是相同形式的：设计组织和它设计的系统。可以在图1中替换下面的单词。
- 将“系统”替换成“委员会”
- 将“子系统”替换成“子委员会“
- 将“接口”替换成“协调员”
和系统一样，我们发现设计组可以在多个复杂级别查看。以联邦政府为例。它是设计组织很好的一个例子，其复杂性足以满足任何系统工程师。这是一个特别有趣的例子，显示了这两个概念的相似性，因为联邦政府既是一个设计组织（设计法律、条约和政策），也是一个设计系统（宪法是主要的初步设计文件）。
一个基本的关系。我们现在可以解决本文的根本问题了。设计组织的图结构与其设计的系统的图结构之间，是否存在可以预测的关系。答案是：是的。这种关系很简单，在某些情况下它是一种身份。 考虑以下“证明”。
让我们任意选择一些系统和设计它的组织，然后让我们也任意选择设计系统的复杂程度，我们给它画一个图。（我们对这种随意性的动机是，如果我们成功的证明了有趣的东西，它就会同样适用在任何设计组织和复杂程度。）图2，仅是出于说明目的，显示了与后面的声明可能相关的结构。
对系统中的任意节点x，我们可以认出设计x的设计组织的设计小组，并称之为X。因此，通过一般化这个过程，对于系统的每个节点，我们都有一个规则来寻找对应节点的设计组织。注意，这个规则不一定是一对一的；也就是说，存在两个子系统可能是同一个设计小组设计的。
有趣的是，我们可以对分支们做类似的声明。驱系统中任意两个节点x和y。它们要么被一个分支加入，要么没有。（也就是说，它们要么以某种对系统运行有意义的方式互相通信，要么不相互通信。）如果存在一个分支，则设计两个节点的两个（不一定是不同的）设计组X和Y，必须协商并约定接口规范，以允许设计组织的两个对应节点之间的通信。另外一方面，如果x和y之间没有分支，则子系统不相互通信，两个对应的设计组不存在协商，也因此X和Y之间也没有分支。[3]
我们刚刚展示了什么？简单来说，我们已经证明了，系统结构和设计它的组织结构之间，存在非常密切的关系。每个子系统都有它单独的设计小组并非是不常见的情况，我们发现设计小组的结构和系统的结构（线形图）是相同的。在某些情况下，一些小组会设计多个子系统，我们发现设计组织的结构是系统结构的折叠版本，具有相同设计小组的子系统，折叠进一个节点，来代表这个小组。
这种在两组事物之间保持结构的关系，称之为同态。如果像数学家那样说，我们会说，从系统的线形图到其设计组织的线形图，存在同态。
系统映射其设计小组
经验丰富的系统设计人员坚信，任何系统设计，总有一天会有人会在相同的工作上找到更好的设计。换句话说，谈论特定工作的设计是误导的和不正确的，除非是在空间、时间、知识和技术的情景下理解的。对于那些阅读历史或者参考他们记忆的人，这种谦逊是唯一合适的姿态。
F0RTRAN 和 COBOL 等编程语言的设计进程就是一个很好的例子。在五十年代中期，当这些编程语言的原型出现时，它们的编译器甚至比执行它们所需要的巨型（当时）计算机还要笨重。今天，这些翻译者们只是历史遗珠，和如今的编译器没有任何相似之处。（我们应该注意一个事实，编译器设计进程中的“量子跃迁”，与计算机制造商先前践踏的领土上，出现的一群新人的群有关——首先是在大学里紧密的小型研究团队，接着是独立的软件公司。）
那么，如果假设对于任何系统的需求，都有一个系统设计的系列满足该需求，这是合理的；我们还必须询问设计组织的选择是否影响从这个系列中选择的系统设计的过程。如果我们相信我们的同态，那我们必须要承认它的确如此。一个组织在它的沟通结构上不是完全灵活的话，这个组织将会从它生产的每个设计中剔除自己的映射。一个组织越大，它的灵活性就越小，这种现象就越明显。
举例说明，一个合同研究组织有八个人来生产COBOL和ALGOL的编译器。在对难度和时间进行一些初步评估后，五个人被分配了COBOL的工作，3个被分配到ALGOL的工作。结果COBOL编译器分为五个阶段，ALGOL编译器分为三个阶段。
两个军种在总司令的指导下开发了一种通用的武器系统，来满足他们的需求。经过一番努力，他们只做了一份组织结构图。（见图3a）
考虑正在使用的操作系统来解决问题。在高层次的检查中，它由三部分组成：硬件、系统软件和应用程序。（见图3b）与这些子系统相对应的是他们各自的设计者：计算机制造商的程序员，他的系统程序员和用户应用程序的程序员。（那些系统硬件和软件倾向合作而不是仅相互容忍彼此的情况很罕见，与程序员和工程师具有相似关系的制造商有关。）
系统管理
大型系统结构在开发的过程中往往倾向于瓦解，比起小型系统更是如此。当应用到过去十几年的大型军事信息系统时，这个观察极其明显。他们是人类头脑设计的一些最复杂的事物。一种叫做“系统管理”的活动崛起，有一部分是为了应对这种系统瓦解的趋势。让我们检查我们在这里开发的概念，对系统管理的效用。
为什么大型系统会解体？这个过程似乎发生在三个步骤中，前两个是可控的，第三个是我们同态的直接结果。
- 首先，最初的设计者意识到，系统可能会很大，加上组织中的某些压力，因此无法抗拒将很多人分配给设计工作的诱惑。
- 接着，将传统管理的智慧应用在大型的设计组织，会导致其沟通结构的解体。
- 最后，同态确保了系统的结构会反映发生在设计组织中的解体。
让我们先检查一下设计工作人口过密的趋势。当系统的复杂度明显接近他理解的极限时，对最初的设计者（初步的设计概念会影响设计工作的组织的人）来说，委派任务是很自然的。这是设计过程的转折点。要么他努力将系统简化到可以理解并且取胜，要么他失去对系统的控制。如果有进度的压力，有预算需要管理，结果几乎是可以预测的。
经理知道，如果他在没有运用所有资源的情况下，错过了进度，他将被容易受到管理不善的指控。这种知识给最初的设计者带来了巨大的压力，他们也可能更倾向于克服它，而不是通过委托来分割它，但他觉得这样做风险太高而不能冒险。因此，他会被迫通过委派来承担更多的资源。
以下例子说明了另一种但是相关的方式，其中管理者的环境可能与正在设计的系统的完整性发生冲突。
经理必须将一项关键而困难的设计任务分包出去。他可以选择两个承包商，一个是小型的新组织，它提出一种比预算少的多的直观吸引方法，以及一个既定的但传统的装备，它要求更“现实”的费用。他知道，如果这个年轻有为的组织没有产生充足的结果，他会被职责管理不善，而如果老牌组织失败，就会证明问题的确很棘手。
这里有什么困难？其中很大一部分与源自传统会计理论中资源的计量的推理有关。根据这个理论，资源的单位是美元，所有的资源必须使用可交换成美元的计量单位来计量。如果是人力资源，计量单位就是每个人工作的小时数乘以他每小时的价钱，总和为整个劳动力。
这种计算背后的一个谬误是线性属性，即两个人工作一年或一百个人工作一周（每个人的每小时成本相同）是等价的资源。假设两个人和一百个人不能在同一个组织结构中工作（这是很直观，将在下面讨论）我们的同态理论说明了，他们不会设计类似的系统；因此，他们努力的价值甚至可能无法相提并论。从经验中我们知道这两个人，如果他们选择得很好并且在经历中幸存下来，会给我们一个更好的系统。 用于剥土豆皮和竖起砖墙的假设不适用于系统设计。
帕金森定律 [4] 在设计工作的过度分配中起着重要作用。只要经理的声望和权力与其预算规模挂钩，他就会有动力扩展他的组织。这是管理系统设计活动的不当动机。当然，一旦组织存在，它将被使用。 现在存在的许多设计不佳的系统，其背后最大的一个共同因素，可能是需要工作的设计组织的可用性。
系统设计解体的第二步——设计组织通信结构的碎片化——在委派开始之后就开始了。初等概率论告诉我们，一个组织中可能的沟通路径的数量大约是该组织中人数的平方的一半。即使在一个中等规模的组织中，也有必要限制沟通，以便人们能够让一些“工作”完成。引导设计人员之间更有效交流的技术的研究，将在系统管理技术中发挥极其重要的作用。
常见的管理实践，在代表军事组织管理结构的线性图的复杂性上，施加了一定的数值限制。具体的说，每个人最多只有一个上级，最多约有七个下属，以至于组织协议限制通信像是命令，毕竟组织的通信结构类似它的管理结构。这就是军事组织设计的系系统，看起来像他们的组织结构图的原因之一。
结论
本文的基本论点是，设计系统（此处使用广义上）的组织被限制生产这些，组织的通信结构的副本的设计。我们已经看到，这个事实对系统设计的管理具有重要意义。首先，我们已经找到了一个设计组织结构的标准：设计工作应该根据沟通的需要来组织。
这个标准会产生问题，因为随时通信的需要，取决于当时有效的系统概念。因为最先出现的设计几乎从来不是最好的，所以流行的系统概念可能需要改变。因此，组织的灵活性对于有效设计很重要。
必须要找到奖励设计管理者保持组织精简和灵活的方法。需要一种系统设计管理的哲学，它不是基于增加人力就能简单增加生产力的假设。这种哲学的发展有希望挖掘关于资源价值和通信技术的基本问题，这些问题需要在我们系统构建技术能够自信发展之前得到解答。
Notes
[1] John Kenneth Galbraith 的 The New Industrial State（波士顿，Houghton Mifflin，1967 年）对系统设计组织的行为进行了相关但更全面的讨论。 尤其参见第六章“技术结构”。
[2] 有关设计活动在功能环境中采用项目形式时可能出现的问题的讨论，请参阅 CJ Middleton，“如何建立项目组织”，哈佛商业评论，1967 年 3 月至 4 月 ，第 73页。
[3] 可以通过多种方式来看待这种说法。 这可能是微不足道的，取决于有意义的谈判的定义。 或者，这可能是观察到的结果，除非[这样做]绝对必要，否则一个设计团队几乎永远不会为了满足另一个团队的需求而妥协自己的设计。
[4] C. Northcote Parkinson，帕金森定律和其他行政管理研究（波士顿，霍顿米夫林，1957 年）。
