互联网公司中所谓中台是怎么定义的？

大约从去年年底开始，中台的概念开始被广泛讨论。

但与此同时，关于中台究竟是什么，却是众说纷纭。引用王健老师在《当我们谈中台时，我们在谈些什么| 白话中台战略》一文中提到的关于中台的一些理解，就能看出一些端倪。

在有些人眼里：中台就是技术平台，像微服务开发框架、Devops平台、PaaS平台，容器云之类的，人们都叫它“技术中台”。
在有些人眼里：中台就是微服务业务平台，像最常见的什么用户中心，订单中心，各种微服务集散地，人们都叫它“业务中台”。
在有些人眼里：中台应该是组织的事情，在释放潜能：类似于企业内部资源调度中心和内部创新孵化组织，人们叫它“组织中台”。

这些理解都对，但也都有不够准确或不够完整的部分。中台，作为一个还在被定义当中的概念，正处在一个大家都有感觉，但又难以被定义的状态。而且可预见的是，这种相对模糊的状态可能还要维持相当长的一段时间。

与此同时，在查阅了大量资料、并与京东等大厂的中台相关负责人沟通后，我们发现，目前行业内对于中台讨论的视角还是多偏于战略或组织架构层面，而中台更多是因为公司业务在发展到某一阶段时，遇到瓶颈与障碍后，为解决实际问题而提出的解决方案。

虽然基于战略的角度去看，确实能够让大家视野开阔，从更高维度理解中台。但战略是基于实际业务而制定的，如果撇开业务去空谈，就如同空中楼阁，还是无法了解中台到底是什么。

接下来，我们将会站在实际业务的角度，探讨一下中台的“前世今生”，以及如果想要成为一个中台产品经理，你应该具备哪些能力。

01 为什么需要中台？

市面上讲到中台，一定会提到两个例子，一个是13年马云参观supercell，然后在15年确定了阿里的中台战略；另一个是华为的中台战略转型，也就是那句著名的“让听得见炮火的人指挥战斗”。

这似乎会给大家一个错觉，似乎中台是一种自上而下的战略选择。老板觉得中台好，所以要搭建中台。

不过，现实情况，或许与绝大多数人想象不太一样，中台的产生，并非完全是自顶向下的战略设计，也并非是为了追随某种行业风口，而是随着公司业务高速发展、组织不断膨胀的过程中暴露的种种问题需要被解决。而这时，中台的概念恰好对应了这个问题，所以大家接受了中台。

过去几年中，借着移动互联网的红利，许多公司都高速发展，进行大规模业务拓展，业务拓展的速度足够快，对公司自然是好事，但是随着而来的问题就是，公司内部出现了大量的重复建设和资源浪费的现象。

阿里的共享服务部发展历程就是如此。

公司刚开始只有淘宝，后来意识到B2C模式的业务也会是电商领域重要的组成部门，所以出现了天猫，随着天猫的不断发展，逐渐独立成一个部门，但是这两套都包含订单、商品、库存、价格、仓储、物流等基本业务系统。这两个系统互相独立，各自运行。

等到10年左右，阿里开始上线1688、聚划算等业务的时候发现，这些业务针对的领域虽然各不相同，但是他需要用到的系统功能也高度类似，主要也是订单、商品、库存、价格、仓储、物流等系统。如果这些新业务的系统也都要全部重新开发一遍，这无疑是很大的资源浪费。明明既有的系统调整一下就可以满足新业务的需求，为什么还要继续开发新系统呐？

在这个大的背景之下，阿里内部将共享服务部的职权不断提升，统一将各个业务业务部门重复使用，反复建设的功能和系统统一规划和管理。

其实，很多公司的中台部门，或者平台业务部门的出现都有类似的背景和情况。

比如说，滴滴在15年末开始启动自己的中台战略，这与滴滴当时的业务发展阶段也是相关的。

2015 年末，滴滴在短时间内形成了包括快车、出租车、专车、顺风车、代驾等多业务的垂直化架构。

这些业务虽然会有一些差别，但是核心系统和流程都是类似的。如果各自独立开发，也会出现各种各样的问题。

比如说，开发成本过高，滴滴旗下的每个业务，其实都是可以单独支撑起一家公司的，如果每个业务都独立做到极致，那么开发成本和人力成本就会非常巨大，而如果为了控制成本，就把系统的建设放缓，则意味着，无论是核心系统本身的质量，还是对外的用户体验都不太好。

在这样的背景下，滴滴也开始考虑将诸多业务，以及各个城市的系统统一规划，统一建设，提升服务前台的能力。

其实，刚刚我们提到的，以及许多正在实践中台业务的公司，都有类似的问题，这些问题，大约会是两类——

一类是，许多业务需求或功能需求高度类似、通用化程度很高，但是由于没有专门的团队负责规划和开发，大量的系统重复开发、重复建设，导致复用性低、效率低、产研资源浪费、用户体验不统一。

