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

简介: 神奇的康威定律-组织决定产品形态

这是我的第56篇原创

互联网有基因论--阿里有交易基因,所以来往、淘江湖会失败;腾讯是即时通讯基因,所以拍拍等交易业务全部扑街。稍微有些独立思考能力的同学都会嗤之一笑,这算啥乱七八糟的理由?等等,你别忙着否定,这还真有一定的道理。这就是“康威定律”,这是康威在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学习,回来就把中台吸纳、提升为中台概念。


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

腾讯的组织架构就比较散,以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
大的系统组织总是比小系统更倾向于分解

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

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

中台架构又开始合并。所谓分久必合,合久必分。我在《一口气说透中台--给你架构师的视角》一文里详细讲述了架构的演进过程,感兴趣可以点开看看。

相关文章
|
6月前
|
敏捷开发 监控 测试技术
软件架构的艺术:探索演化之路上的18大黄金原则
实际工作表明,一步到位的设计往往不切实际,而演化原则指导我们逐步优化架构,以灵活响应业务和技术的变化。这不仅降低了技术债务和重构风险,还确保了软件的稳定性和可扩展性。同时,架构的持续演进促进了团队协作,激发了成员间的知识共享与技能提升。
135 0
软件架构的艺术:探索演化之路上的18大黄金原则
|
6月前
|
搜索推荐 程序员 测试技术
研究思考|关于软件复杂度的困局
本文重点围绕软件复杂度进行剖析,希望能够帮助读者对软件复杂度成因和度量方式有所了解。
|
搜索推荐 程序员 测试技术
研究思考丨关于软件复杂度的困局
研究思考丨关于软件复杂度的困局
1301 9
研究思考丨关于软件复杂度的困局
|
存储 NoSQL BI
【企业架构】描绘未来:使用能力、产品和技术路线图来调整企业和执行战略
【企业架构】描绘未来:使用能力、产品和技术路线图来调整企业和执行战略
|
运维 Kubernetes 供应链
【老猿说架构】那些因素决定架构活动的成败
【老猿说架构】那些因素决定架构活动的成败
230 0
【老猿说架构】那些因素决定架构活动的成败
|
存储 监控 安全
【组装式架构设计】“有机”架构思维的探寻-交付那些事
软件架构本身是一个宏大的概念或命题,但历经过往种种,开始有些思考在脑海中,挥之不去,在此整理出来,和大家一道探寻,这是一篇关于“类比”的探寻。
573 0
【组装式架构设计】“有机”架构思维的探寻-交付那些事
|
运维 架构师 测试技术
从架构理解价值-我的软件世界观(转载)
程序员的迷茫-找寻不到价值 在浩大的软件世界里,作为一名普通程序员,显得十分渺小,甚至会感到迷茫。我们内心崇拜技术,却也对日新月异的技术抱有深深的恐惧。技术市场就像这喜怒不定的老天爷,今天下个大数据雨,明天挂个人工智能风,面对琳琅满目的技术浪潮的冲击,程序员难免深感无力,深怕错过了技术潮流从而失去了职场竞争力。
1242 0
|
数据可视化 测试技术
好的设计准则是如何塑造更强大的产品形态的
本文讲的是好的设计准则是如何塑造更强大的产品形态的,我的工作是为房地产专业人士设计/改善一个旧的 CRM 系统。我们常常会碰到设计的瓶颈,因为我们没有任何设计原则可做参考。我们的用户有着自己对产品喜好的标准。
1312 0