搞技术中台构建踩过3个坑后，我才明白它不是大公司的玩具

去年秋天在南京帮本地一家区域零售客户梳理技术架构，刚进门CTO就拉着我吐槽，说老板拍板要搞技术中台，搞了大半年，现在业务线骂，中台团队也骂，两边都不讨好。

什么情况呢？原来他们有三个业务线：线下超市、线上电商小程序、企业团购，每个业务线各有一套技术班子，用户数据散在三个库里，每次做个跨渠道的活动，光拉齐数据就要跑三个部门提需求，等个三四天，出来的数还对不上。老板一听，这不就是中台能解决的问题吗？马上招了一个中台团队，动工开搞。

结果呢？中台搭了大半年，业务线说用你的中台接口比我自己写还麻烦，改个小需求要排期一周，我赶活动上线，还是自己写了一套。中台团队喊冤，说我按规划做的通用能力，你们业务线天天要改定制需求，我哪忙得过来？

别上来就堆组件，技术中台是解决问题，不是为了凑概念

说实话，我见过太多公司一开始搞技术中台构建，上来先搭框架，找一堆开源组件，堆了十几个可复用模块，PPT做得花里胡哨，结果上线没人用。

为什么？搞错了出发点。

我给你打个最通俗的比方。你开三家汉堡店，每家都要自己腌牛肉、烤面包、做酱料，每天光备料就要花两个小时，人工贵，口味还不稳定。技术中台就是帮你把腌牛肉、烤面包这些活，统一放到一个中央厨房去做，每家店要货直接拿，回去加热夹菜就能卖，省时间还稳。

问题就出在，很多人把中央厨房做成了商场，要求所有店必须进我的货，不管你开在学校门口想卖学生爱吃的炸鸡，还是开在写字楼想卖减脂轻食，都必须卖我中央厨房做好的汉堡，这不找骂吗？

技术中台构建的出发点，从来不是为了让公司看起来有中台，而是哪里有重复造轮子，就把哪里的能力抽出来。你的公司如果只有一个业务，所有开发都是给这一个业务服务，那根本不需要搞什么中台。如果你有好几个业务线，都要自己做用户登录、都要自己做支付、都要自己做图片存储，每个团队都写一遍一模一样的逻辑，那这不就是浪费时间吗？抽出来，放中台，大家一起用，这不就完了？

技术中台构建的核心：抽能力，不收权力

刚才那个零售客户的问题，出在哪？中台团队一开始就把定位搞错了，觉得自己是管所有技术的，所有能力必须归我，所有接口必须走我，把自己做成了业务线的上游关卡，而不是给业务线打杂的服务方。

你想啊，业务线要赶项目上线，改个一行代码就能解决的小问题，找中台排期要等一周，换你你会不会自己偷偷写一个？肯定会啊。

真正舒服的中台架构，分层其实特别简单：底层是共用的基础设施，中间是中台抽出来的通用能力，上层是各个业务线自己的业务逻辑。中台只做通用的事，你要用户ID，我给你统一的，你要支付，我给你封装好接口，你业务要加什么特殊规则，自己在业务层改，我不卡你，我也不要求你必须用我的所有东西。

说白了，中台是给业务线提速的，不是来管业务线的。很多公司搞中台，最后搞成了部门权力斗争，中台要收权，业务线要放权，最后活没干成，内耗先搞起来了，太亏了。

绕不开的三个误区，我踩过你别碰

第一个坑，一定要一步做大做全。我见过不少公司，中台规划做了三个月，把未来三五年能用到的能力都列进去了，搞了一年多才上线，结果上线的时候业务都换方向了，原来规划的能力全没用，白忙活。

技术中台构建哪需要一步到位？业务现在需要用户中心，你就先抽用户中心，下个月需要支付能力，再抽支付，跟着业务痛点走，迭代着来，半年就能出能用的东西，比你憋一年出个没用的强一万倍。

第二个坑，技术越先进越好。非要上最新的技术栈，非要把服务拆得连原子都不如，结果呢？原来一个运维管十个服务，现在要管一百个，天天救火，开发改个需求要跨三个中台团队协调，效率反而比原来低了一半。

适合自己的才是对的，你整个技术团队才二十个人，搞几百个微服务，不是自己给自己找事吗？能解决问题，能让大家偷懒，就是好中台。

第三个坑，建好就不管了，一劳永逸。很多公司中台上线就扔那，也不收集业务线的反馈，也不更新能力，过了一年，业务变了，中台的能力跟不上，大家慢慢就不用了，又回到各干各的老样子。

你得把中台当一个产品做啊，你的用户就是各个业务线的开发，你要跟进他们的需求，改不好用的地方，加新的能力，持续运营，才能活下去。不然就是一个死中台，摆着看的。

最后说句实在话，很多人吹技术中台，说这是未来企业技术的标配，不搞就要落伍。我从来不这么看。

技术中台本来就是解决重复建设的问题，它不是万能药，解决不了你的业务增长问题，也解决不了你的团队管理问题。你要是没那么多重复造轮子的痛点，犯不着为了概念硬上，浪费钱又浪费人。你要是真的天天看着一堆人重复写一样的代码，那就从小处开始动手，抽第一个能力，用起来了再慢慢扩，比什么都强。

搞技术的，到最后还是看能不能解决问题，别的都是虚的。