什么是技术中台？为什么要做技术中台产品经理？

01 什么是中台？

想要聊清楚一个事物，一定要把它放到一个更大的背景和框架中去看。

提到中台，那一定离不开前台和后台。

在互联网公司，传统且普遍的开发模式就是前台+后台，也可以叫前端+后端，或客户端+服务端。

前台将计算需求告诉后台，后台将计算结果返回前台。

也就是说，由后台提供能力与计算，前台将前台的计算结果进行封装，并以图形的形式展示给用户，让用户能更容易地使用公司提供的服务来解决个人需求。

这种模式简单且高效，适用于大多数业务场景。

但是当业务日渐庞大，并衍生出多条业务线，这种前后台的模式就并不高效了。

就拿阿里巴巴的电商业务举例，最初时只有C2C模式的淘宝，后来衍生出了B2C模式的天猫，再到后来又有了团购模式的聚划算。

这三条业务线隶属于三个部门，但它们又有很多通用的模块，比如商品中心、交易中心、评价中心等，如果这些共性业务模块在三个部门分别建设一遍，成本会非常高，而且效率低下。

如果未来又有新的业务线，难道又要从头开始建设？

于是，为了解决多条业务线各自为战、信息资源不互通的问题，新的模式便出现了：前台+中台+后台。

前中后台各自的定位也非常清晰：

（1）前台：前端页面、垂直业务；

（2）中台：沉淀核心能力、赋能业务发展；

（3）后台：服务端、管理后台；

所谓中台，就是提炼各条业务线的共性需求，并将这些打造成组件化的资源/能力包，然后以接口的形式提供给前台各业务部门使用，这样就可以最大限度避免“重复造轮子”的问题。

目前有各种类型的中台，但整体可以分为三大类：技术中台、业务中台和数据中台。

（1）技术中台会负责将企业内部各个成熟的功能模块代码进行封装，产出通用的技术工具以方便不同业务线直接调用，如视频压缩SDK。

（2）业务中台负责为公司的用户需求提供基础解决方案，然后各条业务线会根据具体的业务场景进行定制。

（3）数据中台进行业务全生命周期中的数据管理，打破业务线间隔，将不同业务线产生的用户数据汇聚至中台。

但最后还是要提一句，虽然中台的概念这几年非常火，但并不是所有的公司都适合建设中台。

从中台的定位中可以看到，建设中台的时机有非常强的限定条件：公司内部有多条产品线，整体业务逻辑庞大复杂，而且在快速扩张中。

02 在阿里做中台产品经理是一种怎样的体验？

我在阿里这边做的是业务中台，中台产品经理和其他各种类型产品经理的基本方法论还是一致的，包括用户调研、需求收集、需求分析、产品方案设计、项目管理等。

但是各个环节的侧重点、做事方式和难度则有非常大的不同。

结合在阿里这近三个月的工作体验，自己对中台产品经理的工作方式和方法论有三个明显的体感：

1.业务复杂度高

中台的需求来源主要有两个：业务部门和自主发起。

在阿里的实际工作中，70%的需求是来自于业务部门，只有30%是自主发起的项目。

虽然中台比较好的发展模式是从上向下进行规划和建设，但实际上常常没有充足的资源去提前建设，只能在支持业务需求的同时，顺带补足中台能力。

中台要承接多条业务线的需求，但各个业务具有一定的差异性，而且不同业务部门提的需求只会从自己的业务角度考虑问题，也只关心自己的利益。

而中台具备全局视角，可以从全局看待各个“点”上的需求，从而有可能得到全局最优解，这便是中台的优势所在。

另一方面，这也能看出中台产品经理的工作难度，因为没有直接在一线接触业务，但又需要对各个业务线足够了解，包括支持业务方式、业务现状、业务未来规划等。

同时还需要对业务和行业有非常深入的认知，才有能力从全局视角看待各个“点”上的需求，做出合适的决策，比如哪些应该由业务部门来实现、哪些需要沉淀为中台能力等等。

那怎么解决业务复杂高的问题呢？

其实只有一个笨方法：从做中学，只能从一个个项目中积累业务经验，不断提高自己的业务认知和决策准确度。

