委员会是如何被发明的？（康威定律）
这是一个奇怪的题目，也许有人会以为这是一篇讲政治学的文章，其实这是提出了“康威定律（Conways's law）”文章的原名。
Conway先生是美国资深的软件工程师和思考者，在1968年发表了这篇文章。1975年，软件工程专家Brooks集结出版著名的《人月神话》，并在其中的一篇文章引用了Conway本文的观点，并称之为“康威定律”。
Conway的这篇文章，其实并不是讲“委员会”的诞生历史，而是讲系统设计的。其观点就是——设计组织的“信息交互结构”会影响其设计出来的系统。
这个结论是有数学理论来支撑的，即“同态”（homomorphism）。也就是说：“系统的结构”与“其设计组织的信息交互结构”是“同态”的。
Conway的定律与文章不如《人月神话》那么有名气，但从时间线上来看，后者应该是受了前者的一些影响。
大时代的大背景
我们现代人时常挂在嘴边的：信息、控制（管控）、系统等这些名词，至今都不到百年的历史，都是一些“新”词。
1940年代，无论是政治还是科技，都是一个大时代。这个时期诞生了三大科技理论：信息论、控制论、系统论。其中，信息论的影响最为深远，一直到今天还在蓬勃发展；信息论是控制论的基础，二者共同成为系统论的研究方法。
什么是系统？是一个大问题，我也只能简单讲一下系统的重要特点——系统是由“部分”或“子系统”组成的；但其整体功能要大于各个部分（子系统）的功能之和。
人体就是一个典型的、至今我们不能完全了解的系统。我们想要消灭新冠病毒，只能是依靠自身的“免疫子系统”。
现在，很多软件组织都在称他们的“产出物”是xx系统。这其实是需要加上问号的——很多软件先天不足，根本无法“存在”，所以很难被称之为系统。
系统设计与步骤
将“部分”整合为“整体”的智力活动被称为“系统设计”（在西方的语境中，设计design这个词含义深刻，本文不展开）。
系统设计工作的产出物，是一份条理清楚、逻辑自洽的文档。后续，出资方会要求实施团队严格按照此“设计方案”来构建/制造/培育/训练系统。
系统设计工作的第一步是什么？
并不是明确“系统”的定义，而是要明确如何来开展设计工作，可以称之为“准备阶段”；主要有以下两个步骤：
1、讨论“系统”以及“设计工作”的边界。
2、确定承担设计工作的团队。
这两步非常必要，如果不进行，后续的工作就无法有效地开展。
完成了上述的准备阶段，接下来，设计工作的生命周期大致可以分为以下步骤：
1、明确并记录“系统”以及“设计工作”的边界；
2、确定系统的概念设计；
3、根据概念设计来组织、分配设计任务；
4、在各个任务之间进行协调；
5、将各个任务的成果整合为系统。
上述的步骤，也不是一成不变的。当设计团队发现了更好的“概念设计”时，这个过程很有可能会反复。
为此，Conway说了句名言：永远没有足够的时间去把事情做正确，但总有足够的时间重新去做。
这个现象直至今天都很普遍，我们经常能听到——XX软件要重构；XX咨询项目要重新实施。
有经验的设计者，应该有一个信条：任何的系统设计，总有一天会有人找到更好的方案来实现。换句话说，所有的设计方案都有局限性——局限于特定的空间、时间、知识和技术。
所以，每一个合格的设计者，永远都应该心怀谦逊与敬畏。
系统与信息交互
任何系统都是由子系统组成的，子系统也会不断去细分为更小的子系统。
例如：“碳中和”是系统；清洁能源交通、清洁能源发电等就是子系统。
新能源车是清洁能源交通的一个子系统，其本身又分为电池、电驱、软件等子系统；对于电池而言，又可以分为正极、负极、隔膜等子系统。不断的细分，最后都可以细分到逻辑上的“原子功能”层面。在当代软件工程行业，对此有专门的术语：基本过程、用户目标等。
要设计系统，一定要描述系统（子系统）如何与外部世界进行信息交互。系统（子系统）对外信息交互的渠道，被称之为“接口”——这个词在1960年代的后期，还是很时髦的。
为什么信息交互如此重要？可以用物理学家约翰·惠勒的论断“一切皆自比特”（It from bit）来回答。如果要深入理解，推荐阅读吴军的《信息传》，格雷克《信息简史》以及香农先生的《通信的数学原理》。
每个“系统”都会对应一个设计组织，我们可以将这个组织称之为“委员会”；“子系统”对应的设计小组，可以称之为“小组委员会”。系统之间的“接口”对应“联络员”。
在这里，Conway引用了离散数学中“同态”的概念。他将系统视为一个“集合”，设计组织（委员会）视为另一个“集合”。这两个集合之间，一个“子系统”肯定对应一个设计小组，一个设计小组可能会设计多个“子系统”。如果两个子系统之间有接口（明确的信息交互规范），那么对应的两个设计小组之间一定要有联络员；如果两个子系统之间没有接口，那么两个设计小组也就不用进行“正式沟通”。
因此，“系统”与其“设计组织”两者的信息交互结构是“同态”的。
Conway拿美国联邦政府举例，其是被“国父们”设计出来的系统，同时也是一个设计组织。美国政府下设了众多的委员会，设计了相应政治、法律、金融、医疗等系统。
这里插一句，我对美国软件工程领域里“知识阶层”的认识。他们中的一些人尽管身在IT行业，但是言语总是喜欢与政治挂钩，总想着世界和平、消灭瘟疫与贫困之类的大目标；对他们的国父、宪法，有着比较深刻的认同。
系统映射组织
作为设计者，我们应该有信心——所有的问题（problem）都有办法被解决；也就是说，所有的需求，都可以设计出合适的解决方案。但是，我们为什么还是看到了那么多失败的案例，系统的出资方（管理层），应该思考：问题是否就出自问题的解决者？
如果，我们相信数学，相信“同态”的理论。我们就要认可：系统会“映射”出组织的“特点”。
设计的团队选定了，系统的命运也就是被决定了。在人类世界中没有“完美”的设计团队——即有组织性，又不带偏见。
设计团队选定了后，工作会被继续不断的细分到小组，到个人。每一次的细分，系统的“可能性”也就随之缩小了。
诺基亚（的设计团队）设计不出智能手机（系统）；阿里巴巴设计不出社交系统；印度政府设计不出有效的疫情防控系统。我的亲身经历就是：传统的直线职能式的软件研发组织，设计不出项目管理系统。
系统的瓦解
1940年代，随着信息论的出现，计算机与软件被发明，财大气粗的美国军方立刻就着手开发了众多的大型信息管理系统。然后他们很快就发现，这些大系统在开发的过程中往往会“支离破碎”（这也是1960年代“软件工程”诞生的原因之一）。
为什么大系统会“瓦解”？
一、由于系统自身的原因，以及管理层的要求，设计组织往往会选择不断“加人”。
二、由于不断的“加人”，设计组织的信息交互结构一定会被“解构”。
三、由于“同态”（康威定律）的存在，设计组织信息交互的“特点”，一定会传递给系统。
第一点：最初的设计者（即所谓的“总设计师”），初始时会专心于系统设计，因为他们知道：人数增多后组织一定会“人浮于事”。然而随后，他会发现自己的能力不足，风险成本太高，自然会想到去扩大队伍，分配任务，专注于所谓的“系统管理”。
总设计师（产品总监）如此，下面几个层次的设计师（产品经理）也会继续“上行下效”。
在这个分配任务的环节，其实已经就是系统的转折点了。设计师们有两个选择：1：努力简化，使得系统在自己的这个层面可理解和掌控；2：逐步失去对系统的控制，听天由命。
如果某个管理者发现自己的能力不足，会有3个选择：1、让位；2、选择一个比自己优秀的人来辅助；3、选择多个平庸的人来辅助。
1958年，英国的学者对此现象进行了研究，发布了“帕金森定律”，其结论就是：一般而言，“聪明”的管理者会选择第3项。
这个定律，在系统设计领域尤其突出。根据Conway的描述，在1960年代的美国，已经就是有了一堆所谓的“不良”系统，其本质的原因就是设计组织的人员冗余，且这些人员要让自身“显得”重要且忙碌。
第二点，也是有数学证明的——组织内信息交互的通道会随着人数的增加，而呈“指数级”的增加。所以，不可能让每一个成员都进行自由的工作沟通，为了有效的管理，只能是建立起有特点的、被“解构”的信息交互结构。
Conway评价很多组织还是在用“传统”的管理（信息交互）模式来管理信息产业。例如：1个人只能有1个领导；1个人最多领导7个人。然然而，这个实践直到今天，还是被很多组织采纳。
系统设计的风险
Conway的文章并没有详细提交系统的实施团队，他的假设是实施团队一定会按照设计稿严格执行的。这个假设在1960年代的美国也许是成立的。
但是在21世纪的中国软件工程行业，这个假设很可能不成立。
设计与实施团队——在中国的业界，被形象地比喻为：“挖坑”与“填坑”的。最后谁会影响（管理）谁，还不好说。
设计团队与实施团队有可能是同一个；也有可能是分离的。Conway先生认为：具体的、实际的活由谁来干，会直接影响设计师的设计选择。
经过不断地细分，设计工作一定会落到具体的“设计师”身上——他们也许被称之为PM(产品经理/项目经理)、BA或SA。在系统设计的过程中，他们会不断地做出选择，这种选择不仅仅是系统的设计决策，往往也包含对个人未来的选择。
在1980年代，西方经济学家总结出一个经济学术语——道德风险（Moral Hazard）——人们执行活动，却不用全部或部分地为此活动的后果负责，所以会选择自身效用最大的自私行为。
这个风险，对于设计活动的影响很大。
故事1。我曾经为某研发组织做度量系统的流程设计，他们的接口人（内部的设计师），最关心的就是某项工作的执行人是谁？（他主要是担心由他去承担“麻烦”，同时又想着能够“出彩”）
故事2。国内的传统软件企业，其KPI就是合同款按时收回，因此推导给研发组织的KPI就是系统按时交付。至于系统是否可以实施？客户是否能够使用系统？是否可以给客户带来价值？与研发组织的考核无关。
在这种信息结构下，产品经理（设计师）可以不受任何约束地“挖坑”。到了最后，产品总监迫不得已地来“敷衍”。如此，产品与研发团队的奖金都可以兑现了。至于在坑里的实施团队和客户，谁关心？
故事3。来自Conway的原文，某位经理准备将一项关键的设计工作外包，有两个供应商可供选择：1、新成立的小型组织，方案新颖，且报价远低于预算；2、一个老牌的传统企业，报价比较“现实”。
“聪明”的经理知道选择1，如果结果不理想，对于他自己的风险很大；选择2的话，即使是失败了，他也可以推卸责任——事实证明了这个问题的确很难。
这个现象，很多年以后在中国也在上演，某些企业的CIO，在数字化（信息化）设计的过程中，往往倾向于选择国际大厂。其理由就是，连XXX都实施失败了，那么其他厂商就更加没戏了。
但是，真正的难点是什么？Conway认为是由于传统的“会计理论”，其对于“人力费用”的计算公式=工作量*单价。工作量的计量单位，一般就是著名的“人月”。
2个人工作1年与24个人工作1个月，其工作量是相等的，在会计上费用是相等的；但是否可以假设两者产产出的“价值”是相等的呢？
换一个说法，系统设计工作的“人月”越多，产出的价值就越大吗？
如果是割麦子、砌墙之类的工作，这个假设也许是成立的。但是在系统设计上，这个假设不成立。因为两者在1960年代还是没有办法比较。（下文有描述，到了1970年代后期，专家们发明了科学的度量方法）
根据常识，我们可以知道：小而精的团队，其设计出来的高质量系统的可能性会高。因为通过康威定律可以推导出——组织越大，其信息交互的灵活性就越差。
解决之道
Conway在1960年代，就指出了对于系统设计之类的工作，不应该受传统的管理模式（例如：帕金森定律、简单会计度量与核算等）的约束，而是要发明一种新的管理制度，新的管理哲学，来鼓励设计经理保持设计团队的精益（lean）与灵活。设计组织，可以根据系统的特点——信息交互的需求——而灵活变化。
如何有效提升设计工作的效能？Conway认为也许可以从这两个维度来解决：人员的价值，信息交互的技术。
应该说他遗抛出的问题，是西方管理学、哲学上经典的问题。他的文章也是影响和启发了一批软件工程专家。Brooks，在1975年发表了《人月神话》；以及其后的《没有银弹》（1986年），《设计原本》（2009年）。都是有意无意地在解答上述问题。
1979年，Allan Albrecht发布了的功能点分析（FPA）方法，从软件的规模度量上回答了他的一些问题。至少，系统设计的规模是可以度量、比较的了。
其实，对于中国软件工程而言。建立真正的“产品（设计）委员会”本身就是一个好的方案。
“委员会”（日本人翻译的中文词），这种政治制度，起源于古罗马，后来被英国、美国继承和发扬，并在全球范围被广泛认可。这种组织最大的特点就是“民主”，不会被愚蠢独裁。
无论是软件工程行业，还是其他领域。系统的设计是最重要的，是“主要任务”；后续的实施工作其实只是“次要任务”。我们要不断反思，自己是否受到了“康威定律”的影响？