产品必读：“康威定律”对组织论、沟通成本、微服务的启发.docxVIP

产品必读：“康威定律”对组织论、沟通成本、微服务的启发 “组织形式等同系统设计”——这就是康威定律（Conway’s Law）阐述的一个关键思想。Conway’s Law () 其原话是这样的： Organizationswhichdesignsystemsareconstrainedtoproducedesignswhicharecopiesofthecommunicationstructuresoftheseorganizations.-MelvinConway(1967) 中文直译大概的意思就是：设计系统的组织，其产生的设计等同于组织之内、组织之间的沟通结构。 但是其思想启发远不止于此。 本文目录如下： 团队组织＆产品架构设计。 沟通成本 = n(n-1)/2。 孤岛系统的集成接口量。 康威定律与微服务的合理性。 一、团队组织＆产品架构设计 面试的时候，面试官问我们有什么要问的，实在想不出的时候，你就问问团队组织架构吧。 这不仅仅是关乎到自己入职后的汇报协作，同时也是对产品系统架构的预估。 为什么呢？因为组织结构往往代表一种协作分工，而分工的产物就是产品。 所以，团队组织形式，首先体现在系统上。 比如Apple的产品、微软等的产品脚骨设计，就能形象生动的理解这句话。 从这张图也可以看出： 亚马逊等级森严且有序；谷歌结构清晰，产品和部门之间却相互交错且混乱；Facebook架构分散，就像一张散开的网络；微软内部各自占山为王，军阀作风深入骨髓；苹果一个人说了算，而那个人路人皆知；庞大的甲骨文，臃肿的法务部显然要比工程部门更加重要。 多年前，更有人在《第一财经周刊》尝试着炮制了一份中国主要的科技公司的结构图—百度、腾讯、华为、联想、阿里巴巴、新浪。 结果发现，它们也是彼此风格迥异(和今天的实际情况已经不一样了)：华为，技术创新引发矩阵结构变化；阿里巴巴，马云的影子无时无处不在；新浪，依托微博画了一张大饼；百度崇尚简单；联想，大小通吃但又左右互搏；腾讯，产品与部门关系千丝万缕，QQ是所有产品与服务的基石。 这给我们的启发就是，想要什么样的系统，就搭建什么样的团队。 比如，如果系统是按照业务边界划分的，大家按照一个业务目标去把自己的模块做出小系统，小产品的话，你的大系统就会长成下面的样子，即微服务的架构： 这个思想，其实就来自于康威定律。 二、沟通成本 = n(n-1)/2 《人月神话》中最著名的一句话就是: Addingmanpowertoalatesoftwareprojectmakesitlater–FredBrooks,(1975) 之所以这样，是因为沟通成本 = n(n-1)/2。 沟通成本随着项目或者组织的人员增加呈指数级增长。举个例子： 5个人的项目组，需要沟通的渠道是 5*(5–1)/2 = 1015个人的项目组，需要沟通的渠道是15*(15–1)/2 = 10550个人的项目组，需要沟通的渠道是50*(50–1)/2 = 1,225150个人的项目组，需要沟通的渠道是150*(150–1)/2 = 11,175 为什么这样呢？国外的研究：灵长类的大脑容量和其对应的族群大小有一定关联： 从而推测出人类的大脑智力只能支持我们维系这么多的关系:亲密（intimate）朋友: 5信任（trusted）朋友: 15酒肉（close）朋友: 35照面（casual）朋友: 150再多的化，沟通的问题，会带来系统设计的问题，进而影响整个系统的开发效率和最终产品结果。150也就成了很多设计的参标，比如某系统的购物车最大允许200个商品（涵盖150）。 所以，一个大的组织因为沟通成本/管理问题，总为被拆分成一个个小团队。每个经理都被赋予一定的职责去做大系统的某一小部分，他们和大系统便有了沟通的边界。 三、孤岛系统的集成接口量 说一个案例：随着医院信息化建设的不断完善，医院逐步上线了 HIS、EMR、PACS、LIS 等多个业务系统。由于这些业务系统由不同厂家开发，各个系统拥有不同的操作系统、数据库，进而导致不同业务系统之间需求调用复杂、接口数量多且无统一标准、数据交互效率低下、维护困难等问题。 正如人月神话提出的，随着项目或者组织的人员增加呈指数级增长，沟通成本 = n(n-1)/2，传统模式下各个孤立系统对接时候的接口开发最大数量也是N*(N-1)/2。 这就导致实现成本很高，于是出现很多集成平台。 集成平台的重要性在于，其不仅能够在各个系统之间实现统一集成和交互，同时为数据集成提供了可能。 通过将各个系统产生的数据集中存储并重新组织形成医院的数据仓库，集成平台为下一步数据分析创造条件，即充分挖掘数据价值进而形成一系列数字化应用支撑智能化决策，帮助医院实现真正数字化转型。 可以说，集成平台是医院数字化转型的重要基础。市场出现很多