别堆轮子了：从0到1的技术中台构建踩坑实录
去年秋天在南京跟做零售技术的老陈喝酒，他吐了一肚子苦水。公司老板听了行业分享，一拍脑袋要做技术中台，拉了三十个人的团队砸了两千万，干了一整年。上线那天老板剪了彩，结果业务部门该怎么重复开发还是怎么开发，出了问题全往中台甩锅。
好好的事做成了烂尾工程，说出去谁不心疼。
企业技术中台分层架构落地示意图
很多团队上来就走错路，什么都想抽，什么都想放进中台，最后做成了谁都不敢碰的摆设。还有人觉得中台就是技术部门自己的事，跟业务部门没关系，闭门造车做出来的能力，根本不符合业务的真实需求，扔在那边落灰。
技术中台重复造轮子问题对比图
说实话，正确的打开方式恰恰相反，从小切口切入，先解决最痛的那个问题。比如你发现公司三个业务线都在投入人力做用户标签，每个线都花了不少钱，那你就先把用户标签能力抽出来做成中台，跑通验证价值，拿到业务部门的信任，再慢慢扩展其他能力，这不香吗？罗马不是一天建成的，中台也一样。
落地要攥紧的几个核心原则
搞中台，跟盖房子不一样，盖房子先画图纸再动工，中台得从业务里长出来，不能凭空造。
第一个，要用产品化思维做中台，不是简单抽代码。什么叫产品化？你的中台能力要有清晰的文档，有独立的测试环境，有版本管理，有完整的监控告警，业务开发不用找中台团队问东问西，自己看文档就能对接测试上线，这才叫合格的中台能力。要是中台做出来，业务对接还要天天拉中台开发开会改bug，那还不如各个业务自己写呢。
第二个，记住中台提供能力，业务负责自治。中台不要把手伸到业务逻辑里，别去管业务怎么用我的能力，你把标准能力做好就够了。反过来，业务也不能要求中台给你做定制化开发，你有特殊需求，自己在业务层基于中台能力扩展，别麻烦中台。边界清晰，才不会乱成一锅粥。
第三个，接受中台是持续演进的，别想着一劳永逸。业务在变，公司的规模在变，需求肯定也会变，中台不可能做完就扔在那不动。但是迭代有个底线，就是一定要保持向下兼容，不能你中台一更版本，老业务就跑不起来，那谁还敢用你的能力？
不过话说回来，技术中台也不是什么银弹，不是所有公司都适合搞。小公司，业务还没稳定，就一两支开发团队，连三个重复的业务场景都找不到，凑什么热闹搞中台？先把业务跑顺，活下去比什么都重要。大厂搞中台是因为人家几十上百条业务线，重复问题堆成山，不得不搞，你小公司跟风，纯粹是浪费钱。
我见过最舒服的中台项目，就是从一个痛点长出来的：一开始就是支付部门发现四个业务线各做一套支付对接，重复改bug重复对接，太痛苦了，几个人抽了半年，把支付能力做成了中台，新业务对接从两周变成两天，省了十几个开发的人力，所有人都拿到了好处，后面再扩其他能力，业务部门都愿意配合，慢慢就做起来了。
搞技术中台，哪有什么高大上的黑科技，说白了就是解决真问题，给业务真提效，别搞花架子，别为了中台而中台。能做到这一点，你的技术中台构建就已经赢了。
很多人从一开始就理解错了技术中台
说白了，技术中台不是老板们用来凑数字化转型KPI的噱头，也不是程序员堆公共代码的垃圾场。我刚接触中台那会，也以为就是把各个业务线重复的代码抽出来，塞到一个公共仓库里就算完事。结果呢？抽完变成了一个几百M的大巨石项目，哪个业务改代码都怕碰着别人的模块，线上出了故障，全组人一起停下手头活定位中台问题，反而比之前更慢了。 技术中台的本质，其实是把企业里重复出现的业务问题，提炼成可快速复用的能力，给前线业务做赋能。 举个最实在的例子，做零售的，线上商城要积分，线下门店收银要积分，会员营销活动也要积分，三个业务线各写一套积分规则、积分抵扣、积分过期逻辑，光这一块每个线就要投入两个人维护，每年重复投入几十万成本，出了bug还要各改各的。把这套通用能力抽出来做成中台，业务线接个接口就能用，省下来的人力投去做业务创新，这才是中台真真正正的价值。企业技术中台分层架构落地示意图
很多团队上来就走错路，什么都想抽，什么都想放进中台，最后做成了谁都不敢碰的摆设。还有人觉得中台就是技术部门自己的事，跟业务部门没关系，闭门造车做出来的能力，根本不符合业务的真实需求，扔在那边落灰。
技术中台构建的核心坑，绝大多数团队都踩过
说实话，我见过的成功落地的中台不多，一半以上都死在坑里了。说几个最常见的，你品品。 第一个坑，什么都想复用，抽得太细太泛。我见过最离谱的团队，连日期格式化、字符串拼接这种工具函数都要放进中台，业务线改个格式还要中台走发版流程，等个两三天，业务的上线窗口期都过了，这不纯纯添乱吗？能进中台的，一定是多个业务线都在用的通用业务能力，不是什么阿猫阿狗都往里面塞。 第二个坑，权责不清，中台变成了万能背锅侠。业务说中台能力不好用，中台说业务需求变来变去我跟不上，最后变成两个部门互相甩锅，谁都不落好。这个问题本质就是没划清边界。中台只做通用能力的抽象和维护，不做任何业务定制逻辑。还是拿积分举例，中台给你开放规则配置接口，你要做双十一专属的积分翻倍活动，自己在业务层配置就完了，没必要让中台给你改代码。把这个红线卡死，90%的甩锅问题都能解决。 第三个坑，上来就追求大而全，搞宏伟蓝图。很多公司做中台，先做三年规划，要覆盖所有业务所有场景，结果干了一年多，还没出一个能用的能力，业务部门早就失去耐心了，领导也看不到价值，直接砍预算，项目就黄了。技术中台重复造轮子问题对比图
说实话，正确的打开方式恰恰相反，从小切口切入，先解决最痛的那个问题。比如你发现公司三个业务线都在投入人力做用户标签，每个线都花了不少钱，那你就先把用户标签能力抽出来做成中台，跑通验证价值，拿到业务部门的信任，再慢慢扩展其他能力，这不香吗？罗马不是一天建成的，中台也一样。
落地要攥紧的几个核心原则
落地要攥紧的几个核心原则
搞中台，跟盖房子不一样，盖房子先画图纸再动工，中台得从业务里长出来，不能凭空造。
第一个，要用产品化思维做中台，不是简单抽代码。什么叫产品化？你的中台能力要有清晰的文档，有独立的测试环境，有版本管理，有完整的监控告警，业务开发不用找中台团队问东问西，自己看文档就能对接测试上线，这才叫合格的中台能力。要是中台做出来，业务对接还要天天拉中台开发开会改bug，那还不如各个业务自己写呢。
第二个，记住中台提供能力，业务负责自治。中台不要把手伸到业务逻辑里，别去管业务怎么用我的能力，你把标准能力做好就够了。反过来，业务也不能要求中台给你做定制化开发，你有特殊需求，自己在业务层基于中台能力扩展，别麻烦中台。边界清晰，才不会乱成一锅粥。
第三个，接受中台是持续演进的，别想着一劳永逸。业务在变，公司的规模在变，需求肯定也会变，中台不可能做完就扔在那不动。但是迭代有个底线，就是一定要保持向下兼容，不能你中台一更版本，老业务就跑不起来，那谁还敢用你的能力？
不过话说回来，技术中台也不是什么银弹，不是所有公司都适合搞。小公司，业务还没稳定，就一两支开发团队，连三个重复的业务场景都找不到，凑什么热闹搞中台？先把业务跑顺，活下去比什么都重要。大厂搞中台是因为人家几十上百条业务线，重复问题堆成山，不得不搞，你小公司跟风，纯粹是浪费钱。
我见过最舒服的中台项目，就是从一个痛点长出来的：一开始就是支付部门发现四个业务线各做一套支付对接，重复改bug重复对接，太痛苦了，几个人抽了半年，把支付能力做成了中台，新业务对接从两周变成两天，省了十几个开发的人力，所有人都拿到了好处，后面再扩其他能力，业务部门都愿意配合，慢慢就做起来了。
搞技术中台，哪有什么高大上的黑科技，说白了就是解决真问题，给业务真提效，别搞花架子，别为了中台而中台。能做到这一点，你的技术中台构建就已经赢了。