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

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

　　有比较宏观的中台概念介绍：《我做中台这5年：我的中台观》有我对转转做中台的实践回顾：《转转中台5年发展的整体回顾》有如何规划和落地中台的体系拆解：《中台规划深度解析：用户、机制、系统》有中台系统建设的方法思维：《中台系统建设之“屏障”思维》、《中台系统建设之“锁链”思维》有如何基于问题做精细化运营：《中台的精细化运营：“问题”反向驱动机制》有对中台定位和发展的思考：《不设边界，把中台做“厚”》这个系列，比较偏重于整体性的产品思维意识和框架多一些，打算写够10篇，基本上自己在中台这块的经验就算梳理得差不多了。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　优点：中台资源压力比较小；业务灵活度较高；缺点：所有上下游感知成本大；数据统一化和规则统一化会变得极度困难；其实，大家会发现这样做，缺点会大于优点。

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

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

　　优点：上下游感知和交互成本小；实现数据统一化和规则统一化；缺点：中台架构难度和产品挑战大一些；业务一定程度上依赖中台；但是，综合来看，优点是远远大于缺点的。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　找利益共同点。例如搞联合项目、业务需求+基础建设一起做、项目利益分配。以**之名。例如以用户之名、以风险之名、以老板之名（有时候需要用，但是要注意形式）。人际关系。例如要让协作方感受到被重视，团建庆功宴要记得感谢、日常的非正式沟通、建立你来我往的“人情”。影响力（口碑、威望）。让自身成为金字招牌，有口皆碑，大家相信你；也可以叫其他有名望的人过来站台。这里讲一个案例。我们支付中心最早启动和发展的契机，其实就是来自于一个146w重复打款的事故。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　题图来自Unsplash，基于CC0协议

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