副标题：design organization criteria
引用：Conway M E. How do committees invent[J]. Datamation, 1968, 14(4): 28-31.
马尔文·康威在这篇论文中提出了”康威定律“，该文档是对论文的学习和理解。
因为这篇论文是管理学方向的，所以有些地方的理解可能有误，只能尽可能结合自己的工作经验来翻译和理解这篇论文。
另外，论文不是“AIMRD”结构的，因此，文档是按照论文顺序对内容翻译了一遍，并没有与其他论文做对比。
introduction
“设计一个系统（the design of a system）”是指从一些分散的部分创造出有用的整体这一智力行为，无论这一行为是创建一个武器系统、提出一个建议来解决社会问题，或者电脑编程，活动大体上是相似的（the general activity is largely the same）。 一般来讲，设计组织的目标是创建和汇总一个包含”连贯的结构化的信息体“的文档，我们称这样的信息为”系统设计（system design）“，该文档称为”系统设计文档“。通常，“赞助商（sponsor）“想使用“系统设计文档“来指导他的设计活动。比如，一个政府官员希望通过立法来避免某种灾难再次发生，随后他指派一个团队来解释这个灾难；或者工厂需要一个新型产品，指定一个“产品计划活动”来确定应该引入什么产品。
作者给出了“设计一个系统”的定义，并指出不同的设计行为大体上是相似的。后面的内容，应该是围绕“设计一个系统”的共性或共同问题进行讨论。
-
从设计组织的目标来看，共性是：产出一个设计文档，设计文档内容就是“系统设计”相关的信息。
-
从设计文档的作用来看，共性是：“赞助商”能够根据设计文档来指导自己的设计生产活动。
潜台词是：设计文档必须能够解决“赞助商”的问题，满足他们的需求。在"参考阅读1"中，就指出了“系统架构的目标是解决利益相关者的关注点“，这里的”赞助商“就是”利益相关者“，他们的设计生产活动就是”关注点、需求“，设计一个系统或产出的设计文档就是为了解决“赞助商”的“关注点”。
文中举了两个例子“解释社会问题、产品计划活动”，都是“赞助商”的需求，他们需要的文档就是对应的“设计文档”，前者是灾难原理解释文档，后者是活动的策划案。两者看起来不一样，但是从“设计一个系统”的抽象层次来看，都是把一些分散的部分整理成一个整体，两者在这个层次上是一致的。
目前为止，”设计一个系统”的大概过程如下：
“赞助商”提出需求 --> 指定设计组织 --> 产出设计文档 --> 根据设计文档设计系统
设计组织并不一定会参与它们所设计系统的实施中。通常来讲，在公共领域会有政策禁止一个组织实施它们自己的建议，在私企中则相反。 有理由假设这样的一个“共识”：一个设计组织实施自己的设计或者把这个任务指派给其他组织来实施，会影响到设计师（在设计文档中）所做的“设计选择”。大部分设计活动需要连续不断地做选择，很多选择不仅仅是设计上的决策，它们（决策）可能关系到设计设计师个人的未来前途。我们后面会看到，在一些传统的管理环境中，一些激励政策会鼓励设计师去做一些违反“赞助商意图”的决策。
从“实施过程”角度来看，共性是：
- 实施一个设计文档需要连续不断地做出选择，由文档的设计组织来实施还是由其他人来实施，这两者的差异会影响到文档中的“设计选择”。
- 做出的选择不仅仅关于“设计“的，还关系到设计师个人的前途，这个和他所在的管理环境有关。
个人理解：
这里“选择（choice）”的含义，应该是指设计师编写设计文档时，对一些问题的权衡利弊后做出的决策，比如一个功能为什么这样设计而不是那样设计、为什么一个功能给这个团队做而不是给另一个团队做。很显然，如果组织A给出了一个设计文档，组织B来实施，那么在实施过程中，组织B必然不会100%按照文档来实施，它会根据具体情况和利益关系做出改变。
stages of design
在这一小节中，作者介绍了设计系统的前期步骤和整个设计生命周期。
设计工作的前期步骤（The initial stages），关注设计活动的体系构成（structuring）甚于系统本身。在一些确定的、初步的里程碑（前期步骤）通过之前，一个完整的设计活动是不能实施的。设计的初始步骤如下： 1、理解“赞助商”和现实世界对设计活动和系统所施加的边界。 2、达成（形成）系统组织工作的初步概念，从而能够有意义地分配/配置任务组。
在实施设计文档之前，有一些前期工作要做，这些工作更多地是关于“设计活动构成”。这些前期工作有：
1、理解“边界”，这个边界是由“赞助商”和现实世界施加在系统上的。
赞助商的“边界”很好理解：赞助商的需求就是系统的业务边界，比如DDD中的领域边界。
现实世界为什么会给系统施加边界？
个人理解：
- 现实世界的客观条件，决定了赞助商的需求边界能否实现。
- 现实世界各方的关联关系，会影响到系统的业务边界，比如系统中业务A依赖于业务B，但是现实世界中，提供业务A的组织和提供业务B的组织之间，可能没有依赖关系甚至是敌对关系，这就会影响到系统边界的设计。
2、达成系统组织工作的初步概念，从而能够有意义地划分任务组。
系统的组织工作，比如分配任务等，都要求对系统中的一些概念达成共识，比如统一名词术语、统一任务优先级等，在这基础上才能把工作细分，然后分配给不同的工作组来参与设计文档的编写。
设计活动（design activity）一词的含义是什么？
个人理解：
这里“设计活动”应该主要是“编写设计文档（design document）”这一行为，不包括“实施设计文档（construct design document）”这个行为，从论文的小标题可以看出，论文关注点不是“实施”而是“设计”。
稍后我们会看到，“组织一个设计团队”这个行为本身，就表示已经显示地或隐式地（explicitly or otherwise）做了一些设计决策了。对于任何设计团队组织而言，总有一些设计方案选项不能被被这些组织有效地推进，因为没有必要的沟通途径。因此，不存在既有组织又没有“偏见”的设计团队（a design group）。 一旦确定了设计团队的组织方式，就可以把设计活动指派给组织的子组。每次做一次指派，被指派团队的调查权限缩小的同时（somebody's scope of inquiry is narrowed），可以推进的设计方案类别（the class of design alternatives）也会被挤掉。 一旦定义了活动范围，就会产生协调问题（a coordination problem）。任务组之间的协作虽然降低了小团队中个人的生产力，但协作提供了唯一的可能性：即独立的任务组能够将其工作整合到统一的系统设计中。
前面说过，要先做完初期阶段的一些工作，然后才组织设计团队。
因此，当“组织一个设计团队”时，其实已经做完了初期工作，比如理解边界、达成概念一致等。这就意味着已经做了一些”设计选择“，而”设计选择“都是有”偏好（biased）“的，比如为什么这样理解边界、为什么达成这样的共识等等。遵从这些”设计选择“组织“设计团队”，只能推进适用于这些“设计选择”的方案，（不适用于该设计选择的）其他方案（a class of design alternatives）是很难在团队中推进的，因为团队在组织时，没有为其他方案留下沟通渠道。
因此，不存在既有组织又无偏见的团队。
作者继续指出，设计团队组织完成后，就可以给团队中的子组指派任务，并且每次指派都会导致原本备选的设计方案变得越来越少、任务组之间存在协作问题。
个人理解：
当我们遵循某些”设计选择“来组织团队、指派任务时，随着任务不断推进，系统被可修改的余地越来越少，导致其他备选方案不断被排挤。比如我们编写一个设计文档，各个功能之间相互依赖掣肘，随着进度的深入，会发想即使有一些好的方案也不能使用，因为整体的系统设计框架已经确定了，我们必须按照整体的系统设计来取舍，否则会与其他功能冲突。
因此，一个系统的设计生命周期会经历以下步骤： 1、根据基本规则绘制边界 2、系统初步概念的选择 3、根据概念组织活动和指派任务 4、任务之间的协作 5、把子设计统一成一个设计 一个设计活动可能不会直接按照这个列表中的步骤进行。它一旦发现一个新的、更优越的设计概念，可能会重新组织（重新规划设计）。这种不确定性并不受人欢迎，而且对创造（前面的创造性工作）的每一次放弃，都是痛苦且高代价的。当然，从历史学家的观点出发，这一过程是会不断持续重复的，进而有这样的一个现象：永远没有足够的时间把事情做对，但是永远有时间去重做。
总结了一个系统设计生命周期的大致步骤，并给出了一个重要的结论：永远没有足够的时间把事情做对，但是永远有时间去重做。
系统设计生命周期的大致步骤如下：
个人理解：
遵从原本的”设计选择“来实施系统设计活动，工作只能按照既定的规划推进，可选方案越来越少，再加上沟通协作问题，会在推进工作的过程中发现一些更好的概念（为了解决前面的问题而提出或使用），进而想着重构（重新组织、重新规划设计）设计活动。
你会发现，这个过程总是在不断重复，先实现一个功能，过一段时间再去重构，循环往复。从历史学（更长的时间线、更多的样本案例）角度来看，这是一个有趣的现象：你永远没有时间把事情做对（总有更优的概念和设计），但是总有时间再重新做一遍（重构）。
the designed system
这一小节介绍了如何描述一个已经设计好的系统。
任何重要的系统（Any system of consequence）都是由相互连接的子系统构成的。如果要描述一个系统的内部情况，需要描述该系统与外部世界的联系，以及系统内部子系统之间是如何关联的。再往下一层（描述子系统），我们可以用同样的方式，把每个子系统视为一个系统，然后描述它的子系统。这个过程可以不断进行，不断地缩小要描述的系统范围，直到范围小到不需要再细分就能被我们理解。
完成”前期步骤“之后，就可以设计一个系统，就需要对一个已经设计完的系统进行描述，描述思路如下：
- 系统是怎么与外界交互的
- 组成该系统的子系统有哪些
- 子系统之间是怎么关联的
如果要描述子系统，同样可以使用这样的思路。之后，作者举了交通系统的例子，其中有一句：“This is a very heterogeneous system（异构系统）; that is, the subsystems are quite diverse”。 也就是说，系统可以由异构的子系统组成，只要子系统之间能够交互关联即可。比如，一个微服务应用就可以是异构的。
我们可以按照前面“描述系统”的思路来描述一个理论（It may be less obvious that a theory is a system in the same sense），尽管两者似乎不是很明显地存在相似性。理论与它所观察事件的外部世界有关，它必须解释事件或至少与事件不矛盾。 一个理论由子理论组成，并且子理论之间以相同的方式相互关联。例如，对飞机失事的调查试图产生一种解释复杂事件的理论。 它可以由描述飞机路径、无线电通信、损坏方式以及事件发生时与附近物体的关系的子理论组成。 反过来，其中每一个子理论可以进一步细分为更精细的细节，直至单个证据单元的级别。 图1就以“分支”和“节点”的形式来表示一个系统（理论），每一个节点表示一个系统，分支表示接口，系统通过接口与外部沟通，子系统之间通过接口相互沟通和通信。
作者认为，可以用描述系统的思路来描述一个理论，理论同样可以看作是由子理论组成，子理论之间也是相互关联的。
这里突然说到“理论”感觉很突兀，如果你还记得在文章开始时，作者就提过“一个政府官员希望通过立法来避免某种灾难再次发生，随后他指派一个团队来解释这个灾难”、设计文档包含“连贯的结构化的信息体“，就能把理论和系统关联起来了。设计文档中包含的是可以用来指导设计活动的”结构化“的信息体，这结构化的信息体就是（系统设计）理论，它解释了一个事件的原因和处理方式（设计一个系统）。按照这样的文档设计一个系统，那么系统的结构和理论的结构应该是相对应的。
随后，按照前面描述系统的思路，作者使用“线性图”描述了一个系统和它的理论，线形图中主要有两个部分：节点、分支。
relating the two
系统是由组织设计的，这一小节介绍怎么把系统与组织关联起来。
“线性图”为我们正在考虑的两个实体（设计组织和它设计的系统）提供了同一种的抽象形式，这可以在图1中通过替换以下单词来说明： 1、将“系统”改为“委员会”。 2、将“子系统”改为“小组委员会”。 3、将“接口”替换为“协调员”。
与系统一样，我们发现设计组织可以从多个复杂级别上进行观察。 例如，联邦政府是设计组织的一个很好的例子，... 显示了这里研究的两个概念的相似性，因为联邦政府既是一个设计组织（设计法律、条约和政策）又是一个设计系统（宪法是主要的初步设计文件）。
我们现在可以解决本文的基本问题：设计组织的图形结构和它设计的系统的图形结构之间是否存在某种可预测的关系？回答是：是的，这种关系非常简单，在某些情况下它是一致的。考虑下面的“证据”： 我们随机选择某个系统和它的设计组织，然后随机选择相同的复杂度给两者绘制图表。（随机的目的是，如果我们成功地展示了任何有价值的东西，它将适用于任何组合和任何级别的复杂度）。图2展示了与以下状态有关的结构。
系统中任意的节点 x（子系统），我们可以从设计组织中找到它的设计组节点 X（设计团队）；一般而言，系统中的每个节点（子系统），我们都可以通过某种规则在设计组织中找到对应的“设计节点”（设计团队，a corresponding node of the design organization）。需要注意的是，这个规则不是一对一的，两个及以上的子系统可以对应同一个设计团队。 我们可以对分支做出类似的声明。 取系统中的任意两个节点 x 和 y。 他们要么被一个分支连接，要么没有（它们要么以某种对系统运行有意义的方式相互通信，要么不进行通信）。如果节点 x 和 y 之间存在分支，则两个节点对应的设计团队（不一定是不同的）X 和 Y 也必须经过协商确定了沟通规范，从而允许两个设计团队能够进行通信。 另一方面，如果节点 x 和 y 之间没有分支（子系统之间不相互通信），相应的，两个设计组也没有任何东西需要协商，因此 X 和 Y 之间也没有分支。
我们刚刚展示了什么？ 粗略地说，我们演示了：系统结构与设计它的组织结构之间存在非常密切的关系。 常见情况下，每个子系统都有自己对应的设计团队，我们发现设计组织和系统的线性图是相同的。 在某些不常见的情况下，某些设计团队设计了多个子系统，我们发现设计组织的结构是系统结构的折叠版本：具有相同设计团队的子系统节点折叠成一个节点，来表示该设计团队。 两组事物之间的这种”保持结构的关系（a structure-preserving relationship，翻译来自谷歌和百度）“称为“同态”，像数学家一样，我们说，系统的线性图与它设计组织的线性图之间存在“同态”。
在这一部分，作者把“系统线性图“和”设计组织线性图”两者建立了联系，两者之间存在一种“同态”关系：系统线性图中的“子系统节点”用”子设计团队“代替后，就变成了设计组织的线形图，也就是说，设计组织的结构与它所设计系统的结构的线性图是相同的。
systems image their design groups
前面一节指出“系统的结构图”与“设计组织的结构图”两者是相同的，这一小节继续这个话题。从小标题可以看出，作者认为系统反映了它的设计组。
经验丰富的系统设计人员坚信（It is an article of faith among experienced system designers）：任何系统设计，总有一天会有人找到更好的方式来做同样的事。换句话说，如果不是在特定的“空间、时间、知识和技术“背景下，那么谈论特定工作的设计是存在误导性和错误性的。保持这一谦逊的态度，是那些从历史和经验中学习的人（系统设计人员），应该具备的唯一正确姿势（The humility which this belief should impose on system designers is the only appropriate posture for those who read history or consult their memories，实在不知道怎么翻译这句话，只能意译了）。
举例：略。
作者先指出“任何系统设计都会被后人优化”，之后举了“FORTRAN和COBOL语言的编译器”的例子。作者认为，之所以编译器能取得巨大飞跃，与两个群体的出现有关：小型的大学研究团队、独立的软件公司。
这里有一个隐含的内容：系统设计的优化除了与技术的进步迭代有关，还和设计组织的变化有关，也就是说，系统新的实现本身就反应了组织的变化。
因此，可以合理地假设，对于任何需求，都存在一系列（a family of）的系统设计满足它。 我们需要知道，对设计组织的选择是否会影响“从一系列的备选方案中做出选择”这一过程？ 如果我们坚信前面我们提出的“同态”，我们就必须承认，设计组织的选择会影响系统设计方案的选择过程。在某种程度上，一个组织的沟通结构不灵活，该组织会在其制作的每个设计产品中消除自己的形象（image）。一个组织越大、灵活性越低，这种现象越明显。
前面一段指出“系统设计总会有更好的选择”，这一段就指出，选择不同的设计组织，会影响不同系统设计的选择过程。因为根据前面提出的”同态“，每个系统设计的结构与设计组织的结构是相同的，所以不同的组织会选择与满足自己结构的系统设计方案。（举个例子，解决同一个社会问题，资本主义国家和社会主义国家，选择的方案肯定不一样，因为两个国家的组织结构不一样。）
这种影响的程度是怎样的？
作者认为，一个组织的沟通结构越不灵活、组织结构越大，那么在设计的产品中，越会消除自己的影响（stamp out an image of itself）。之后，作者举了两个例子来证明自己的观点，如图2所示。
个人理解：
如果组织内部沟通不灵活，子设计团队各自为政，设计出的子系统也是相互孤立的，这个设计组织会失去对整个系统的影响力和控制力。外在表现就是，这个组织设计出来的系统并不像这个组织。系统的结构的确和组织的结构相同，但是前提条件是组织内部存在有效的沟通路径（线性图中的分支），如果组织中没有有效的沟通路径，那么各个子团队设计出的子系统是孤立且零散的，最终整合出的系统不能反映组织的整体结构（一盘散沙与另一盘散沙并不相同）。
system management
在这一小节中，作者把前面的”同态“理论应用到系统管理领域。
大系统的结构在发展过程中往往比小系统更倾向于解体，在观察过去几十年的大型军事信息系统（人类设计的最复杂的物体之一）时，这一现象极为明显。一种称为“系统管理”的活动的兴起，部分是为了应对这种系统解体的趋势。让我们来检测一下，我们在这里提出的概念对“系统管理”的效用（the utility to system management）。 为什么大型系统会解体？这一过程似乎分为三个步骤，前两个步骤是可控的，第三个步骤是我们的“同态”的直接结果。 第一，最初的设计师意识到系统会很大，再加上他们组织中的某些压力，不可抗拒地分派太多人参与设计工作。 第二，将传统管理智慧应用于大型设计组织会导致其沟通结构解体。 第三，“同态”确保系统的结构将反映设计组织中发生的解体。
作者把“同态”理论应用到“系统管理”，来解释为什么大型系统会倾向于解体。
作者认为“同态”主要是作用在第三步：当组织解体时，会同步到系统中，导致系统解体。
首先，让我们来研究一下设计工作中存在的人员过剩的趋势问题。
当系统的复杂性接近其理解极限时（the apparent complexity of the system approaches his limits of comprehension），初始设计人员（其设计概念影响设计工作的组织）自然会受到“指派更多人参与”的诱惑。这其实是设计过程的一个转折点，要么他可以努力将系统简化为可理解的系统并获胜，要么他将失去对系统的控制。如果还有外在的进度压力和预算管理，结果几乎是可以预测的，必然会失去对系统的控制。 一个管理者（manager）知道，如果他没有运用所有资源而导致自己错过了进度安排，他将受到管理不善的指控。这一认知给设计师带来了巨大的压力，导致他们更愿意（通过增加人员）与“设计”抗争，而不是把任务做碎片化地委派分割（他感到风险的成本太高，不敢冒险）。因此，为了带来更多的资源，他被迫授权更多的人参与设计。
作者认为导致“人员过剩”的一种原因：迫于系统设计的复杂度、风险和进度压力，设计人员（管理人员）不敢把设计拆分，只能通过投入更多的人力资源来保证进度。
是否还记得，在文章开始之处，作者曾指出“设计是一个连续不断的选择过程，有些选择是出于设计师对自己前途的考虑”。很显然，在做设计选择时，更多时候不是选择更优的方案，而是选择当前可行的方案（哪怕后面崩溃了）。
下面的案例说明了另一种相关的方式，在这种方式下，管理员（设计人员、经理）所处的环境可能与正在设计的系统的完整性之间存在冲突。
管理员（设计人员经理）必须将一项关键而困难的设计任务指派给某个工作团队（subcontract a crucial and difficult design task）。他可以选择两个承包商：
- 一个新成立的小型组织，它提出了一种直观而有吸引力的方法，需要更少的预算；
- 一个是一个成熟但传统的组织，要求更“现实”的费用。
他知道，如果这个年轻的新组织失败了，他会被指控管理不善，而如果那个传统组织失败了，只是证明了这个任务的确是一个难题。
这里的困难是什么？其中很大一部分与传统会计理论中资源计量的方式有关。根据这一理论，... 如果资源是人力，则计量单位是每个人的工作小时数乘以其每小时成本，累加求和即时整个工作的成本（the number of hours worked by each man times his hourly cost, summed up for the whole working force）。
这一计算背后的一个 谬误 是，这种计算方式隐含的“线性”性质，即两个人工作一年或一百个人工作一周（每个人每小时的成本相同）所花费的人力资源是相等的（resources of equal value）。假设两个人和一百个人不能在相同结构的组织中工作（这是显而易见的），我们的“同态”理论表示，他们不会设计出相似的系统；因此，他们工作的价值就可能不具备可比性。... 在“剥马铃薯和切墙砖”中有效的假设（传统的资源计量方式），对系统设计并不适用（Assumptions which may be adequate for peeling potatoes and erecting brick walls fail for designing systems）。
帕金森第三定律参考阅读2，在设计工作的总体设计中起着重要作用。只要管理者的威望和权力与他的预算规模两者相匹配，他就会扩大他的组织人员。在系统设计活动的管理中，这是一种不当动机。但是，只要组织存在，（这种不当权力）就会被使用。
目前许多设计糟糕的系统背后，最大的共同因素是：设计组织的可用性（存在问题）。
作者认为另一种导致“人员过剩”的原因有两个：
- 传统的人力资源计量方式有问题
- 帕金森第三定律
传统的人力资源是按照“人天”的线性总和来衡量一项工作的复杂度，导致管理者在选择团队时，为了避免受到管理不善的指控，只会选择成熟的传统组织，而不会选择新生代的设计团队。成熟的传统组织的人员组织方式符合传统的人力资源计量方式，而新生组织则不然，所以在传统计量理论的思维惯性下，管理者更倾向于选择传统组织。
实际上我们知道，2个人的团队和100个人的团队，组织结构是完全不同的。根据“同态”理论，即使他们花费相同的人力资源，他们设计出的系统也是不同的。所以，新生组织与传统组织设计出的两套系统必然是不同的，不具备可比性。进而得出结论：传统的人力计量方式在系统设计领域是失效的。
另外，在“传统人力资源计量方式”和“帕金森第三定律”的作用下，管理者会在自己职权范围内扩充团队人员（管理者认为只要线性增加人员数量，就能提高产出）。
这两个原因，导致了设计组织人员过剩，进一步导致了组织的可用性出现问题，（根据“同态”理论）当组织可用性出现问题时，它所设计的系统也必然是脆弱的（poorly designed systems ）。
当任务开始委派之后，系统设计解体的第二步——设计组织沟通结构的解体——就开始了。概率论的基础知识告诉我们，一个组织中可能存在的沟通路径数量大约是组织中人数平方的一半（half the square of the number of people）。即使在中小规模的组织中，也有必要限制沟通方式，从而让也员工能有效地完成一些工作。在系统管理中，使设计人员之间能够进行更有效沟通的技术研究，将发挥极其重要的作用。 通常的管理实践中，会对军事组织的线性图的复杂性施加一些数值上限制。具体而言（Specifically），每个士兵最多有一名上级，最多有七名下级。由于组织规章限制了沟通只能沿着指挥线进行（that organizational protocol restricts communication along lines of command），所以组织的沟通结构保留了组织的管理结构，这就是为什么军事化组织所设计系统看起来像他们的组织结构的原因之一。
在系统解体的第一步中，因为设计人员的压力、管理者对人力资源衡量方式的认知错误，导致了设计组织人员过剩。人员过剩又会导致第二步的解体：沟通结构的解体。因为一个组织中的沟通方式约等于 ，其中 是组织中的人员数量，所以当人员过剩时，会导致沟通方式呈指数增长（**个人理解：**这里的沟通方式，不仅仅是沟通渠道，还有对一些概念的理解和表达等，每个人对同一个概念的表述和理解都不同，导致了沟通成本增加，所以在设计系统之前，要先统一概念），从而导致沟通方式的解体。
conclusion
本文的基本论点是：设计系统的组织（广义上的组织）被限制只能生成复制该组织沟通结构的系统设计。我们已经看到，这一事实对系统设计的管理具有重要意义。我们初步找到了设计组织结构的标准：设计工作应该根据沟通的需要进行组织。
这个标准会产生问题，因为在任何时候进行沟通的需要取决于当时对系统概念的认识，然而首先选择的设计通常不是最优的，所以系统概念会不断改变。因此，组织（沟通）的灵活性对有效的设计非常重要。
需要找到一个有效的奖励机制，让管理者能够保持组织的精简和灵活。需要一种新的系统设计管理理念，这种理念不会认为简单地增加人力就能增加产出（adding manpower simply adds to productivity）。对这种新理念的发展，有望发掘出有关“资源价值和沟通技术”的一些基本问题，在我们在继续发展系统构建技术之前，要回答好这些问题。
参考阅读
关注公众号“CodeGo编程笔记”，一起从入门到精通。