另一类是，早期业务发展过程中，为了解决一些当下的业务问题，垂直的、个性化的业务逻辑与基础系统耦合太深，由于没有平台性质的规划，横向系统之间、上下游系统之间的交叉逻辑也非常多，这样导致在新业务、新市场的拓展过程中，系统没法直接复用，甚至没法快速迭代。

这两类问题，在软件开发领域，有专门的名称，叫做“重复造轮子”和“烟囱式架构”。这两类问题本质上是企业在发展过程当中，为了解决当下的业务问题，快速上线了很多功能，而欠下了许多技术债，当企业进入成熟期之后，发现这些问题的存在，严重影响了企业的运行效率和运营成本。

如何能够机制化，产品化地解决这些问题，能够更好地通过产品的形式，将企业内部具有很强的通用性的数据、功能、产品甚至经验进行统一规划和开发，进而更好地帮助前台业务部门更多地关注业务，提高业务运营效率，进而提升企业竞争力，是企业开发中台的基本出发点。

现阶段，大多数提出中台战略或是建设大中台的公司，大多都有类似的困境。业务高速发展多年，许多问题积重难返或者大量在解决“重复造轮子”的问题，中台这个概念，很多情况下是因为契合了大公司业务的发展的情况，而被大家广泛认可。

02 中台能解决什么问题？

前面的内容，我们大致介绍了中台要解决的问题。这给我们一种感觉是，中台是只有大公司才能做的事情，因为毕竟只有大公司在会有这种多条业务线，需要大量通用功能的场景，也只有只有大公司有能力拿出如此大的资源打造个中台。

现实情况也如我们所说，很多公司的中台业务，实际业务发展到一定阶段，进入一个瓶颈之后，为了能够应对接下来的问题，才一点一点从内部开始推动解决之前的问题。

但这其实只是中台建设的一个层面。

中台作为一种产品设计思路，或者系统架构思路，并不受限于公司的规模，理论上讲，任何一家即将或者正在面临业务高速增长的状态时，都很值得利用和借鉴中台的思路，将目前业务当中大量可复用的功能和场景进行梳理，为业务的高速增长做好准备。

这在中小公司当中，是有现实意义的。

对于很多中小公司，当他们走出生存困境，进入到高速发展阶段时，会遇到很多的问题，但大概率会遇到的一个问题是，过往的业务模型，产品能力很有可能没法完全承接住大规模用户增长带来的压力。

而当你具体到每个用户的时候，你又能发现，他们遇到的问题你之前都遇到过，只不过，因为一下来的太多，你没法像过去一样提供达预期，甚至超预期的服务时，对方就会产生不满。

这也是为什么许多公司会生于拉新，死于留存的一个原因。

很多公司在这个阶段的选择都是为了临时解决一个问题，快速上线一个功能，也不是不可以，只不过，很有可能你的解决方案会不断带来新的问题，最后陷入到功能太过复杂，以至于积重难返的地步。

所以，在有可能的情况下，公司将一些大概率长期有价值的功能，专门模块化，进行开发和优化，确保即使业务规模进一步扩大，也能够满足业务需求。甚至，随着能力或方法论的不断优化，甚至有可能某一天成为整个行业的方法论。

这个过程，就很像是在高速飞行过程中修飞机一样。一方面，机翼已经千疮百孔，摇摇欲坠，另一方面，发动机还在运转，你还能往前飞，但你知道，如果再进入到下一场战斗，你不见得还能确保飞机不会坠落，所以，必须抢在下一次战斗前把飞机修好。

随着业务的发展，你对飞机的要求，也不仅仅是修好，可能会希望，能够提前预防一些问题。或者，知道你的飞机哪里战斗力最强，就把哪里做到最好。或许，就能够回避之后的一些问题。

这或许是中台这个概念，对于中小公司内部产品规划的一个启发。

当然，需要提示的一点是，对于中小公司而言，中台的理念不见得是单独拉几十人搭建一个中台产研团队，可以将一些关键流程先行标准化，把一些反复出现的场景当中的解决方案进行沉淀，部分需要产品化的功能先行产品化，可能对于一家业务刚刚开始起步的公司来说，就已经很重要了。

03 中台产品经理的挑战

之前的内容，我们其实花了很大的篇幅来讨论，为什么会有中台，中台解决怎样的问题，以及中台适用怎样的场景。

但是，具体到业务场景当中，中台产品经理又在做什么事情，解决怎样的问题？如果想要成为一名优秀的中台产品经理，又会遇到怎样的困难和挑战？

我们采访了一些大公司的中台部门之后，会发现，中台产品经理面对很多挑战，其中，最主要要是最困难的挑战，主要集中在这样两个方面。

一方面，是思维的差异。

很多产品经理并不是从一开始就从事中台相关的事宜，也不是一开始就有中台这样的定位。更多情况下，他们是从前台业务部门，或者以业务为导向的产研部门转型到中台产研部门。

这时，其实要面临很大的思维方式、做事方法的转变。

在业务部门或者以业务为导向的产研部门，最核心的目的就是达成业务目标，要求你速度足够快、功能高效地解决当下的业务问题，当前业务发展的效率是最关键的。

