我们为什么要做中台？

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

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

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

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

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


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

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

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

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

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

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

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

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


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

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

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

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

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