神奇的康威定律——组织决定产品形态

编辑导读：互联网圈有这么一句话：百度的技术，阿里的运营，**的产品。为什么这么讲？这其中有什么**支持吗？文章从阿里**的案例出发，对康威定律进行了详细分析说明，与大家分享。

互联网有基因论–阿里有交易基因，所以来往、淘江湖**失败；**是即时通讯基因，所以拍拍等交易业务全部扑街。

稍微有些独立思考能力的同学都**嗤之一笑，这算啥乱七八糟的理由？

等等，你别忙着否定，这还真有一定的道理。这就是“康威定律”，这是康威在1967年在论文里提出来的，后来被软件开发神书《人月神话》引用并总结成四条定律。

康威第一定律

Conway’s law: Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.

– Melvin Conway(1967)

组织设计的产品/设计等价于这个组织的沟通结构。

用人话来说，就是你组织是啥德行，产品就是啥德行。从这个角度上来说，阿里做来往就扑街，做钉钉就成功，好像还蛮有道理的哦。

阿里的组织架构和沟通机制就非常职业化和政治化，你在钉钉上截图，**带上你自己的名字和手机号码，这与阿里员工截屏**打水印是一样一样的。

阿里的产品架构都非常严谨，中规中矩，先顶层设计，后逐步细化。阿里善于学习、总结、提炼，所以阿里去SuperCell学习，回来就把中台吸纳、提升为中台概念。

**的组织架构和沟通机制就很有意思，小马哥天天在内网跟一帮人探讨产品，据说邮件都是秒回。所以**、微信都很成功，但是企业微信就被无数人吐槽。

**的组织架构就比较散，以IEG事业群为例，下面有4大工作室，天美、北极光、魔方和光子。像盛极一时的王者荣耀，就是在这种松散的组织架构中被组装起来的其中一个案例。所以**把SuperCell收购了之后，依然是独立管理，继续做游戏。

有些公司的沟通机制是老板一言堂，这种产品就很有意思了，天马行空，随意的很。产品形态没有下限，甚至也没有上限，那真是，红旗招展，彩旗飘飘。程序员们也不是面向对象开发，而是面向老板开发。

对了，你可以拿康威定律套一下你自己的公司，看看这个定律在你公司是不是也一样生效。

康威第二定律

There is never enough time to do something right, but there is always enough time to do it over。

时间再多一件事情也不可能做的完美，但总有时间做完一件事情。

软件开发领域，永远不可能完美，所以建议我们先把事情做完。你看这是不是就是敏捷的思想？

• 文档可以不完美，拍张照**都行；
• 上线的功能可以不完美，能跑通就行；
• 代码可以不完美，有bug也没关系，咱持续迭代就行。

先把事情做了，再去逐步逼近完美。所以敏捷管理主张持续交付，快速迭代，及时反馈，立刻验证，持续优化。

康威第三定律

There is a homomorphism from the linear graph of a system to the linear graph of its design organization.

线型系统和线型组织架构间有潜在的异质同态特性。

异质同态指的是系统和组织虽然是两个东西，但是有相同的结构。所以系统是啥样，组织也就得变成那个样子。这个比较好理解，做过技术管理的人在设计组织架构的时候都**参照系统的架构来设置。

比如咱公司如果是单体架构，那就一个开发组就行了；但是如果是前后端分离，那么必然就**拆分为前端组和后端组，分别进行管理。这就是所谓的异质同态。如果系统和组织的结构不匹配，那么将**是灾难。你想象一下系统是前后端分离，但是压根就没拆分前后端的岗位是啥情况？

康威第四定律

The structures of large systems tend to disintegrate during development, qualitatively more so than with small systems。

大的系统组织总是比小系统更倾向于分解。

这句话非常有意思，系统架构的核心字诀就是“拆”和“合”。

从单体架构开始，分层架构、微服务架构、网络服务架构，都是在拆，拆的越来越小。

作者：大数据架构师，国药国华大数据总监，擅长BI、数仓、数据中台产品规划领域，公众号：大数据架构师

本文由 @大数据架构师 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于 CC0 协议