编辑导语：关于中台，本文作者对过去5年的经历做了整体回顾，分析了转转做中台的必要性和公司战略变化与中台不同阶段，一起来看看吧。

　　之前写了一篇文章【我做中台这5年】系列开篇：我的中台观，整体介绍了中台的基本概念和我做转转中台的一些观点理念。

　　接下来本文，会先对过去5年的经历做个整体回顾，带大家了解下转转中台大概的发展历程。

　　正文开始：2016年7月，我从美丽说离职，来到了转转。彼此我28岁，现在已不知不觉变为34岁大叔。

　　2016年，转转还不到200人。2021年，转转已有数千人的团队规模。2016年，刚起步的时候，我们主要做C2C模式。2021年，到现在变为了C2B、B2C、C2C、C2B2C、B2B全模式，且覆盖线上、线下交易场景。2016年，我刚进入转转，自己一个人，做运营后台，还没有中台。2021年，我负责中台交易&履约团队，经历了中台每个产品线发展的0-1。在这个过程中，公司的战略、业务的发展、中台的发展、团队的变化、个人的成长，是如何变化的呢？

　　《我做中台这5年》系列文章，从从宏观到微观，从公司到个人，会围绕每个阶段的关键系统或项目展开来给出答案。

　　接下来，我先针对二手赛道和我们转转从事的业务形态做一些简单的描述，让大家先知道为什么转转适合做中台？

　　上边这个图，大家可以看到新品电商和二手电商，在供销模式上的巨大差异。

　　现在主流的新品电商，尤其是平台型电商，更多精力花在售卖端对C买家心智和服务的打造上，供应链端都是由品牌/厂商/经销商等B角色来保障的，平台用买家端的流量反向控供应链端。

　　但是二手电商，却与新品电商有着较大的差异。

　　首先来看，二手商品与新商品相比3个巨大的差异：

　　供给分散，货源分布在一个个C卖家（新品买家）手里；供给非标，货源除了sku属性之外，有了成色的概念，而成色却是由商品上百项参数好坏程度综合影响的；用户信任问题，由于C卖家和C买家是平级的角色，平台并不能像B商家一样去要求C卖家具备专业的服务属性，再加上商品非标造成的两端用户理解信息差，会让用户交易体验很差，进而对交易和平台产生不信任（这里C卖家和C买家都会有用户信任问题）。所以，二手电商要想发展，就必须要解决掉在供给、标准化、售卖这些环节的以上3个核心痛点。

　　那对应来讲，二手也必然是一个重服务、重履约、低毛利的产业互联网。

　　看了以上二手电商与新品电商的对比，大家就会发现。

　　新品电商，核心需要解决的是采购、销售的问题，核心主要是销售问题，包含流量、交易、履约、售后等问题。那么在产品形态上，其实主要就是B2C交易。

　　二手电商呢，就比较复杂，面临的选择项也很多，我整理下在二手行业里面比较常见的模式：

　　大家看到上边表格中的模式，基本就是目前所有二手电商交易模式的总和。

　　模式变多，其实代表着平台从轻模式逐渐向重模式的转变，背后逻辑是二手问题需要用服务履约重模式来解决。

　　在上图的模式中，大部分二手电商平台，主要包含2~3种。

　　但转转在历史上和现存的模式中，却包含以上表格中的全部模式，共6种。

　　并且，在以上模式的基础上，各模式之间还存在较多的关联逻辑，例如转卖、同售，还有多终端经营。此外，转转当前还具备【上门回收】和【线下门店】的线下交易履约场景。

　　综上，大家可以看到转转的业务模式是非常多样化的，且模式之间又具备较强的连通性。

　　如果单独各个业务闭环实现交易履约全链路能力，是一个成本超级大的事情，尤其是转转做全品类生意，后续要面向更多品类、更多模式。

　　那么，“中台”这个统一化服务、统一化数据的架构体系，就非常适合转转的业务场景，可以让后续边际成本越来越低。

　　转转最早期的时候，基本上主要就是用户、商品和C2C交易链路相关的基础体系。

　　那现在为止，在交易（信息流）、支付（资金流）、履约（实物流）三大方向已经具备了相对完善的产品体系。如下图：

　　我们拿B2C为例，按照售前、售中、售后信息流大概看下这些系统的协作分布图：

　　接下来我们就按照时间线，来看看这些复杂的系统，是如何演变而来的。

　　以下是公司在过去5年多的战略变化，以及中台在各个阶段发展的重点方向和系统。

　　大家可以看到中台各个系统并未是一蹴而就的，它是跟随着公司战略变化，一步步匹配业务节奏实施落地的。

　　每个阶段，中台的资源是有限的，业务繁多，所以我们既要有横向兼顾，也都有重心，有针对性地进行中台系统沉淀，为以后更好支撑打下基础。

　　业务需求与中台建设，相互交替，日积月累，一点点变为了现在的产品框架。

　　结合上图，我把转转中台的发展划分为了以下5个大的阶段。

　　（1）工具效率

