我的一年中台实战录

市面上有关中台的“应景儿”文章越来越多，但是讲概念的多、有干货的少，毕竟中台虽然热，但是还缺少真刀真枪的实践。而恰恰本文作者，就是一位中台的实践者。他所在的团队用一年时间搭建中台，虽然因为公司战略和组织架构调整，中台项目被停止了，但是其间有太多的收获、感悟和反思，借本篇文章分享给对中台感兴趣的朋友们。

令人唏嘘的一年

故事的开端

2018 年 3 月份，我正式成为一名中台产品经理，在这之前的一两个月，我已经和 Sunner 就中台的发展有了多次沟通。我们要做一个在线教育领域的中台产品——爱多思（EduOS），顾名思义，就是一个在线教育的操作系统。线下教育的教学工具有桌椅板凳，黑板、粉笔、投影仪等教学设备，组合成物理世界的课堂，爱多思的目标是构建出线上教育里的桌椅板凳，让其能够自由组合成一整个在线教学管理系统（LMS），并形成标准。

这是一个有挑战的活儿：

首先，当时中台在互联网公司是个新概念，如何在互联网公司里做一个中台，业界并没有太多的成熟经验可以参考；

其次，各条业务线里烟囱式的教学系统已经分开跑了很久了，在这个基础上搭建中台，就好像在给飞行中的飞机换引擎（当然，并不是每条业务跑得同样快，这也是中台能够在各个业务产品间周旋的基础）。

17 年阿里出版的那本书「阿里中台战略」是我们当时唯一找到的理论基础，阿里大中台几年的实践，以及 17 年我们通过一支几个人的别动队在内部对可行性的探索，最终让我们在申请立项时说明这事可以做成。

中台项目正式立项，我成为立项后第一个产品经理，Sunner 是负责人和产品架构师。我们计划用两年时间把中台搭建好，让爱多思能够支撑各条业务线的发展，并且能快速孵化出新的业务。然而一年过后，2019 年 2 月底，因为公司战略和组织架构调整，中台项目被停止了。

我依然清晰的记得那天，大家在会议室里讨论已经在线上跑的中台服务未来何去何从，想想在云端本地无数的代码库中有一套打着那天的 tag，然后就没有再更新过，让人唏嘘不已。

这一年的收获

回顾这一年，我们做成了这几件事儿：

1. 完成了多个教学服务的中台化改造。其中包括一些底层的基础服务，如账号、权限、点播、直播等；也包括一些具备教学逻辑的模块，如直播课、题库、问卷等等。每个服务都可以单独拿出来做成可直接给终端用户使用的产品，类似于 CCtalk、问卷星，并且这些服务和模块都已经支持各业务产品了。

2. 总结出来中台化产品设计、产品研发、项目管理的一些标准规范和套路。依照这些标准和套路，没有中台经验的产品和技术人员也可以快速的开发出中台服务，并被业务产品接入使用。

当然我们也还有一些没做完的事儿，包括：

1. 中台教学系统的闭环。我们做了一些独立的教学模块，但还没能够用中台化的标准把这些教学模块完全组合起来，形成一个可以系统化学习的课程。

2. 中台价值的量化体系。只有做好了价值量化这一点，我们才算完成了中台在商业世界里的实践，并且经验可以被推广到公司内外。

3. 中台商业化的探索。 我个人一直希望能够把中台做成一个可商业化的企业服务，不仅仅只是一个内部支持型的产品。 中台项目停止后，我也依然在教育 ToB 行业。时常在想：如果有了成熟的中台能够对现在的问题有什么帮助？现在看起来， 在国内目前的商业环境下，一个好的中台，其对内服务产生的价值还是远远高于对外直接输出的价值， 庆幸当年 Sunner 压制住了我想快速商业化的诉求。

假如我们能有两年时间，不知道能否达成最初的目标，也不知道未来是否还有机会继续？但我几乎肯定的是：中台会在接下来互联网和传统产业深度结合时，变得越来越重要。名字除了叫中台外，还可能会被称为平台、中间件、共享服务等等。

此外对于我个人而言，应该说我这一年的收获良多：

1. 进入互联网行业后，小步快跑成了常态。而在中台的这段时间，我难得能够暂时放开业务的压力，按照近乎理想化的标准去进行产品架构设计、做抽象、画 UML、花时间仔细思考。我本不是这样的人，这也算是在刻意练习了。

2. 作为一个在线教育行业的新人，通过中台我能有机会参与整个事业部涉及的所有教育业务，包括 K12、成人、ToC、ToB，让我对在线教育行业有了一个更全面的认识，从中寻找兴趣所在。

3. 结识了一帮优秀而有趣的小伙伴，大家一起做有挑战的事情，也才有了这篇文章里的回忆。

都在谈中台，究竟什么是中台？

中台的概念

中台是近年来 IT 行业非常火的概念（这里最好加上一个”IT 行业“的限定，因为曾经有商务同事以为我是研究两岸关系的，哈哈），有很多的文章从产品、技术、组织等多个角度来解释什么是中台。对于一个快速变化的新概念而言，很难有标准定义，阿里中台某高管都提到过现在阿里所做到的离他所定义的中台还有一段距离。

