本文是作者做中台5年总结的7条经验，偏重于整体性的产品思维意识和框架。主要从发展思维、平衡能力、系统设计、转移矛盾、善于借势、信息机制、沉淀资产这7点进行总结梳理，希望能给你带来帮助。
过去一段时间，我已经累计写了《我做中台这5年》系列文章共计7篇。这里面：
这个系列，比较偏重于整体性的产品思维意识和框架多一些，打算写够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协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。