本文是作者做中台5年总结的7条经验，偏重于整体性的产品思维意识和框架。主要从发展思维、平衡能力、系统设计、转移矛盾、善于借势、信息机制、沉淀资产这7点进行总结梳理，希望能给你带来帮助。

过去一段时间，我已经累计写了《我做中台这5年》系列文章共计7篇。这里面：

• 有比较宏观的中台概念介绍：《我做中台这5年：我的中台观》
• 有我对转转做中台的实践回顾：《转转中台5年发展的整体回顾》
• 有如何规划和落地中台的体系拆解：《中台规划深度解析：用户、机制、系统》
• 有中台系统建设的方法思维：《中台系统建设之“屏障”思维》、《中台系统建设之“锁链”思维》
• 有如何基于问题做精细化运营：《中台的精细化运营：“问题”反向驱动机制》
• 有对中台定位和发展的思考：《不设边界，把中台做“厚”》

这个系列，比较偏重于整体性的产品思维意识和框架多一些，打算写够10篇，基本上自己在中台这块的经验就算梳理得差不多了。

目前已经构思或准备好的有2篇：

一篇打算将之前做过分享的《5年中台实践的7条经验》写成文字版，也就是大家即将看到的本文内容。

另一篇打算写下人，介绍下中台产品的能力模型，名字暂定为《中台产品经理的“十字型”能力模型》。

最后一篇，还没有想好，以后想到了再说。

另外，这个系列，是基本没有涉及到具体产品域设计经验和方法的，例如订单、支付、促销等等这些专业领域该怎么做。后边有机会再看要不要写。

正文开始。先看一个整体框架：

以上7条经验，基本就是我结合自己过去的实践，总结出来的比较适合中台发展落地的一些经验。

接下来，我们逐一介绍下。

一、发展思维

我认为发展的核心模型是由3个要素组成，分别是规划、机会、资源。

发展，就是自我在周遭环境下，不断洞察机会，结合现有资源，规划并落地的过程。

机会意识很重要，它基本决定了我们能否做有价值的事情，而这个机会宏观上来自于公司战略，隐藏在跟用户、跟业务、跟兄弟部门、跟同事上下级之间的连接中。

规划落地，在经验的前提下，结合洞察到的机会，再根据资源，确定目标与节奏，最终拿到结果。

1. 规划篇

我觉得规划分为3个步骤：

第一步：“看见”。可以是别人做过的，自己做过的，也可以是推导出来的。

第二步：蓝图。就是框架搭建、核心路径和指导原则。

第三步：不断纠偏。大规划拆解小规划，阶段性诊断当前，及时纠偏规划。

2. 机会篇

聊到机会，其实大家更多会提到需求。

但如果发展业务过程中，你只是被动的等待需求，或只是看到显性的需求，那你基本上就不会有机会。

更多的机会，其实潜藏在冰山之下，例如：

• 对战略的思考
• 跟业务的密切沟通
• 用户和客服的反馈
• 内部复杂/重复/不通畅的事情
• 新技术的关注

……

从2016年到2021年，转转中台都会紧贴公司战略重心的变化，敏锐洞察到机会。然后做出及时判断，适当调整阵型、聚焦资源，然后支撑业务发展的同时，做了一个个中台化的沉淀。如下图：

3. 资源篇

怎么看待资源，我的观点其实很简单，其实就像投资一样，你如何赚到更多的钱。

用财务模型类比，我们做的无非就是几件事情（注意以下收入、支出并不真的表示是钱，可以理解为价值）：

1. 增加资产，然后资产会不断自增产生收入。例如系统化、模板化的工具，就可以产生复用性，那么下次不用花任何成本就能支持需求，相当于带来价值。
2. 直接提升收入。例如中台也可以直接做一些增收的项目，例如营销工具、低费率通道等等。
3. 降低支出。例如没有做到很好中台化，造成重复性的资源投入或设计不合理造成的返工，那就是变相增加支出了。
4. 降低负债。例如有些中台化过度设计，做了太多较长时间都用不上的冗余功能，相当于我们有了一笔负债。

所以，把资源当做自己的钱来认真对待，中台产研要合理使用资源。

1. 需求抽象转为系统产品，避免重复消耗资源；
2. 开拓新的业务能力，直接带来收益；
3. 产品架构合理，注重扩展性，不浪费研发资源；
4. 产品优先级拆分，合理调配当前资源，兼顾当前与未来。

二、平衡能力

平衡的决策，是一个非常复杂的事情。

决策时，你面向的用户是广义的，不局限于产品用户，而是和产品过程中的所有利益方。然后结合环境各种变量，得出一个最优解。

另外，平衡并不一定都是体现在每一个单点决策上，更多时候是在整个周期内，这时候平衡能力要看全局思维和节奏感。

也就是局部与整体的平衡、短期与长期的平衡。

1. 局部与整体