给定义是非常谨慎的事情，但很多时候不给定义又没办法继续聊，所以我也曾经在一个内部分享上给中台做了定义「服务于某个垂直领域的工具平台」。在做这个定义时，我是参考了云计算的概念的。云计算是一种通用服务，那么中台和云计算有什么差别呢？按照 IaaS/PaaS/SaaS 来划分，服务的领域越来越垂直。参考这种方式，我会定义中台在 PaaS 和 SaaS 之间，主要原因如下：

1. PaaS 提供了一种服务，客户的程序员通过二次开发使用 PaaS 服务，最终完成某个功能给最终用户。PaaS 的通用性需要非常强，这样才能获得足够大的市场，比如 IM、视频云服务等，也因此 PaaS 往往是没有界面的。

2. SaaS 提供的服务不需要客户进行开发，只需要开通服务，在管理后台上配置一下就可以直接使用。但 SaaS 服务往往针对的是一个细分领域，其定制化能力也相对弱很多。即使是像钉钉，钉钉选择 IM 这种企业中最通用化的服务，同时做成企业服务的开放生态，目标客户也主要是覆盖中小企业。定制化需求强的大客户，也往往会需要希望借助 IM PaaS 服务来自主研发内部 IM 工具。

3. PaaS 和 SaaS 定位在服务外部客户，必须具备很低的使用成本。即使是需要通过技术来接入的 PaaS 服务，接入成本也一定要足够低，接口清晰，文档完善。

4. 中台首先是定位在服务公司内部客户，由于这个范围的限定，导致 中台的通用性可以在很多约束条件下来实现，可服务的领域比 SaaS 广。 比如即使同样是电商，淘宝、天猫、聚划算、闲鱼、飞猪的站点都是不一样的，而阿里共享事业部就在中台层服务多个业务。此外，由于中台的用户是公司内部的程序员，大家有相似的背景，也可以频繁沟通，所以服务接入的成本可以做得比面向外部客户的 PaaS 要高。

中台 vs 第一性原理

很多资料在介绍中台概念时都会引用这样两个例子：

1. 美军的特种部队加航空母舰的策略：10 人以内的一支特种部队在战斗的最前沿侦查，独立决策，一旦发现目标，迅速呼叫强大的中台航母群对其进行毁灭性打击。

2. 芬兰著名的游戏公司 SuperCell，开发了部落冲突、皇室战争等现象级的手游。整个公司才 200 多号人，就被腾讯以 86 亿美金收购。在 SuperCell 里，一个游戏开发团队平均是 3-7 个人，但有一个强大的游戏中台在做支撑，可以并行开发 50 款游戏，然后通过“内部赛马”产生出一到两款经典。据说马云在带领阿里众多高官参观了 SuperCell 后，回来就在阿里整个集团层面启动了大中台战略。

同时我想要对比的是另一个概念「第一性原理」。第一性原理也是近几年很火的一个词，基本已经成为完成颠覆式创新的大杀器。最典型的例子之一就是 Elon Musk 了。这个同时掌管 Solar、SpaceX 和 Tesla 的硅谷钢铁侠，从最基础的物理学原理出发，重新设计和制造的猎鹰火箭，正带领着人类飞向火星。

在上述例子中，第一性原理和中台都带来了创新和成功，但其实这两者在某种程度上是矛盾的。第一性原理往往是打破原有的经验，跳出舒适圈，从最底层逻辑去进行思考。而中台是将通用的能力进行抽象和共享，将成功的经验固化下来，将有限的人力投入到创新中去。

第一性原理是物理世界运转的本质，在没有时间条件的约束下，可以推导出整个世界。假如地球要灭亡了，只有一张纸上的信息能够保留下来，写在这张纸上的就是地球文明的第一性原理。基于这些可以重塑地球文明，但可能需要几千万年。

但人类社会的运转往往是有明确时间约束的，如果我只知道 1+1=2 时就要完成微积分，可能要穷尽一生。因此，依靠前人和自己的经验做事才是人类社会能够高效运转的基本要素，放在 IT 行业，这些经验就叫中台。经验往往能带来效率提升、成本提升、质量提高，同时也能带来偏见、惯性思维模式，中台也一样。

我们为什么要做中台？

随着「阿里中台服务」那本书在 17 年的出版，中台开始走进更多人的视野，并且在 18 年逐渐热门起来。但那时网上介绍中台的文章和分享还不多，记得我在准备公司内中台分享时，没有花多大功夫就看完了几乎所有相关内容。

而到了 2019 年，中台的热度迅速攀升，火爆程度有点类似 16 年的 VR、18 年的区块链。同时我也听说有创业公司连核心业务的商业模式还没摸清楚，上来就要搞中台。这其实是没搞清楚为什么要建中台、中台要解决什么问题：

