最实用的中台入门介绍

文章插图
中台概念大家已经很熟悉了，各种定义满天飞，但是中台到底是什么，怎么做，还是需要做了才知道。我现在以实实在在的案例让大家明白中台。当然了，毕竟接触中台时间还是不够长，免不了出现一些有偏差的观点，有看到的中台大佬可以指出。
一、中台的定义和角色中台的定义可以从很多公开资料找到，我这里不再做赘述和解释。我在这里期望以更白话、真实的案例和个人经历的方式讲讲对中台的理解，讲讲中台是怎么落地实施的，怎么将一个业务需求转化成中台需求的，好让大家对中台有个非常具象的认知。
谈起角色就要有对象，中台对于前端业务来说，是业务后端。前台业务不是很关心你怎么实现，也不关心是中台实现还是业务系统自己实现，只关心你能否实现我想要的前端展示、交互、逻辑等等。
中台对于前端业务的后端系统来说，类似一个有强大能力的第三方服务商，这个第三方服务商有某个模块的各种接口和能力，我按照这个第三方规范的接口文档给信息，对方就能够实现我这边业务的这个模块想要的底层结果，不需要我针对这个模块再做一次开发。
所以，如果从业务角度看中台，他承担了一部分业务后端系统的角色，也承担了一个第三方服务商的角色。

文章插图
二、什么样的人适合做中台我们都知道，业务系统如果做的不合理可以等以后重构，也可以为了应付紧急需求而做很多阉割版功能，甚至可以让产品新人和技术新人操刀，只要实现业务需求就可以。
而对于中台来说，不管多小的中台，都需要有非常清晰的产品规划，产品要知道业务以后可能做什么，会怎么玩，落地下来就是业务某个功能点以后可能怎么做，我中台底层模型如何搭建，才能让中台的扩展性很强很灵活很好支持多变的业务。
中台的重构成本相比于业务侧，是翻倍的，越灵活重构成本越高，对接的业务侧越多，重构成本也越高。
那么问题来了，你如果不懂业务，能做中台的产品吗？
答案肯定是否定的。
所以做中台的人一定是对业务很了解的人，无论是产品还是研发，请记住懂业务是前提条件，不仅仅懂自己的业务，还要懂与自己相关的上下游业务。
由于中台的搭建往往是围绕一个需求考虑具体的产品实现方案和技术实现方案，所以中台产品最好还要对技术有一定的了解，了解越多越容易切入角色，越容易产出更符合中台定位的产品方案。
另外，搭建中台大部分是从零到一，搭建好基础后期比较好维护，而且是多个团队协作，涉及到模块拆分和能力域边界的划分，所以最好要有经历过从零到一的项目的经验，能够知道如何跨团队协作。
如果产品或者研发只懂业务，没做过中台，能做中台吗？
也不是不能，要组一个低成本的高潜力团队。
如果产品没有做过中台，就要求产品具备较强的抽象能力，搭配做过中台的研发。
如果研发没有做过中台，就要求研发有较强的抽象能力，搭配一个懂中台的产品。
以上都是相对好且低成本的团队组合，在配合时保证大家能够在预知未来业务走向的情况下，合理设计中台的产品方案和技术实现方案。
前面说的是技能方面，那从个人追求上面，你适合做中台吗？
答案是看个人方向了。
有的小中台配备的产研人员是既负责业务需求又负责中台需求的，所以离业务可能比较近，对业务侧产品实现方案是有一定决策性的。