技术中台构建：别把花架子做成企业包袱
去年跟一个创业公司的CTO吃饭，他喝了三杯啤酒就开始骂街。
花了一百八十万做技术中台，搞了一年多，现在锁在服务器里吃灰。
业务部门没人用。说改个需求比原来还慢一倍。
这不是个例。我见过太多企业，跟风搞中台，最后做成了面子工程。
企业技术中台业务痛点梳理流程图
说白了，他们搞中台的顺序就反了。
大厂搞中台是什么逻辑？字节跳动早期扩张快，今天做个抖音，明天做个头条，后天整个西瓜视频，每个产品都要做内容分发、做推荐算法、做用户账户体系，重复开发一遍太浪费人力，效率太低，所以才把这些通用的能力抽出来，做成中台给各个业务线用。
先有多个业务的重复痛点，再抽中台。不是先建个中台，再等着业务来用。
很多企业倒过来，业务还没几个呢，先砸钱建中台，这不就是等着烂尾么？
技术中台构建常见踩坑点对照表
那个之前跟我吐槽的创业公司CTO，就是栽在这个坑里。大厂出来的，总觉得要做跟大厂一样的架构，上来就画了个几十页的架构图，融的A轮钱花了三分之一，结果产品上线拖了半年，投资人都找上门要撤资，现在还在填坑。
他说那阵子天天睡不着，早知道不搞这个花架子了，先把产品跑起来再说。
中小团队做技术中台，其实可以从最小可行单元开始
很多人觉得中台是大厂玩的东西，中小厂碰都碰不得。其实不对，找对方法，几十人的团队也能搞出好用的中台。
核心就是，别搞大而全，从最小可用开始。
你现在有三个业务线，每个都要做短信验证、支付对账，还有用户登录，这三块每个业务都要写一遍，重复劳动还容易出bug，那你就先把这三块抽出来，做成一个简单的中台服务，能调用，不出错就行。不用考虑未来要支持一百个业务，不用做什么花里胡哨的配置面板。
我见过最快的，一个二十多个人的电商团队，两个开发两周就抽完了，之后每个新的分销业务线上线，速度直接快了三分之一，这就够了。
说实话，技术中台就是个效率工具。不是给老板看的政绩工程。你帮业务少写一万行重复代码，少出十个线上bug，加快了上线速度，那就是合格的好中台。你搞出来个大而全的东西，没人用，那就是占服务器资源的垃圾。
不过话说回来，也不是所有企业都需要中台。你要是就一个业务线，从头到尾就一个团队开发，那根本没必要折腾什么中台，把代码写清楚，模块化做好就足够了。
别听那些卖方案的瞎忽悠，说什么不上中台企业就没竞争力，都是骗你钱的。
适合自己的，才是对的。你说对吧？
别从技术出发搞技术中台，要从业务痛点切入
很多架构师一上来就说，我们要把所有通用能力抽出来，我们要做高可用可扩展，我们要对齐大厂架构。 听着挺牛，落地全错。 技术中台不是为了技术而技术，是为了解决业务重复造轮子的痛点才存在的。 我前阵子帮一家区域连锁零售企业梳理技术架构，一进门业务总监就拉着我吐槽，去年外包做的中台，把用户信息抽出来做了个统一用户中心，听起来高大上对不对？结果线下跑了十年的收银系统改不动，新上的社区团购小程序要用户数据，中台接不到老系统，老系统出不来数据，卡在中间半年，新业务差点黄了。企业技术中台业务痛点梳理流程图
说白了，他们搞中台的顺序就反了。
大厂搞中台是什么逻辑？字节跳动早期扩张快，今天做个抖音，明天做个头条，后天整个西瓜视频，每个产品都要做内容分发、做推荐算法、做用户账户体系，重复开发一遍太浪费人力，效率太低，所以才把这些通用的能力抽出来，做成中台给各个业务线用。
先有多个业务的重复痛点，再抽中台。不是先建个中台，再等着业务来用。
很多企业倒过来，业务还没几个呢，先砸钱建中台，这不就是等着烂尾么？
技术中台构建的三个核心踩坑点，全是踩出来的血泪
我见过的烂尾中台，十个里有九个栽在这三个坑里。 第一个坑，对复用率的执念。 不管什么需求，都要塞进中台实现复用，仿佛不复用就是技术不合格。结果中台越做越重，什么乱七八糟的定制逻辑都堆进去，后来改一个小功能，要测试大半个中台，上线速度比业务自己做还慢。 我就见过一个团队，为了让一个只用一次的活动需求复用，硬生生把中台改了两个月，活动都结束了才上线。搞笑不？ 第二个坑，中台和业务线权责不清。 中台说我只做通用能力，你的定制需求自己解决。业务线说你中台做的能力不满足我，我怎么做？两边踢皮球，一个需求拖一个月都是常事。 之前有个互联网公司，甚至闹出业务线自己偷偷搭了一套服务绕过中台的事，你说搞成这样，中台存在的意义是什么？ 第三个坑，过度设计提前布局。 一开始就想着我这个中台要支持一万个业务，要兼容未来十年的扩展，做了一堆根本用不上的配置和抽象，代码写得无比复杂，结果第一个业务上线，一半功能用不上，还天天出bug，开发团队天天给中台擦屁股，根本没时间做业务。技术中台构建常见踩坑点对照表
那个之前跟我吐槽的创业公司CTO，就是栽在这个坑里。大厂出来的，总觉得要做跟大厂一样的架构，上来就画了个几十页的架构图，融的A轮钱花了三分之一，结果产品上线拖了半年，投资人都找上门要撤资，现在还在填坑。
他说那阵子天天睡不着，早知道不搞这个花架子了，先把产品跑起来再说。
中小团队做技术中台，其实可以从最小可行单元开始
中小团队做技术中台，其实可以从最小可行单元开始
很多人觉得中台是大厂玩的东西，中小厂碰都碰不得。其实不对，找对方法，几十人的团队也能搞出好用的中台。
核心就是，别搞大而全，从最小可用开始。
你现在有三个业务线，每个都要做短信验证、支付对账，还有用户登录，这三块每个业务都要写一遍，重复劳动还容易出bug，那你就先把这三块抽出来，做成一个简单的中台服务，能调用，不出错就行。不用考虑未来要支持一百个业务，不用做什么花里胡哨的配置面板。
我见过最快的，一个二十多个人的电商团队，两个开发两周就抽完了，之后每个新的分销业务线上线，速度直接快了三分之一，这就够了。
说实话，技术中台就是个效率工具。不是给老板看的政绩工程。你帮业务少写一万行重复代码，少出十个线上bug，加快了上线速度，那就是合格的好中台。你搞出来个大而全的东西，没人用，那就是占服务器资源的垃圾。
不过话说回来，也不是所有企业都需要中台。你要是就一个业务线，从头到尾就一个团队开发，那根本没必要折腾什么中台，把代码写清楚，模块化做好就足够了。
别听那些卖方案的瞎忽悠，说什么不上中台企业就没竞争力，都是骗你钱的。
适合自己的，才是对的。你说对吧？