　　我记得2016年7月入职的时候，第一个做的项目就是【优惠券系统（内部也称红包系统）】，是针对公司当时十几个不同应用场景的优惠券做梳理和收敛。

　　项目结果，我们形成了一套具备扩展性、统一性的优惠券系统框架。

　　这个项目，看起来是做了一个优惠券系统，但其实更多是中台化的思路，收敛存量以及设计增量扩展性。目前这套优惠券系统，几经迭代，但是它的内核框架始终没有变过。

　　2017年2月左右，我发起了另外一个项目【魔方】，这个也是针对当时公司各个业务独立做专题页实现的成本和统一性问题。

　　后续的历史中，魔方也是发展了很多的版本，核心的模块拼装框架也没有大的调整。到现在为止，几乎承载了绝大部分非频道页的各类专题页面搭建。

　　以上2个产品，是第一阶段的代表产品，我印象中还有一些组货管理、push管理、资源位管理等，也都是在这个阶段做了一些比较系统的规划，这些产品都是解决操作效率和重复建设成本的问题。（PS：后续会单独起文章，来详细展开各个产品的设计过程）

　　这个阶段，其实也没有明确的中台部门定位，产品经理也就我一个人。

　　做事情的过程中，产品架构设计对我来讲没啥特别大的挑战，因为都是之前的底子。唯一不同点就是，上游多业务样本让我在沟通协作方面和推测判断业务后续动作方面，有了不一样的输入和思考。

　　（2）能力拼图

　　2018年开始，随着业务的不断尝试和扩展，一些促销玩法的产品需求也日益多了起来。

　　拼团、拍卖、秒杀等产品也在这个阶段诞生，同时也突破C2C单品交易的场景，做了购物车和满减等产品能力。

　　还有最关键的，围绕支付中心的建设，也进入了深层次建设期。我们不仅搭建了转转的本地账户体系，以及将清结算模块从各业务逻辑中剥离出来形成清结算中心，让整个平台的资金账务更加清晰。

　　小b角色的大量引入，也使得我们有了做电商后台PC端的机会。

　　2019年5月，随着平台入仓质检类业务的发展，我们开始筹备自研WMS，也随着公司新业务做了一些质检系统建设。

　　总之，在这个阶段，业务开始爆炸式创新，推动了中台在多个产品域（主要是资金流和实物流）有所行动。这个时期，团队大概应该有5个人左右，支付和仓储履约方向，分别是我们的2个大神CJZ和LJ在做操盘手。

　　过了2019年，其实转转中台在电商的三个流向，即信息流、资金流和实物流这几个维度完成了最基础的框架搭建。

　　而我也由原来的1个人，变为了6个人的产品团队。除了要学习之前不了解的专业知识外，也逐步承担了一些管理和规划属性的事情。

　　（3）项目工厂

　　从2019年年末开始，公司确立履约战略，就是以X2C、C2X为顶级主力业务形态，以B2B、平台生态、质检中台分别为供应链、流量、履约能力为中间支撑，中台横向能力为底层支撑的多级火箭模式。

　　在这样的背景下，整体的业务飞速发生变化，并且所有的模式几乎都引入了供应链履约环节，再加上交易模式的多样化，资金处理也会较为个性化，所以这个阶段的需求整体上就会变得复杂。

　　中台面向业务需求，沟通协作成本变大，项目数量变多，并且单项目实现周期变长，彻底变为了以项目实现为主要工作的节奏。

　　在这个阶段内，还发生了2个非常关键的事情，对中台的发展影响重大。

　　① 代号为【盘古】的项目发起与推进

　　这个可以说是整个中台历史上难度和持续周期都排第二位的项目。

　　大概背景就是，转转起源于C2C模式，所以在较早时候对商品体系的架构就会很薄弱。但是当公司转型以3C履约为主之后，商品类目属性和标品信息的标准和统一就变为了一个最大的难题。上游N多业务模式，大家用的信息，错综复杂，id体系也还不同，造成了商品发布转卖、价格体系等一系列问题受到阻碍。

　　于是乎，我们在2019年11月左右开始了底层类目体系改造和标品库的建设。这个项目纯开发很简单，大概用了1个月的时间，但是系统改造了底层需要让公司几十个相关业务系统都接入，就变为了一个非常损耗精力的事情。后续又遇到了我们与找靓机两家公司的系统融合，所以相当于又推进了一轮次类似的事情。整体算下来，这个项目的周期超过1年。

　　② 代号为【天衣】的转转&找靓机中台系统融合统一的项目

　　这个更加复杂，涉及到交易和履约全域近10条产品线的全方位系统融合与统一。

　　2020年6月底开始，中台基本全员产研奔赴深圳，开始了融合攻坚战役。大项目被拆分了无数个子项目，而其中相互关联，还涉及到新老系统切换、过渡等问题，整体收尾趋于完善也基本持续有一年时间。

　　在融合项目过程中，公司在业务端还有3C战役，业务需求其实一点都没有少。

