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

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

说实话，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 和我吐槽市面上招不到中台产品经理，长期的解决方案是随着大家都开始做中台，必然有更多有经验的中台产品经理被培养出来；短期我只能和他们说，要不看看乙方公司懂企业架构的人才，和“本土”人才互相补位推动中台的建设。

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

本文转载自健荐公众号。

原文链接：https://mp.weixin.qq.com/s/pHdsIrl8tOt2Ze91IkcJlw