2.系统复杂度高

业务模式根据上下游的关系，整体可以分为三层：蚂蚁基础技术中台、业务中台和各条业务线。

业务中台会调用后台的各种基础服务，然后承接前台各个业务线的需求，而业务中台本身也分为各个模块、各个子系统，因此中台承担连接器的作用，关联着多个部门和系统。

这就导致了在做需求时，可能一个很简单的需求，就要涉及多个系统的交互或打通，因此中台产品经理需要了解不同系统的能力和边界，知道不同系统都该做哪些事，这样才能设计产品方案。

同时，中台是非常黑盒的，有非常多的逻辑规则，但常常没有实体产品，这和做C端产品经理是截然不同的，上手难度也高了非常多。

在做C端产品经理时，经常会提到的方法论就是去做产品调研、竞品分析，多体验产品之类的。

但在做B端产品经理时，尤其是针对企业内部的中台产品经理，根本没有竞品可以参考，甚至上手体验自己的系统都非常困难，因为中台产品很多只是代码层面的“接口”。

这就是中台产品经理面临的系统复杂度高的问题：关联的系统多、整体黑盒、难以上手体验和调研。

针对这个问题，其实有一个非常有效的解决方法：画业务流程图。

在梳理业务流程图的过程中，就能从全局视角看到每一个环节所涉及到的系统、不同系统的交互方式以及边界了。

自己在做每一个需求时，都会先去梳理业务流程图，再去设计具体的产品方案。

3.推进复杂度高

根据前两点说的业务复杂度高、系统复杂度高，可以看到中台产品经理在工作过程中会涉及到不同部门、不同角色，因此对自身的项目把控能力、推进能力、沟通能力要求非常高。

说一个很简单的数据：自己在做某一个日常项目时，群聊中前前后后拉了40多人进行沟通，大大小小的会议数十次。

以前自己做C端产品经理时，高频沟通合作的角色无非是运营人员、设计师、前端开发、后端开发、测试人员等，但现在跨部门、跨领域、跨系统沟通就是自己的工作日常。

涉及到关联方多了，沟通成本会急剧上升，推进的难度自然大了非常多。

因此，首先需要一个合理的项目管理机制对项目的推进进行把控。

在阿里的业务中台，一个项目从立项到开发阶段会经历以下正式的会议：

那怎么才能更好地推进项目呢？

根据自己的真实体感和同事们的过往经验，想要有效推进项目的一个关键点是：找准核心干系人。

最关键的干系人有哪些？他们的关注点是什么？他们有哪些担心？

找准关键干系人后，做好信息的同步，就可以有效避免项目失控的情况发生了。

总结一下：

（1）做中台产品经理，常常会涉及不同系统和平台的打通，跨应用、跨系统、跨角色，因此需要划分边界，知道不同的平台应该做哪些事。

（2）中台产品经理不能只去做业务需求，要考虑需求对中台能力建设的价值，从不同业务线的个性化需求中抽象归类出共性部分进行建设。

（3）更高的要求是能够预判业务发展方向，提前中台建设，反哺业务。

03 为什么做中台产品经理？

回顾自己的过往经历，自己做C端比较多，对C端产品经理的工作方式比较熟悉了，那为什么自己还来做中台产品经理呢？

因为自己做C端产品经理过程中，发现自己虽然离用户比较近，但是离业务比较远，很多业务对自己而言就是黑盒，对公司内部的业务流程并不了解。

也就是说，自己已经初步掌握了C端产品经理的思维方式和做事方式，建立了用户认知模型，但是对业务的理解和沉淀非常少，没有对某一领域有深入的认知，因此现在自己需要建立起业务认知模型。

那又为什么要建立起业务认知模型呢？

因为真正的创新，是业务模式上的创新。

而想要在业务模式上有所突破，则需要对业务有足够深入的理解。

那种仅仅关注交互方式的产品经理时代早已经远去了。

以上内容就是“什么是技术中台？为什么要做技术中台产品经理？”中的全部内容了，如果你还想了解其他相关内容，可以来 产品壹佰 官方网站获取。