5年中台实践的7条经验

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

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

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

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

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

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

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

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

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

5年中台实践的7条经验

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

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

一、发展思维

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

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

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

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

1. 规划篇

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

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

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

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

2. 机会篇

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

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

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

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

……

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

5年中台实践的7条经验

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. 标准与个性化

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

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

5年中台实践的7条经验

这样的架构,有如下优缺点:

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

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

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

5年中台实践的7条经验

中台介入的架构,优缺点如下:

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

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

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

2. 多域串联与跨域转换

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

5年中台实践的7条经验

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

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

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

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

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

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

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

5年中台实践的7条经验

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

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

四、转移矛盾

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

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

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

5年中台实践的7条经验

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

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

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

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

五、善于借势

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

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

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

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

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

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

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

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

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

六、信息机制

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

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

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

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

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

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

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

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

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

5年中台实践的7条经验

七、沉淀资产

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

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

5年中台实践的7条经验

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

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

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

1. 系统角度

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

5年中台实践的7条经验

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

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

2. 机制角度

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

5年中台实践的7条经验

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

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

3. 人才角度

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

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

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

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

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

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

5年中台实践的7条经验

本文作者 @减形简远 。

版权声明

本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!

相关文章

立即
投稿

微信公众账号

微信扫一扫加关注

返回
顶部