首先，中台是支撑公司多个业务产品的共享服务，如果你的公司只有一个业务产品，能做的最多只能是良好的架构设计， 没有多个业务产品的实际场景输入，是难以直接做出中台的。

其次，中台的目标是提高业务产品的研发效率，但为了达到这个目的， 在一段时间内是需要以降低「效率」为代价的， 时间长短取决于系统复杂度和团队能力的差距。

当公司随着业务发展，需要研发第二个、第三个产品时，在这种情况下可能会有两种方式来构建中台：

1. 新产品和技术架构都是继承自当前产品，不断的通过优化当前产品架构来适应新的产品，让中台服务自然沉淀出来。这种情况下的前提条件是在做第一个产品时就做好了服务架构设计，即便如此，在第二个产品时很有可能还是要走弯路，不能满足新产品快速迭代和试错的渴望。但到了第三个、第四个产品时，就会变得越来越快了。

2. 新的产品和技术架构都是重新设计，这样做每个产品的速度都差不多，灵活度也能做到最高。但每个产品都很难在技术上从前面的产品去借力。当团队人员发生变动、产品越来越多，多分支的维护和开发就凸显了人力不足的问题，这时候就需要搭建一个中台。这也是我们当时所面临的问题。

我所在的事业部发展了多年，有五条业务产品线。这五条产品线就是从一条产品线开始，随着时间的推移逐步发展起来的。和大部分研发团队的情况一样，在应对快速变化的市场环境时，我们没有能够做好系统的底层积累，而是选择了一条在当时看来是更简单的路径：从一套代码 copy 出了另一套代码来支撑新的产品。

多年后我们就有了五个独立的系统来支撑五个业务产品。我无法判断如果当时做好了底层系统架构，整个部门实际会发展成什么样。只知道当五个产品要在五套系统上快速往前跑时，研发的复杂程度和成本都太高了。为了解决这个问题，我们决定做中台。

当然我们也可以有另外的选择——砍掉大部分产品，只专注做到一、两个。但大家都知道，其实 真正困难的不是决定做什么，而是决定不做什么，这种决策其实比做中台更加困难。此外，作为一家成熟的公司，一定是需要有能够形成合力的产品矩阵来支撑整个公司战略推进的，所以多产品并行是公司发展到一定阶段的必然选择，而做中台也绝不是站在其中某一个产品的角度来解决问题，而是站在多产品协同的角度来看公司的战略发展。

从公司战略来看，阿里巴巴的曾鸣在「智能商业」一书中提出了看十年、做一年的观点。在日益复杂而又快速变化的市场环境中，公司已经无法做到一个五年的准确的规划，并执行下去。而需要通过看十年的终局思维来看到行业最终会成为什么样子，从而制定公司愿景和方向。

通过做一年的方法来制定计划，快速落地一些事情，然后根据效果来迅速调整方向、更新计划，朝着终局推进。要想做到这点，基础能力的积累就非常重要，而中台也是其中非常重要的部分。

站在产品团队的角度来看，一个搭建完成的中台基础框架，能够带来的直接价值就是：

• 成本节省。 需要开发新功能时，很可能这个功能中台已经提供了，产品经理提供配置参数，研发直接接入服务就可以用起来了。

• 效率提高。 在中台上开发新功能，只需要参考标准和文档，一个新人也可以快速上手，并且这个新功能还可以被其他产品直接使用，产生复利效应。

• 质量提升。 从两方面来看：

• 设计质量。中台团队通常会以功能模块为划分，专职负责某功能模块的团队往往会更有意愿去突破一些难点，成为最懂此功能模块的团队。比如现在教育领域最热门的授课方式就是直播课，而直播功能就是一个有较高门槛的功能模块。要想做出适合业务发展的直播功能，需要对云计算、计算机网络、直播授课方法、直播运营等多个方面都有较为深入的了解。这需要团队能够有一定程度的积累，不是从某一个业务产品研发团队里找几个人就能很快突击出来的。

• 研发质量。中台的服务往往提供给多个业务产品使用，出现故障就会造成大面积的问题。所以 质量保障往往是中台服务的生命线。 每一个下沉到中台的服务不但会经过常规的测试，还会在 Code review、单元测试覆盖率等指标上有更为严格的要求，力保高质量的交付。

我们是怎么做中台的？

产品设计层面

随着中台的日益火爆，如何做一个中台产品经理也成了一个新的职业发展热点，最近也看到有了线上的中台产品经理课程。中台产品经理是 B 端产品经理的一种类型，有 B 端通用的能力要求，比如擅长做抽象建模、具备一定的研发技术功底、懂 UML 等，我在这里就不一一展开了。但就中台服务多个内部业务产品为主的特点来说，会对中台产品经理有些不一样的要求。在我个人的经历里，我认为有三点非常重要：

1. 中台产品经理如何设计出用户体验好的功能？由于教育中台对其服务的要求是从前端到后端的完整服务（具体原因在技术部分介绍），因此教育中台的产品经理所设计的功能需要直接面对最终用户，也需要保有良好的用户体验。