七问七答，亲历者讲阿里中台落地的实践

关于作者：我2013年转岗到阿里巴巴交易平台，从2014年开始推动阿里巴巴交易运营平台的建设（阿里交易中台的前身），此后推动阿里巴巴交易中台的建设直到2016年离开阿里创业。

缘起

在过去一年的时间中台这个词流行了起来，从市面上的文章看很多朋友讲中台的时候倾向于把平台等同于中台，甚至是后台当中台，在打算写这篇文章前我觉得把中台讲的最透彻的就是王健先生的“白话中台”系列 —— 定义中台为“企业级能力复用平台”，特别是用Pace-Layered Application Strategy中的SOD（Systems of Differentiation） 来定位中台。

但是还不断有朋友问我中台到底是什么、怎么做，其中还不少资深的产品/研发同学，我完全不怀疑他们的理解能力，那么一定是有地方出现了问题，我把这个问题定位在“落地”，标杆企业中台的理念已经说了太多，但是极少有人讲如何落地，导致大家不只是没吃过猪肉，也没见过猪跑，只是听说过有猪这么个东西 —— 据说比狗胖，比牛小，不挑食，长肉快。

所以，有了这篇文章，把最近朋友常问到的“中台问题”以及我常讲到的“中台故事”完整呈现一下，让大家有个对中台更真切的体验。

老板说我们也要做个中台或者中台化，大家一脸懵，到底什么是中台？

当初我们在马老师提出中台概念之前就开始做“中台”， 所以没遇到这个问题，但是我有个故事应该能一定程度解答这个问题。 

我刚进入阿里巴巴交易平台的时候先是开心，因为交易平台是阿里的核心系统，和自己合作的都是技术体系的大牛，做什么需求都丝毫不担心技术实现，但是不久之后就很困惑，因为交易平台几十个开发，每年（只能）做1000多个需求，研发差不多每天都要加班到晚上10点左右，作为产品经理我一年要开900多个会，每天18:00之后才能正经写写文档做做设计，和研发的下班时间差不多；但是即便大家这么努力，交易平台的需求周期依然是特别长，整天被业务线投诉。这个事情困扰了我半年的时间，后来一个晚上和渐疯老师聊的时候聊出了这么一句话 —— 我们建设了很多平台能力，但是缺少管理这些能力的能力 —— 这句话有点儿绕，但在当时我们有种被“点亮”的感觉，因为当时我们面对的问题不是常见的“资源不够”，而是“失去掌控”，本质上，是集团交易平台快速发展了10年，平台治理没跟上，同时面向业务的视图缺失，导致平台对业务的响应速度跟不上，沟通也不顺畅，有点儿力不从心。

一开始我们要做的东西叫“运营平台”，让常见需求“可配置”，业务变更有地方可查，很朴素的想法，后来进化到“交易中台”，我们一直围绕如何对平台能力的有效管理在做事情，从业务建模、系统改造、管理平台建设，目标都是交易平台能够快速对接、有效管理电商体系内各种商品、资金、交付方面的能力，并用业务可理解的方式呈现、复用、整合。一直到现在交易中台的建设仍然是按照这个方向在发展，这个过程中“业务视图”被建设的越来越好了（参见极客公园专访玄难的文章）

所以当老板突然说我们要做中台的时候，我的建议是去理解“我们要做中台”这句话背后的诉求：多业务支撑、快速响应前台创新等现实问题。正常的情况下，每家公司做出来的中台都应该是不同的，因为不同阶段面对的问题不同，中台切入的点会不一样。

不过中台还是能有个统一答案： 

1. 中台是平台发展到一定规模，业务的扩展和变化超出了平台服务能力后自然生成出来的一个发展策略 —— 即中台是平台向业务进化

2. 中台的目标是更好的应对业务的变动和差异（王健先生文章中的pace-layered application strategy，SOD层面主要讲的就是这个） —— 业务稳定或者单一小伙伴们认真做好平台化，特别是IT治理就能解决大部分问题了 

3. 中台的价值是通过有效的管理让平台上的各种能力（功能/产品）能够有效复用、快速组合，支持业务更快捷的进行探索和发展 —— 如果老板问中台定什么KPI，最直接的其实就是需求交付时间，只不过这个时间的精准度量也是比较耗精力的

一句话，千万别把中台当作前后台中间的那个，不在一个维度上；中台这个名字其实是平台的升级版。

我们公司有几十个开发，怎么做中台合适？