这里讲个工作中的一个案例：

公司2个业务，都需要对C2B和B2C两段交易做一个模式衔接，一个叫寄卖，一个叫以旧换新。

最终，寄卖模式实际上是由中台统一封装提供给上游业务的，但以旧换新确实让业务自行封装使用的。

局部来看，对以旧换新业务方来说，他们的成本一定是高的，除了本身开发之外，还需要对中台现有能力去做熟悉。

在整体公司来看，寄卖模式是一个相对成熟的模式，肯定不属于mvp的概念，并且当前直接就是多品类都要使用的场景；中台去介入，从ROI角度来看，成本是小的。

但对以旧换新来讲，业务属于尝试的阶段，并且很多人看法不一致，单量上线预估也比较一般，品类也有限定；在这个情况下，考虑ROI，中台做这个就相对不太合理。

再讲另一个现象，就是非核心业务的困境：

中台变为各业务中枢的情况下，非核心业务很难获取到资源。

如果完全站在ROI角度来判断资源投入，业务对中台的满意度将会降低至负值。

这时候，有2种建议的做法：

要不保留小的固定带宽，顺序排期，让业务看到希望；要不就是在固定周期内要给予一定的需求支持，哪怕支持一个小的需求。

这种情况下，对非核心业务，尽可能保持多一些“感情”沟通。

2. 短期与长期

讲一个关于商品体系升级项目的案例：

转转历史上，是以C2C起家的，所以整个商品结构设计的没有那么完善，用户发布C2C商品，商品相关的信息没有太多需要结构化的约束，更多就是标题、描述这些文本。

但是随着公司越来越重视服务和履约，就慢慢发展成为了对垂直类目的深度介入，有C2B回收也有B2C卖场，这时候无论是价格、质检还是搜推，都强依赖商品类目属性体系的完备。

做升级项目的时候，已经是2019年了，距离最早C2C底层设计已经过去三四年，过程中一直没有产品介入，都是技术在打补丁，终于到了扛不住的时候。

于是，我们终于下了决定，来个破釜沉舟的重构，代号【盘目】。

盘古项目，先推动了转转内部业务拉齐技术和内容体系，后续又恰逢转转与找靓机融合，总历时将近10个月，涉及到公司所有部门；

过程中，产生的技术难度和业务压力为中台历史所有项目之最。

这个底层改动项目，中台面临的协作压力（业务在短时间内的不理解）是非常高的；但是，为了长期的价值，就必须果断做决策，否则后边会更加痛苦。

当然，这个例子也让让大家意识到，中台系统架构，一定要具备前瞻和扩展预留，否则后续将会以数十倍资源进行弥补。

三、系统设计

1. 标准与个性化

标准与个性化，其实是一个灵活性的问题。

在系统设计层面，很多人的做法，会直接把个性化交给业务，然后造成中台+业务，共同面对其他上下游，如下图：

这样的架构，有如下优缺点：

• 优点：中台资源压力比较小；业务灵活度较高；
• 缺点：所有上下游感知成本大；数据统一化和规则统一化会变得极度困难；

其实，大家会发现这样做，缺点会大于优点。

那还有另外一种架构，是中台作为一道屏障的方案，如下图：

中台介入的架构，优缺点如下：

• 优点：上下游感知和交互成本小；实现数据统一化和规则统一化；
• 缺点：中台架构难度和产品挑战大一些；业务一定程度上依赖中台；

但是，综合来看，优点是远远大于缺点的。

所以，也比较推荐中台作为一道屏障，然后让业务有限灵活，确保全局是最优的。

2. 多域串联与跨域转换

一个需求，整体在中台的实现是比较复杂的，一般都会跨域在5-10个；而在每个域内的设置内容，都可能多达数十项；并且中台各域之间，还存在依赖关系。如下图：

在项目中，经常会发生漏配错配的情况，并且沟通协作成本很高，测试周期也比较长。

所以，在中台，做一些大项目，“老人”会更有优势，因为他们会更有经验一些。

那一个组织的发展和稳定，肯定不能建立在纯靠个人经验上。

我们经过不断摸索，逐渐将一个需求的实现，在中台系统化实现了。

即可以通过像业务线这样的主键，贯穿所有产品域的各个功能点，并且功能点已经尽可能把代码逻辑变为了配置化。

这个之前《锁链思维》那篇文章已经讲的比较清楚，这里不再展开。

各产品域的交流，也可以通过统一的度量衡系统进行转译。如下图：

系统化之后，项目效率大大提升，基本很少发生漏配错配，系统化天然节省了项目化的测试成本。

并且这样的“经验”，可以变为不依赖人的系统，大大提升了稳定性。

四、转移矛盾

中台作为项目实现的中枢，必然会高频遇到资源的矛盾。

每个业务在中台的预期，都希望是最高优先级，但是资源永远是有限的，并且大概率会投入到重点业务。

