中台的故事与事故_AI阅读总结 — 包阅AI

👉目录

1 Supercell 的奇迹

2 中台的本质：零成本复用

3复用背后的隐患

4 一些想法

5 写在最后

2015年左右底，“中台”这个词 迅速在互联网走红，众多互联网大厂纷纷投入到“中台”的战略布局中，转眼间，到了2024年，曾经风靡一时的中台迎来了退潮时刻。这期间发生过什么有趣的故事，这背后的原因又是什么？本文将阐述我对于中台建设的一些思考和浅见，希望可以引发技术人的思考。

本文作者将在下周三晚做客腾讯云开发者视频号「鹅厂程序员面对面」直播间，分享中台、建模、领域驱动等干货内容，提前预约抢占前排座位！

2015年，Supercell 公司旗下的《部落冲突》、《海岛奇兵》等众多爆款游戏迅速走红，Supercell 的年净利润高达15亿美元，但员工总数不到200人，其中每个工作室以 Cell 为单位，数量控制在7人左右。问题来了：为什么 Supercell 的小型团队能够在短时间内成功开发出热门游戏？在深度考察后，Supercell 背后成功的原因可以归功于以下几点：

• 公司开始之初 CEO 制定了:所有游戏开发的底层能力 从始到终 必须复用公共基础平台。在项目中，想必大家都遇到过半道被迫迁移公共组件，对于迁移者的实施者来讲，不光是要求组件更加好用，更需要的是说升级组件的收益要远远大于迁移的成本，这样对于使用者来说，才会有动力去迁移，也就是如下等式模型，很显然，我们想让实际价值越大，一方面增量价值要足够出色，另一方面要使得迁移成本越小越好，取极限就是0！不迁移！也就是这家公司起初的战略。

• 小团队的优势，所有开发团队的人数需要控制在5到9人左右，团队的沟通效率和执行力都达到了极致。（推荐阅读美国认知心理学家乔治.A.米勒的文章《神奇数字7±2 :信息加工能力的极限》和我的另一篇文章，其中讲到了沟通复杂度和 team 人数的关系《99%的程序员容易忽视的“系统”健康问题》）。

• 快速试错，小步快跑是关键，任何事情永远不可能一步就做到完美，但是一定可以在一个时间内做完，有的时候先做比先想重要的多，就算起步比较低，但只要一次比一次好，最后也是一个好的结果。Supercell 公司开发完成的游戏会快速投入全球市场进行快速验证，再基于反馈数据进行快速迭代，反复多次迭代，最后推向全球市场，获得成功。下图为小步快跑模型，试想：如果一个项目的周期动则半年、一年，那就需要认真评估是否可以活过“生存点”。

Supercell 的成功，背后都指向了一个原因：中台战略，随后中台战略在互联网迅速蔓延起来，XX 中台如雨后春笋，迅速在互联网开花结果。

想象一下，现在你就是特斯拉上海超级工厂的总裁，即将面临新年里将产能提升10倍的挑战。你会怎么做？可能是扩充规模、引入自动化机器人、优化生产流程…，但无论怎样优化，制造所用的原材料是少不了的。

换一个场景，假设你是一名开发人员，现在需要一个线程安全的 map 来存储数据。在这种情况下，我相信没有人会从头开始 Coding，而是选择现有的库。这种模式下，开发所用的原材料就是零。

对比这两种场景，你就不难发现软件行业相对于其他行业的巨大优势：高复用性，中台战略可以在一个时期中发挥出巨大的价值，正是充分利用好了这个特点，高复用有带来了人力成本的加少，用更少的钱做更多的事，谁听了都连连叫好。

透过复用性，在看 Supercell，一切都明朗了。旗下的游戏服务架构中，底层模块高度统一、复用性极高，如支付网关、算法模型、游戏引擎、存储引擎等，底层模块高复用能力使得新游戏的开发，更像是换皮不换骨，在极短时间内就可以复制出爆款游戏。

如下图所示，可以清晰的看出两种模式的异同，大中台模式一句话总结就是：在变化的业务中，找到不变的元素，投入一次成本，服务众多业务。

中国人最有智慧的地方就是教你，事物总有两面性，你说到好，就要下意识想一下，哪里不好，正所谓：一阴一阳之谓道。

到了2020年，慢慢中台的声音没有之前那么大了，或者说好像被遗忘了，背后的原因是什么呢？我先抛出自己的答案：中台阻碍了业务了发展，活不下去了，这里阻碍有两层意思：