至于说，这个功能将来有没有可能适用于别的场景，有没有可能解决别的问题，这个问题实在是没那么重要。

但是，对于中台不能如此。

对于中台产品经理来说，必须思考的问题是，这个功能在现在或者将来能满足多少业务场景？如果将来有新的业务出现，是不是能够复用？或者说，需要做多大的调整才可以复用？甚至于，这个功能有没有可能对外输出，提供SaaS化的服务。

这些问题，是中台部门需要思考的问题。这是思维上的差异。

另一方面，是环境的变化。

当你在业务部门的时候，响应业务是相对轻松的。但是，在中台部门，响应多个业务，就没有那么轻松了。

就拿需求调研为例。在业务部门或以业务为导向的产研部门的时候，你只要和对接的业务人员沟通清楚需求就OK了，毕竟，你只要了解这一个或对应的多个部门的业务需求即可，业务目标相对比较明确。

但是，当你需要响应多个业务部门的时候，就没有那么容易了。

你会发现，同样一个需求，A部门的流程和B部门流程完全不同，或者，流程是相似的，但到具体细节的时候，却有很大差异。

更可怕的是，同样一个问题，由于业务的发展阶段不同，对于问题的态度也全然不同：有的部门业务已经非常成熟，自己流程也很清晰，所以不太希望你来调整他们现有的流程；但是，有的部门还处于探索期，还没有遇到你提出的问题，可能压根就不理你。这时，对于中台产品经理的挑战就非常大。

他们可能会将大量的精力耗散于不同部门之间的沟通协调，反复对同一个需求进行确认，很长时间没有明显突破。这个时候，就要求中台产品经理有很强的沟通、协调和协作能力。

并且，因为他们接下来要做的解决方案，是要服务于多个业务。这个时候，需要中台产品经理有很强的逻辑思考能力，看到不同需求之间的共性需求，并提炼出一个产品化的解决方案。

甚至于，对于一些尚未遇到这个问题的业务部门，可能还要帮他们前置地思考解决方案。

这又很要求产品经理的逻辑思考和抽象思考能力。

既需要沟通协作的软技能，又需要逻辑抽象的硬思考，这可能才是中台产品经理最有挑战的地方。

虽然有挑战，但是也不见得没有方法。对于中台产品经理来说，刚刚我们提到的内容，也只是帮助中台产品经理，对于中台产品这个岗位所要面临的挑战和工作，能够有一些初步框架性的理解。

但是，在实际业务场景当中要解决的很多复杂问题，受限于篇幅，我们还没有详细讨论。

对于中台产品而言，他们的能力要求其实跨越非常大。一方面，需要极强的逻辑思维和战略分析能力，能够看到业务当中的关键流程，理解业务接下来的发展方向，并将其转化为产品功能，与研发一起实现。另一方面，又需要极强的沟通和交流能力，能够在与多个业务线，需求、背景、想法各不相同的相关方一起，推动完成相关功能的实现。

这背后，是技术，也是艺术。

某种意义上，能够掌握掌握这两种似乎有些对立思维，并能够灵活运用，可能距离成为一个优秀的中台产品经理，就不太远了。

最后，如果你想了解更多关于产品经理的干货和内容，欢迎关注 @三节课 ！
如果觉得内容对你有帮助，欢迎点个赞，比心心～❤️

中台概念 是相对于 烟囱概念 而设计的

大部分公司的最早期，都是一条业务线

然后公司做着做着，成立了新业务线

每一个业务线的早期，都是自己完成自己闭环

这个闭环是一个烟囱，包括了前后台

多个业务线，是多个烟囱，多套前后台

就像你在伦敦，看到大大小小各种各样的烟囱都在飘着烟，属于多个不同的团队

其实本身没什么，闭环效率也不错

但大老板不高兴啊，要人效

因为烟囱多了每个都要一个开发维护的产研团队，专门的服务器，专门的管理，贵啊

他就想你们能整合整合吗？

这时候CTO和产品老大就说，也行，把功能类似的模块都合并，团队缩编

这个就叫中台

人少了，感觉产研人效就上去了，成本下来了

大家都很满意

然后，非闭环导致的沟通成本和无限排期，业务需求根本响应不过来，效率下降了

这时候业务老大们就说，我们业绩不好就是因为你们效率太低，你们加人吧

加人成本不又上去了吗？老板不同意

于是最后结论，把中台拆分到各业务线自己搞吧，自己管自己的事

中台就没了

哈哈哈

企业组织的分分合合是常态，不要太在意这些概念

要搞中台

想想你们公司什么业务结构，什么发展阶段

再看中台是否真的有用

别听那些人忽悠

特别是别听阿里的人忽悠

阿里搞中台

一，看到有个游戏公司开发游戏有通用引擎，觉得不错，可以提人效

二，阿里大部分业务都是电商业务，系统结构比较同质化，容易做合并

三，有钱，有人，能折腾

你有吗？