这时候，得不到更多支持的业务大概率对中台满意度是不高的，有时候再加上信息单向传递，很容易激化矛盾。

面对这种情况，客观上就2个解法：一是中台加人，而是业务排出来优先级，中台按照顺序来做。

而最关键的是，这2个操作，都一定不能是单点的沟通和判断。

尽可能是拉齐相关利益方一起达成共识，例如从公司层面来敲定全部业务几个事情的重要优先级，这样就不再是中台自己来选择优先级，所有业务也都更容易接受。

同理，增加中台资源，这个涉及到人员招聘预算，站在老板角度，也一定必须是业务需要中台增加资源为前提。

五、善于借势

产品经理要想改变世界，我觉得协同能力至少可以排在第二位。

正确重要的事情，更多时候大家不一定能认知到，尤其是长期利益与短期利益冲突的时候。

没有“实权”，必然需要靠协同能力，协同要讲究各种借势来实现。

根据我自己经验，能够产生借势的4种方式：

1. 找利益共同点。例如搞联合项目、业务需求+基础建设一起做、项目利益分配。
2. 以**之名。例如以用户之名、以风险之名、以老板之名（有时候需要用，但是要注意形式）。
3. 人际关系。例如要让协作方感受到被重视，团建庆功宴要记得感谢、日常的非正式沟通、建立你来我往的“人情”。
4. 影响力（口碑、威望）。让自身成为金字招牌，有口皆碑，大家相信你；也可以叫其他有名望的人过来站台。

这里讲一个案例。我们支付中心最早启动和发展的契机，其实就是来自于一个146w重复打款的事故。

这个风险非常大，所有人都无法再承受第二次的事故出现，所以之后我们非常自然顺利地推动账户、结算等支付系统化项目的落地。

过程中，我想没有人会对此产生“阻碍”，因为以风险之名，没有人愿意承担这个责任。

当然，产品要想成事，不能只是在搞这些“为人处世”的借势，自身有真本事是基础，万不可本末倒置。

六、信息机制

中台作为中枢，上游业务有很多，中台子域也有很多。

对外，中台承接较多系统和应用产品，线上线下问题咨询常态化；对内，中台纵深逻辑复杂以及横向联动性强。

所以在这个环节，信息交集必然是最多的。

如果没有好的信息机制，特别容易造成业务与中台对接效率低、中台内部效率低、内外部满意度下降的结果。

2020年左右，我们就遇到过这样痛苦的状态：

企业微信上，产品同学满屏的99+消息，连看消息都是问题，别说一个个处理了。

还有，一个大项目，中台产品会被各种会议沟通所牵绊，根本没有太多产品设计和思考的时间。

最后，经过我们不断的尝试和迭代，算是找到了业务与中台，以及中台内部信息交换传递的有效办法。如下图：

PS：这个信息机制更详细的介绍，大家可以参照之前《屏障思维》那篇文章。

七、沉淀资产

做中台，除了日常一个个项目和能力交付之外，中台到底能给一个组织留下什么呢？

我觉得需要从以下3个方面来考虑：

从系统、机制再到人，对人的依赖依次升高，靠谱性依次降低。

沉淀资产的角度，我们应该更多转化为系统，其次是各类机制，最后才是依赖人的经验。

当然，这里并不是表示人不重要，而是单纯从资产沉淀角度考虑人的不可控性，以及人培养的ROI。

1. 系统角度

除了项目，我们需要更多在中台平台化角度多做沉淀。

根据实践经验，我将中台平台化分为了4个系统，分别是开放平台、规则中心、配置中心、全域查询。分别对应能力标准化、逻辑规则化、变量配置化、数据链路化。

具体的详述，请大家参照《屏障思维》文章。

2. 机制角度

我们将用户分为了几大类，分别是业务用户、终端用户、团队用户，分别对应需求、使用、价值体现。

针对不同的用户，会有对应的机制在运行。

机制的有效运行，确保了各类信息的输入和输出，确保整个团队组织有条不紊。

3. 人才角度

中台在发展的过程中，必然会内部横向扩展，只有这样才能保证多业务接入时候边际成本降低。

过去中台的重点项目，平均中台投入占总比例均值大概在70%左右，基本上都会涉及到5个产品域以上。

那么作为中枢的中台产品经理，必然会变为跨域乃至全域的高手。并且他们在沟通、抗压、组织协调、业务敏感度、执行力层面，也会更加出众。

这样的人才，对公司其实是一个宝贵的财富，在公司不同发展阶段，是可以输出到业务或创新部门的。

后续，我也会单独写一篇介绍中台产品能力模型的文章，到时候我们再详细展开。

到这儿，对7条经验的已经介绍完毕。对提纲做了一张图，方便大家记忆。

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

题图来自Unsplash，基于CC0协议

该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。

    

使用无须实名的阿里云国际版，添加 微信：ksuyun  备注：快速云！