1. 中台会“反抗”业务的需求，因为中台往往是一个大的部门，不隶属任何业务，不对某个业务的结果负责，业务部门和中台部门的目标很有可能是不一致的。

2. 中台的响应速度太慢了，等你搞好了，业务都没了，你还谈什么价值呢？下面我们具体谈谈这两个问题。

康威定律揭示了：技术架构和组织架构之间的强相关性，当一个组织越大越大，组织架构的划分往往会影响技术架构的划分，一个大的业务往往需要不同部门通力合作，每个团队的目标也不尽相同，以下是一个团队-目标模型图。

上图中，业务和中台都属于不同的组织，因为存在复用关系，理论上就会出现目标不一致的情况，解决跨团队目标的一致性，往往就不是一个技术问题了，也非一人之力可以完成。

更有意思的问题是，在这种架构下，中台会有很强的边界感，系统之间其实会存在所谓的“模糊地带”，中台带来的好处，往往会被对接、定制的内耗抵消，甚至击穿。

在中台的模式下，中台往往不是直接和业务接触的，从市场到业务再到中台往往需要很多时间，也就是中台感知市场的能力具有延迟性，这是一个恐怖的事，如下图所示。

业务同学有的时候会打趣道：“有给你说的功夫，我自己都做完了”，但是自己做，是不是又要在造新轮子呢（轮子问题，不做发散）。

仔细想想上面举的例子：如果想用一个现成安全的 map，只需要“拿来主义”就好，那为什中台直接拿来用就有问题呢？本质的原因是因为对接的代价不一样，对于使用一个库函数，我只需要引入稳定的包，搞清楚出参和入参就 OK 了，这个工作量是可以忽略不计的，但是对于中台，本质上需要做前置大量沟通对接，而且在后续运营的过程中，还存在这强依赖的问题，这使得看似复用实则不复用，这背后隐含着大量的额外工作，这个工作量有的时候甚至大于自己动手。

我总感觉做中台和开超市本质是同一件事，假象你现在就是超市经理，遇到如下场景，你会怎么办呢？：

• 有一个客户想进一批100斤重的大闸蟹，但是你们超市没有售卖，客户期望新增此产品，但由于当地海域品种限制，需要从国外引进，并且成本很高，是否需要引进呢？

• 如果决定提供新品种，但是需要前期调研、选品等乱七八糟时间加起来需要半年，这个前置时间，客户是否可接受，半年后客户还在吗？

• 如果超市决定不提供新品种，客户转而去了别的超市，是否流失了一个客户？

仔细想想这些问题，和中台遇到的问题如出一辙，不难看出，这里的本质问题是：到底是业务围绕着中台发展，还是中台围绕着业务发展？

如果是业务围绕着中台，那很简单，中台提供什么能力，说清楚，让业务去选择。中台同学自己决定 做什么能力、何时去做、做多久。但是正如上面说的，因为中台并不出现在一线，很难及时感知到市场的变化和趋势，迭代具有延迟性，有的时候，等你迭代完了，业务也死了，这个锅谁来背呢？

如果是中台围绕着业务发展，这个关系就从 “中台提供能力 变成了 中台接受需求” 业务同学会把一些定制化需求抛给中台，这好像又违背了中台围绕复用能力建设的初衷，如果有100个业务同时提需求，中台可以抗的住吗，本质做 ToC 的中台慢慢会变成一个 ToB 的中台。

关于这个问题，相信每个人都有自己的想法，我谈谈我的两点看法：

1. 中餐馆没有日料，中台需要明确自己的定位和边界，如果一个客户来中餐馆点日料，那会感觉很奇怪，但是老板发现，日料的受众也很大，那提供可不可以呢，完全可以，为什么呢，要赚钱嘛！

2. 高级营销，靠吸引，也就是不存在单方面的选择，中台拿的出好用的产品，业务自然会去用，但是如果强制业务一定要用，那最后就会出现拧巴的事。

唯一不变的是变化，面对市场的变化，技术架构应该如何快速的应对，有几点想法可以谈谈：

如果你也有和中台有关的故事或者感想，欢迎留言，一起讨论。

你有哪些和中台有关的故事或者感想？欢迎评论分享。我们将选取1则评论，送出腾讯云开发者定制眼罩1个（见下图）。7月31日中午12点开奖。

📢📢欢迎加入腾讯云开发者社群，享前沿资讯、大咖干货，找兴趣搭子，交同城好友，更有鹅厂招聘机会、限量周边好礼等你来~

（长按图片立即扫码）