vlambda博客
学习文章列表

• 1 前言

• 2 康威定律

• 3 康威定律在实践中的一点思考

• 3.1 一个现有的产品开发组织架构

• 3.2 现有组织架构内外环境及引发的问题

• 3.3 如何解决现有组织架构问题？

• 4 总结

• 5 参考资料

1 前言

以前我们或多或少都听说过一些定律，比如木桶定律、墨菲定律、摩尔定律、鲇鱼效应、多米诺骨牌效应、马太效应等等等等。在软件工程领域中，也有适用软件开发和组织管理的经典定律和原则，这些经典的定律和原则被程序员上传到了代码托管平台Github 上，并且被翻译成了多国语言版本，中文版可见https://github.com/nusr/hacker-laws-zh。这里罗列一下：

• 定律
• 阿姆达尔定律 (Amdahl's Law)
• 破窗效应 (The Broken Windows Theory)
• 布鲁克斯法则 (Brooks's Law)
• 康威定律 (Conway's Law)
• 坎宁汉姆定律 (Cunningham's Law)
• 邓巴数字 (Dunbar's Number)
• 盖尔定律 (Gall's Law)
• 古德哈特定律 (Goodhart's Law)
• 汉隆的剃刀 (Hanlon's Razor)
• 侯世达定律 (Hofstadter's Law)
• 哈伯特定律 (Hutber's Law)
• 技术成熟度曲线 (The Hype Cycle or Amara's Law)
• 隐式接口定律 (Hyrum's Law or The Law of Implicit Interfaces)
• 柯林汉定律 (Kernighan's Law)
• 梅特卡夫定律 (Metcalfe's Law)
• 摩尔定律 (Moore's Law)
• 墨菲定律 (Murphy's Law / Sod's Law)
• 奥卡姆剃刀 (Occam's Razor)
• 帕金森定理 (Parkinson's Law)
• 过早优化效应 (Premature Optimization Effect)
• 普特定律 (Putt's Law)
• 里德定律 (Reed's Law)
• 复杂性守恒定律 (The Law of Conservation of Complexity or Tesler's Law)
• 抽象泄漏定律 (The Law of Leaky Abstractions)
• 帕金森琐碎定理 (The Law of Triviality)
• Unix 哲学 (The Unix Philosophy)
• Spotify 模型 (The Spotify Model)
• 沃德勒定律 (Wadler's Law)
• 惠顿定律 (Wheaton's Law)
• 原则
• 单一功能原则 (The Single Responsibility Principle)
• 开闭原则 (The Open/Closed Principle)
• 里氏替换原则 (The Liskov Substitution Principle)
• 接口隔离原则 (The Interface Segregation Principle)
• 依赖反转原则 (The Dependency Inversion Principle)
• 呆伯特法则 (The Dilbert Principle)
• 帕累托法则 (The Pareto Principle or The 80/20 Rule)
• 彼得原理 (The Peter Principle)
• 鲁棒性原则 (The Robustness Principle or Postel's Law)
• SOLID
• 不要重复你自己原则 (The DRY Principle)
• KISS 原则 (The KISS Principle)
• 你不需要它原则 (YAGNI)
• 分布式计算的谬论 (The Fallacies of Distributed Computing)

注：这个仓库包含对一些定律、原则以及模式的解释，但不提倡其中任何一个。它们的应用始终存在着争论，并且很大程度上取决于你正在做什么。

这些定律和原则或总结了我们经常会犯的错误，或总结了软件开发中的指导性规律，或如何指导团队高效的工作等。

这里我并不想罗列所有的定律和原则具有什么指导意义，刚好对最近工作的所遇到的问题结合其中的康威定律写一下自己的构想和总结。

2 康威定律

Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. - Melvin Conway(1967)

即设计系统的组织，其产生的设计等同于组织之内、组织之间的沟通结构。这就是康威定律。

从我所处的工作环境看，这里的系统指我们常说的软件系统或一个软件产品，即我们设计的软件系统是与组织形式是一致的，是强相关的。

康威定律的一些核心观点：

1. 组织沟通方式会通过系统设计表达出来：即组织沟通方式决定系统设计，《人月神话》给出了很简洁的答案： 沟通成本 = n(n-1)/2，沟通成本随着项目或者组织的人员增加呈指数级增长，即项目管理算法的复杂度是 O(n^2)。对于复杂的系统，设计离不开人与人的沟通，解决好人与人的沟通问题，才能有一个好的系统设计。沟通的问题，会带来系统设计的问题，进而影响整个系统的开发效率和最终产品结果。
2. 时间再多一件事情也不可能做的完美，但总有时间做完一件事情：一口气吃不成胖子，先搞定能搞定的。外部需求很多，总是有各种各样的需求进来，软件系统也越来越负载，这时候我们需要抓住主线，搞定关键的需求，达到客户的基本要求，然后再持续迭代版本(敏捷开发)。
3. 线型系统和线型组织架构间有潜在的异质同态特性：比如你想要什么样的系统，就搭建什么样的团队，定义好系统的边界和接口，在一个团队内全栈，让团队自治，原因就是因为如果团队按照这样的方式组建，将沟通的成本维持在系统内部，每个子系统就会更加内聚，彼此的依赖耦合能变弱，跨系统的沟通成本也就能降低。它是第一定律的应用。
4. 大的系统组织总是比小系统更倾向于分解：如一个大的组织因为沟通成本/管理问题，总被拆分成一个个小团队，部门老大管理几个经理，经理又管理几个程序员之类的，最后其实还是回到组织沟通与系统设计上来，比如每个经理都负责软件开发上的不同模块等或者其他分工。

3 康威定律在实践中的一点思考

3.1 一个现有的产品开发组织架构

这里示例一个现有的产品开发组织架构，然后描述在实际开展工作过程中出现的一些问题，最后我们来分析下它有何不妥。

• 这是一个对接 To B业务的部门，但是开发的产品最终是用于终端智能设备，可以间接地说这是做一个 To C的产品
• 产品有商务、有销售(售前)、有项目经理、有产品经理、有产品研发、有基础研发、有测试

列出以核心产品开发交付为中心的组织架构：

定制化开发团队主要做的事情是针对不同的To B客户做定制化开发，包括Demo开发、核心产品的集成，包括核心产品在客户环境下的测试等。

基础研究+核心产品开发团队是另一个团队，主要做产品相关的基础研究和核心产品开发，即定制化开发团队是依赖该团队的。

测试测试的主要工作是测试，主要为功能测试，性能测试暂不明确。它服务于两个团队。

这里的结构在不考虑实际的产品和对接业务的用户情况下，看起来是很较为合理的，有专注于核心产品开发的团队，也有对外的定制化开发团队，可以针对不同用户做不同的开发，实际上怎么样，下面章节我细细地结合实际情况进行分析它的合理性。

3.2 现有组织架构内外环境及引发的问题

3.2.1 内外环境分析

大的环境：

• 这是一个大的创业公司，大部分员工具有饱满的工作热情
• 这是一个想做好产品，但是以基础研究为核心的公司
• 这是一个跨部门产品， 基础研究+核心产品开发团队提供基础研究和核心产品支持， 定制化开发团队主要负责负责客户的定制化开发和集成
• 其他环境，包括部门与部门之间的目标一致性因素等

外部环境：

• To B用户较多，核心需求一致，但是核心需求无法满足更多的要求
• To B用户的需求存在很多一致性，即可以将外部需求提升到核心产品功能中
• To B用户可能存在Demo或解决方案复用的情况
• To B用户关注性能和集成复杂度以及安全性
• To B用户可能会越来越多，而 定制化开发团队支持人员不会增长

内部环境：

• To B用户是 定制化团队以分配开发人员资源跟进，因为均是依赖核心产品，存在资源重复对接情况
• 定制化团队严重依赖 基础研究+核心产品开发团队，而 基础研究+核心产品开发团队无法即使响应客户需求或无法理解客户需求
• 基础研究+核心产品开发团队和 定制化团队没有完备的需求导入渠道和需求审核渠道，需求导入变现缓慢，产品力提升单纯依赖“上游”输出
• 产品是适用于软硬件结合的应用环境， 基础研究+核心产品开发团队的基础研究测试和研发依赖硬件，在技术领域上无法快速开发和响应
• 内部两大团队人员较为分散，很难面对面沟通

3.2.2 引发的问题

综上节环境因素分析，带来的问题就有：

• 核心产品的竞争力会持续下降，最终失去市场优势
• 部门内部资源没有最优化使用
• 定制化团队的作用严重受限，而 定制化团队又处于与客户打交道，整个对接“管道”是一头大一头小，最终是“半阻塞”着的
• 定制化团队与 基础研究+核心产品开发团队沟通较为困难，外部需求很难变为内部“产品”标准功能，或很难根据客户需求，软件产品迭代链太长
• 组织架构和软件产品框架无法很好的协调，违反了康威第一、第三、第四定律

3.3 如何解决现有组织架构问题？

首先我们解决问题需要达到几个目标：

• 提高产品持续竞争力：构建一个部门核心竞争力产品，将“上游“变“下游“。产品跟进市场需求，支持新特性和新的解决方案，以部门为主导，推进基础研究，形成闭环，提高产品持续竞争力。
• 明确分工，结合现有项目情况和软件框架，优化组织，调配资源：可分为 项目支持 & 产品开发 & 基础研发 & 测试，分工明确，流程明确，需求反馈，形成闭环，提高效率，优化人力资源，持续迭代和优化产品，提高部门与跨部门效率
• 优化项目支持和产品资源结构：优化项目和产品资源结构，整合项目软件资源和需求，重构适配当前领域的软件框架，减少客户集成难度，提高项目交付效率和满意度。支持项目定制化模板，项目支持人员可根据产品模板实现自定义插件化开发，最终实现软件产品稳定功能。
• 客户需求与基础研发迭代机制建立：客户现有项目软件需求和支持信息与开发共享，包括问题列表、解决方案、需求列表等， 产品开发与基础研发共享，增加对外对内效率，避免不必要的沟通和资源浪费。同步建立需求审核和预研机制，统一客户、产品开发、基础研究战线。

最终，组织架构与软件框架有效的结合在一起，沟通成本和迭代速度以及资源利用率都会上来，而且需求走上了正轨，减少了团队之间的不理解，重点是整个软件产品的核心竞争力可以得到持续保障，从而不失去市场优势。重新得到组织架构图：

4 总结

创业早期，组织结构小巧的时候，团队是最为灵活的，可以根据外部情况及时做出调整，且对团队的影响也很小，当团队大了，业务大了，这时候我们要根据具体业务和软件产品做出一致性的调整，以达到最优化。根据我所经历过的，康威定律被人推崇确实是有道理的，定律来自实践，结合具体情况，合理的制定组织形式和软件系统，可以让资源优化、效率提升，虽然我结合康威定律对现有组织形式和软件系统的重新思考没有真正去实践过，但经过分析和定律指导，这确实是一个很好的解决方案。

声明：本文纯属个人对康威定律结合实践的构想，跟本人所处任何组织无关。

5 参考资料

• en.wikipedia.org/wiki/Conway%27s_law
• medium.com/@Alibaba_Cloud/conways-law-a-theoretical-basis-for-the-microservice-architecture-c666f7fcc66a
• baike.baidu.com/item/%E4%B8%96%E7%95%8C%E4%B8%8A%E6%9C%80%E7%A5%9E%E5%A5%87%E7%9A%8430%E4%B8%AA%E7%BB%8F%E5%85%B8%E5%AE%9A%E5%BE%8B/7122448
• github.com/dwmkerr/hacker-laws
• 《人月神话》
• wiki.mbalib.com/wiki/%E6%A0%BC%E6%8B%89%E4%B8%98%E7%BA%B3%E6%96%AF%E7%9A%84%E4%B8%8A%E4%B8%8B%E7%BA%A7%E5%85%B3%E7%B3%BB%E7%90%86%E8%AE%BA