　　中台在过程中，抗住了内外的项目压力，基本实现了目标。但在此过程中，我们的主要目标就变为了一个个功能的上线，对系统上线之后的运营工具完善性、系统稳健性和扩展性都少了很多的考量，为以后系统稳定性留下了隐患。

　　2019年末到2021年三四月份，中台基本都处于项目工厂的状态。我自己现在反思，如果融合之初，能够反向推动业务层融合时候先做减法可能结果就会变得不一样，但是反过来想，如果当时推动，好像环境因素也不太能支持。不过归根结底，我觉得自己在cover这个事情时候，没能跳出来用更高视野来看，确实是一个遗憾。

　　两地团队融合之后，团队变为了十几个人，两地办公，面对两地业务，在日常管理角度也多了更多的挑战与磨练。

　　（4）建立屏障

　　2021年5月份，这时候的中台，大概是以下这个样子：

　　业务与中台沟通需求，动不动就能有小10个产品经理在讨论，一个需求可能需要好多次讨论，业务整体反馈中台太复杂；很多新老系统过渡阶段，任何需求都绕不过这个历史包袱，再加上横向系统也有依赖关系，系统设计复杂度超高，有时候产品设计和技术设计考虑影响点很容易遗漏；系统复杂兼容逻辑多，动不动三天两头出线上事故，rd动代码都心惊肉跳的；中台有很多终端系统，面向有较多的用户使用，系统使用问题反馈占去了产品白天大部分的精力；中台是上下游中枢，因为缺少一些配套小工具，导致online问题处理时间占研发整体时间很大比重；中台沉淀的历史信息比较散乱，导致外部了解中台，甚至中台各域之间了解中台都有很大成本。总之，这个阶段的中台，内忧外患，团队士气非常低迷，外部压力也很大。

　　于是，在6月左右，团队发起了中台内建专项，我总结为其实是建立各种屏障层，一个是业务与中台之间，一个是用户与中台之间，还有就是中台各领域之间。

　　① 在业务与中台之间

　　有2个事情：

　　构建了一些平台化系统，将一些高频热点的问题系统化，减少触点；建立业务BP机制，中台派出核心童鞋1V1盯关键业务，交换信息并收口信息，同样也是减少触点。② 用户与中台之间

　　有2个事情：

　　online周复盘机制，再加上产品运营岗位的设立，将用户问题有了漏斗过滤，通过产品运营的sop和培训机制，把问题大幅降低，同时也节约了产研宝贵的时间；站在用户角度，体验线上产品和一线作业现场，主动发现问题并解决问题。③ 中台各领域之间

　　主要是做了系统边界解耦、部分关键系统重构、分散问题收敛等事情，让内部系统更加稳定和对接简便清晰。在这个阶段，我们把之前一年半的历史问题都系统化梳理并提出了结构化解决方案。经过近半年的攻坚，中台对以上描述的各个矛盾都有较大的缓解和改变。同时，更重要的是通过这次改变，建立了诸多的管理框架和机制，对后续发展有非常积极的作用。

　　我自己，也认为在这个阶段的多半年内，是我在转转5年内成长最快的一段时间，它让我在做事方法上有了更多思考，也让我在管理上前进了一小步。

　　这个阶段，到目前还不算结束，但核心矛盾和解法已经确定，后续需要持续的执行落地。

　　（5）回归产品

　　第四阶段建立屏障还没有结束，但其实目前来看，我们已然必须要踏入第五阶段了。

　　我把第五阶段称之为“回归产品”。为什么这么说？

　　过去的若干年内，其实中台的发展伴是随着业务非恒定态的变化而进行的，尤其是第二阶段和第三阶段的发展。但是从第四阶段开始，公司意识到系统的复杂其实根源是来自于业务模式的复杂，于是就开始做减法。

　　另外，整个公司也有了转向，开始在产品视角看业务发展，关注用户体验、用户心智等。

　　那么在这个阶段，中台的复杂度或系统能力，可能就会处于稳定态，不再继续增加。每个人关注的点，就会随着公司大的导向，开始倾注于终端产品的表现层打磨，进而联动驱动内部的一些变化，例如服务体系和履约体系的升级。

　　总之，在这个阶段，系统和项目的视角，不再成为主流，一切都必须要在产品价值层面拿到结果。而这个阶段，对产品经理来讲，可能是最有成长意义的，也会更有挑战性一些。

　　所有的好与不好，最终都会变得更好。一切，每个人都在路上~

　　以上内容，整体回顾了转转中台在过去5年多的发展概述。接下来，我会围绕着每一阶段以及每个阶段做的关键事情，陆续展开后续的文章，敬请大家关注。

　　PS：以上经验，更加是我在转转中台发展过程中得到的反馈与经验，仅供参考。每家公司情况不同，中台发展路线也不同，要灵活思辨。

　　作者：减形简远，微信公众号：产品杂谈（life_pm）

　　本文由@减形简远 原创发布于人人都是产品经理，未经作者许可，禁止转载。

　　题图来自Unsplash，基于CC0协议。