说实话，10个人问我这个问题，9个人我都直接说压根就别做，先问两个问题：

1. 现有平台的成熟度怎么样 —— 有多少需求是可以基于现有功能做少量开发工作就直接复用的？

2. 现在平台团队人员的成熟度怎么样 —— 应对业务需求的时候能否清晰、高效的分析需求，以高于业务的抽象能力给出方案评估，而不是单纯的“接”需求？

我聊下来真的是很多公司因为现在平台的能力不足、人员水平不高，希望用中台这个灵丹妙药解决问题；我的反馈是如果现在的平台、团队成熟度不足，那么直接搞中台的结果就是引入了新的瓶颈，而且这个瓶颈比现状还要恶劣，这个瓶颈是 —— 由于不能正确的进行业务和系统抽象，做出来的中台既不能让业务开发更灵活，也没有让平台治理更高效。传统意义上的“互联网产品经理”在做中台这个事儿上没什么优势，反过来说也是好事，大家水平差不多，谁学习能力强谁能做。

还有个更现实的问题，上面这两个问题，我作为外部人可以直接问然后说现在做中台不靠谱，你作为企业内部的产品研发负责人是很难开口的，那怎么办呢？

1. 咬牙跟老板说能做，然后打着中台的旗号先扎实平台能力，同步以试点的方式由核心到边缘做中台化的包装，挺多朋友真的用了这种方式

2. 跟老板说实话实说家底不够，然后通过专项支持、feature team的方式先确保对业务的有效支持，系统和人员成熟度提升之后再推动中台建设。

方法无分对错，心里不要有压力，主要看公司文化和老板的风格；结果有好坏，取决于是否能找到一个适合自己公司、业务、团队的实现路径，把中台这个战略落下去。回想在交易中台落地的过程中，玄难亲自上阵review代码，范禹顶着业务压力让天猫研发团队全力配合，真的是福报，没有他们就没有现在的阿里中台；也可能是正因为是阿里，才有这样的管理者吧 …… 

Anyway，这个问题的答案是每个中台产品经理都要自己去寻找适合自身发展阶段的落地路径，活下来，做出来。

那你当初是怎么做的？

不能直接讲怎么做，容易把人带到坑里。其实秘诀就是找路径，多学习，活下来。

从哪里开始做

当初阿里做中台，是从交易开始做的，当初其实是个自然而然的过程，因为我们先做了。后来我离职创业、加入其他公司，从中台的实践者、到观察者、再到实践者之后，我的判断是：在当下如果想把中台做好，一定是从公司的“强中强”业务出发进行中台的探索，在形成了自身的“中台方法论”之后，再横向铺开。

什么叫做强中强？就是这家公司或这个组织在行业中最有优势，在内部又有影响力的部分，比如阿里的电商平台、学而思的教研、头条的算法。即兼具外部优势和内部影响力。

这个事儿是我创业之后才想明白的，中台的目标是服务业务的，特别是多变性的业务，我们离开单纯的产品，去想基础的商业逻辑，就是无论我们是业务创新还是拓展，最适合的路径都是从自己的核心能力出发，成功率才高。所以中台本身要“做成” —— 产品落地、价值被认可 —— 就需要内部客户的认可，最优选择就是要选公司内有强势资源、外有强势能力的团队，中台落地遵循这个规律从强势能力、核心能力出发来进行中台化才能够有明显的产出和足够的影响。而且这种能力甚至未必是IT能力，就像学而思的教研其实是个内容能力，或者华为的组织能力，都是最适合进行中台化的。

反之，弱势能力做中台化，面对的问题将是客户不关心，自身能力跟不上，最终两败俱伤。逻辑上这么讲大家一般都能够理解，但是现实中能够下决心这么做的老板并不多，怎么说呢，这些把中台落的的“牛逼”公司，可能也就牛在这种战略落地能力上…… 不过也不用灰心，中台建设就像打仗一样，争取资源，控制预期，从适合的场景出发不断迭代拿出成效，积小胜为大胜，也会是一条能生存下来的中台建设之路。

用什么方法

回想阿里交易中台，我们当时采用了两类方法论： 

在阿里中台建设的初期，我们习惯性的采用互联网从需求到功能的敏捷方式，遇到哪里的效能有瓶颈我们就工具化的方式解决；后期引入了基于企业架构的思路，尝试对中台能力进行拆解、建模、系统化的实现，当时TOGAF、eTOM、DDD的东西大家都要学习参考。

