中台的故事与事故
共 5614字，需浏览 12分钟
·
2024-07-24 08:45
👉目录
1 Supercell 的奇迹
2 中台的本质：零成本复用
3 复用背后的隐患
4 一些想法
5 写在最后
01
-
公司开始之初 CEO 制定了:所有游戏开发的底层能力 从始到终 必须复用公共基础平台。在项目中，想必大家都遇到过半道被迫迁移公共组件，对于迁移者的实施者来讲，不光是要求组件更加好用，更需要的是说升级组件的收益要远远大于迁移的成本，这样对于使用者来说，才会有动力去迁移，也就是如下等式模型，很显然，我们想让实际价值越大，一方面增量价值要足够出色，另一方面要使得迁移成本越小越好，取极限就是0！不迁移！也就是这家公司起初的战略。
小团队的优势，所有开发团队的人数需要控制在5到9人左右，团队的沟通效率和执行力都达到了极致。（推荐阅读美国认知心理学家乔治.A.米勒的文章《神奇数字7±2 :信息加工能力的极限》和我的另一篇文章，其中讲到了沟通复杂度和 team 人数的关系《99%的程序员容易忽视的“系统”健康问题》）。
快速试错，小步快跑是关键，任何事情永远不可能一步就做到完美，但是一定可以在一个时间内做完，有的时候先做比先想重要的多，就算起步比较低，但只要一次比一次好，最后也是一个好的结果。Supercell 公司开发完成的游戏会快速投入全球市场进行快速验证，再基于反馈数据进行快速迭代，反复多次迭代，最后推向全球市场，获得成功。下图为小步快跑模型，试想：如果一个项目的周期动则半年、一年，那就需要认真评估是否可以活过“生存点”。
Supercell 的成功，背后都指向了一个原因：中台战略，随后中台战略在互联网迅速蔓延起来，XX 中台如雨后春笋，迅速在互联网开花结果。
02
想象一下，现在你就是特斯拉上海超级工厂的总裁，即将面临新年里将产能提升10倍的挑战。你会怎么做？可能是扩充规模、引入自动化机器人、优化生产流程...，但无论怎样优化，制造所用的原材料是少不了的。
换一个场景，假设你是一名开发人员，现在需要一个线程安全的 map 来存储数据。在这种情况下，我相信没有人会从头开始 Coding，而是选择现有的库。这种模式下，开发所用的原材料就是零。
对比这两种场景，你就不难发现软件行业相对于其他行业的巨大优势：高复用性，中台战略可以在一个时期中发挥出巨大的价值，正是充分利用好了这个特点，高复用有带来了人力成本的加少，用更少的钱做更多的事，谁听了都连连叫好。
透过复用性，在看 Supercell，一切都明朗了。旗下的游戏服务架构中，底层模块高度统一、复用性极高，如支付网关、算法模型、游戏引擎、存储引擎等，底层模块高复用能力使得新游戏的开发，更像是换皮不换骨，在极短时间内就可以复制出爆款游戏。
如下图所示，可以清晰的看出两种模式的异同，大中台模式一句话总结就是：在变化的业务中，找到不变的元素，投入一次成本，服务众多业务。
03
中国人最有智慧的地方就是教你，事物总有两面性，你说到好，就要下意识想一下，哪里不好，正所谓：一阴一阳之谓道。
到了2020年，慢慢中台的声音没有之前那么大了，或者说好像被遗忘了，背后的原因是什么呢？我先抛出自己的答案：中台阻碍了业务了发展，活不下去了，这里阻碍有两层意思：
中台会“反抗”业务的需求，因为中台往往是一个大的部门，不隶属任何业务，不对某个业务的结果负责，业务部门和中台部门的目标很有可能是不一致的。
中台的响应速度太慢了，等你搞好了，业务都没了，你还谈什么价值呢？下面我们具体谈谈这两个问题。
康威定律揭示了：技术架构和组织架构之间的强相关性，当一个组织越大越大，组织架构的划分往往会影响技术架构的划分，一个大的业务往往需要不同部门通力合作，每个团队的目标也不尽相同，以下是一个团队-目标模型图。
上图中，业务和中台都属于不同的组织，因为存在复用关系，理论上就会出现目标不一致的情况，解决跨团队目标的一致性，往往就不是一个技术问题了，也非一人之力可以完成。
更有意思的问题是，在这种架构下，中台会有很强的边界感，系统之间其实会存在所谓的“模糊地带”，中台带来的好处，往往会被对接、定制的内耗抵消，甚至击穿。
在中台的模式下，中台往往不是直接和业务接触的，从市场到业务再到中台往往需要很多时间，也就是中台感知市场的能力具有延迟性，这是一个恐怖的事，如下图所示。
业务同学有的时候会打趣道：“有给你说的功夫，我自己都做完了”，但是自己做，是不是又要在造新轮子呢（轮子问题，不做发散）。
仔细想想上面举的例子：如果想用一个现成安全的 map，只需要“拿来主义”就好，那为什中台直接拿来用就有问题呢？本质的原因是因为对接的代价不一样，对于使用一个库函数，我只需要引入稳定的包，搞清楚出参和入参就 OK 了，这个工作量是可以忽略不计的，但是对于中台，本质上需要做前置大量沟通对接，而且在后续运营的过程中，还存在这强依赖的问题，这使得看似复用实则不复用，这背后隐含着大量的额外工作，这个工作量有的时候甚至大于自己动手。
04
我总感觉做中台和开超市本质是同一件事，假象你现在就是超市经理，遇到如下场景，你会怎么办呢？：
有一个客户想进一批100斤重的大闸蟹，但是你们超市没有售卖，客户期望新增此产品，但由于当地海域品种限制，需要从国外引进，并且成本很高，是否需要引进呢？
如果决定提供新品种，但是需要前期调研、选品等乱七八糟时间加起来需要半年，这个前置时间，客户是否可接受，半年后客户还在吗？
如果超市决定不提供新品种，客户转而去了别的超市，是否流失了一个客户？
仔细想想这些问题，和中台遇到的问题如出一辙，不难看出，这里的本质问题是：到底是业务围绕着中台发展，还是中台围绕着业务发展？
如果是业务围绕着中台，那很简单，中台提供什么能力，说清楚，让业务去选择。中台同学自己决定 做什么能力、何时去做、做多久。但是正如上面说的，因为中台并不出现在一线，很难及时感知到市场的变化和趋势，迭代具有延迟性，有的时候，等你迭代完了，业务也死了，这个锅谁来背呢？
如果是中台围绕着业务发展，这个关系就从 “中台提供能力 变成了 中台接受需求” 业务同学会把一些定制化需求抛给中台，这好像又违背了中台围绕复用能力建设的初衷，如果有100个业务同时提需求，中台可以抗的住吗，本质做 ToC 的中台慢慢会变成一个 ToB 的中台。
关于这个问题，相信每个人都有自己的想法，我谈谈我的两点看法：
中餐馆没有日料，中台需要明确自己的定位和边界，如果一个客户来中餐馆点日料，那会感觉很奇怪，但是老板发现，日料的受众也很大，那提供可不可以呢，完全可以，为什么呢，要赚钱嘛！
高级营销，靠吸引，也就是不存在单方面的选择，中台拿的出好用的产品，业务自然会去用，但是如果强制业务一定要用，那最后就会出现拧巴的事。
唯一不变的是变化，面对市场的变化，技术架构应该如何快速的应对，有几点想法可以谈谈：
中台建设更适用于有稳定基本盘的业务，稳定就意味着变化少，变化少，才更方便的去抽象出可复用的能力。
中台的建设需要有对业务领域有认知极强的专家团队，并且需要有极强的建模能力，以及可以找到业务的本质以及 get 到业务和技术的衔接点。
05
如果你也有和中台有关的故事或者感想，欢迎留言，一起讨论。
📢📢欢迎加入腾讯云开发者社群，享前沿资讯、大咖干货，找兴趣搭子，交同城好友，更有鹅厂招聘机会、限量周边好礼等你来~
（长按图片立即扫码）