两种方法各有优缺点，采用敏捷的方式可以快速的解决当下遇到的各种问题，但是缺少框架、体系上的参考，是一种用to C（消费者）的方式做to B的感觉；而基于企业架构的思路有明确的体系参考，不过企业架构和现有的方法倾向于在相对确定性的业务环境中进行分析和设计，过程比较长。

当时我们抽调了将近10位业务和架构专家，关在会议室里面做业务建模、系统设计，基本上都是以周为单位推进，这个在互联网产品经理视角上基本是高速路上龟速行驶了，不过没办法，一边探索一边前进。还好，过程中不断的有一些成果出来，至少让业务线感知到情况在逐步变好。

如果现在重新做一次，我的路径选择会是：

• 对内（中台团队），基于TOGAF ADM、DDD这样的企业架构方法论对已有的能力进行梳理，确定哪些能力可以以什么样的方式进行复用。

• 对外（前台团队），围绕前台的应用场景建设业务“视图”（这个用词不精确，叫界面可能更好），业务什么形态就给什么视图，比如电商的业务视图是什么？电商的业务视图就是人货场的设计；算法的业务视图是什么？业务场景、训练目标、评价策略；组织中台的业务视图是什么？组织目标、分工架构、协作流程。

整体过程中采用敏捷的方法，分期迭代不断修正，因为团队对中台的认识也会在这个过程中不断深化。前段时间王健老师分享了他们在咨询过程中综合使用了敏捷的框架，然后用TOGAF、DDD（领域驱动设计）、DT（设计思维）的方法，结合工作坊的形式来做中台架构设计，我听的过程中脑补了一下，很真切的能匹配到落地过程中方法、节奏、沟通上的问题，非常受用。

回到前面提到的互联网产品经理怎么做中台，单纯掌握“互联网产品”技能做中台是很容易挖坑的，持续学习企业架构，参考“最佳实践”才可能走出自己的路。

有了中台，还要跟业务反复沟(si)通(bi)么

在做中台的那段时间，我感觉自己的时间是 1/3 做业务建模、产品设计方面的工作， 1/3还是要接业务需求，只不过做中台被训练了一轮后谈需求的效率会比原来高，因为自己对平台的理解也更深入了，剩下 1/3的时间是原来不曾有的一种工作，就是和所有相关方“聊”中台，因为新的产品形态和对接方式会让大家不知道怎么和你合作（对比一下财务报销这么简单的流程，每个新人到公司都会经历一次或者N次被打回重做），如果所有人都不能和你顺畅合作，那距离团队重组也就不远了。作为一个“中台布道者”，几乎要对上、对下、对前后左右所有相关的团队去聊中台怎么做的、什么进展、带来的价值、怎么有效合作，过程中也会夹带着业务、架构方面的问题去寻求共识。

可以说中台不仅仅是交付一个系统或者是个产品，中台其实是一种工作方式的变化，平台的工作方式比较像职能角色，接需求、实现掉；而中台在做好平台的基础上要更向前一步，去想如何让业务跑的更快。 

传统的组织架构有两种基本形态：基于职能的（function），基于产品线的（product/business unit）。中台是从职能架构“衍生”出来的，在中台你要从职能看业务、想业务。这种架构好不好呢？每一种组织架构都有自身的优缺点，其实中台架构和矩阵架（最典型的一种衍生的组织架构）构遇到的问题很像：矩阵架构永远要面对职能团队人不够分的问题；中台架构则是在技能上要求更高，中台产品经理要更懂业务发展而非单纯的平台能力，不止一位HR和我吐槽市面上招不到中台产品经理，长期的解决方案是随着大家都开始做中台，必然有更多有经验的中台产品经理被培养出来；短期我只能和他们说，要不看看乙方公司懂企业架构的人才，和“本土”人才互相补位推动中台的建设。

中台，只有当工作流走顺、组织健壮起来的时候，才是真正“把中台做出来”的时候。

还有什么要嘱咐的？

互联网产品经理做中台产品真的不容易，就像战役的筹划一样要知进退。这个知进退是知道能做还是不能做；这个知进退是知道什么时候要主动开始，什么时候要埋头打基本功；这个知进退是知道在哪里面向业务处理变化和差异，在哪里回归平台抽象共同点；同时，这个知进退是知道什么时候大张旗鼓的推广，什么时候静悄悄的改bug。

总之， 一个产品经理在自己的职业生涯中能做一次中台，是你的福报。（来自马老师的微笑）

** Photo by Headway on Unsplash