三节课首页
为什么中台产品经理会火?| 一篇文章带你看中台前世今生
张成翼 三节课出品    2019-06-14 15:38:22

 

大约去年年底开始,中台的概念开始被广泛讨论。

 

这种讨论的大背景是,从18年下半年开始,各大互联网公司的战略转型,先是在腾讯业务架构变革,明确提出成立“技术委员会“,为各事业部提供支持,再是京东进行组织架构调整,宣布成立前中后台。在此之后,包括美团,头条,滴滴在内的一众互联网公司都提出要强化中台能力,打通内部数据等等。一时间,中台仿佛成了互联网公司的标配。

 

但与此同时,中台究竟是什么众说纷纭。

 

  • 在有些人眼里:中台就是技术平台,像微服务开发框架、Devops平台、PaaS平台,容器云之类的,人们都叫它“技术中台”。
  • 在有些人眼里:中台就是微服务业务平台,像最常见的什么用户中心,订单中心,各种微服务集散地,人们都叫它“业务中台”。
  • 在有些人眼里:中台应该是组织的事情,在释放潜能:类似于企业内部资源调度中心和内部创新孵化组织,人们叫它“组织中台”

 

这些理解都对,也都有不够准确或不够完整的部分。中台,作为一个还在被定义当中的概念,正处在一个大家都有感觉,但又难以被定义的状态,而且,可预见的是,这种相对模糊的状态可能还要维持相当长的一段时间。

 

而另一头,我们查阅了大量关于中台的文章时,能够发现,大家对于中台讨论的视角多偏重战略或组织架构层面。不得不说,这样的讨论视野开阔,也确实能够让大家从更高维度理解中台,但现实是,战略的制定是基于实际业务而制定的,更多情况下,企业战略的制定,是基于现实的业务发展状态与企业所处的行业环境共同影响下的妥协。

 

所以,类似的,中台这种起源于企业内部,并被大量企业认可,一定不是一个简单风口概念,更大的概率是因为公司业务在发展到某一阶段时,遇到瓶颈与障碍之后,为解决实际问题而提出的。

 

也因此,或许,我们从某个具体企业实践、探索中台的路径出发,看看他们是在怎样的背景和环境开始中台的探索,或许能让我更全面的认知到,中台究竟是什么?

 

为此,我们采访京东数科中台产品负责人邹毅,与他一起聊了聊中台对于业务的价值,中台产品经理的能力要求和工作实践。

 

并且,最为有价值的地方是,他与我们分享了很多京东在中台当中的业务实践。

 

接下来,我们会从,京东中台的实践起源,中台解决的关键的问题,建设中台的基本思路等角度出发,去和大家一起讨论,中台在实践当中的一些经验和思考。

 

相比起战略思考与对中台未来的前瞻,我们更加聚焦于具体的业务实践。换言之,比起搞清楚中台是什么,我们更想回答,作为一个普通的互联网人,中台到底和你有什么关系?

 

一、京东中台的实践起源

 

可能与绝大多数人想象不太一样,中台的产生,并非完全是自顶向下的战略设计,也并非是为了追随某种行业风口,而是随着公司业务高速发展、组织不断膨胀的过程中暴露的种种问题而产生的。 

 

就京东而言,提出中台的原因,也是因为京东发现过去几年的高速发展中遇到很多现实的挑战。这里,我们以京东商城为例,来看看京东开发中台的一个大背景。

 

京东以电商起家,在行业内地位仅次于阿里。在成长过程中,势必是在不断进行新业务的探索,仅在电商业务下,就有京东家电、京东超市、生活旅行、京东生鲜等业务线。另一方面,京东同时投资或收购了一号店、易迅等多家公司。 

 

除此之外,同一条产品线,可能还涉及到PC端、APP端、微信端、手Q端、小程序端等多种产品形态,每个产品形态下,都需要增加开发的工作量。因此,2010年开始,为了能够满足业务高速发展带来的问题,公司招募了大量的开发人员,来满足业务快速发展的需求。

 

但是,管理层很快就发现,招募的人虽然很多,人员素质也很优秀,但是人效比反而是下降的,业务部门+平台部门可能有几千人的产研团队,但实际的工作效率并不高。

 

这时,整个京东就在思考,如何能够提高京东内部的开发效率。

 

与此同时,同样是为了满足业务需求,京东商场在开发过程中,业务系统与基础系统是高度耦合,所以,当新业务产生之后,想要使用京东已有的系统,很难实现,必须要重新开发。

比如说,「活动详情页搭建」这样一个小功能。作为电商平台,日常活动都需要搭建专门的详情页,并且,这样的功能在大多数业务场景下,都是适用的。

无论是在京东家电还是在京东超市,618的活动规则和内容可能不一样,但活动详情页的搭建,没有本质差别。

 

在这样的依情况,一个独立的,可复用的活动详情页搭建工具,就非常有意义,新产品上线,需要进行活动详情页的制作,不再需要专门开发一个系统,直接套用模板就可以了。

 

可现实是,很多时候,即使是这样一个小功能,京东也是将其直接在核心系统基础上开发,这样的好处是,开发成本低,上线速度快,很快的响应了业务需求。

 

但是,当别的业务部门想要再次使用这个功能的时候,发现这个功能和他们的基础系统高度耦合,自己没法直接用,得重新再搭一个。

 

这样一而再再而三,整京东商场就出现了很多个功能类似但高度耦合的小工具,整个核心系统的效率非常低。

 

这里,我们只是举了一个小例子。把这个场景放的更大。对于京东商城来说,虽然他们有很多条业务线,也有很多个产品形态。销售的商品种类千差万别,但是其产品的核心逻辑,都是电商产品。其关键点,无非这样几个关键业务模块:订单、商品、库存、价格、仓储、物流等等。对于这样的电商平台,基本都符合大部分功能可复用,小部分功能需定制化开发的特点。

 

显然,让每个业务线都从0到1开发一套系统势必是对资源的浪费,而且,由于每个业务部门的开发实力不尽相同,最终开发出来的功能,也良莠不齐,这时候,对于用户来说,体验也不够好。

 

同时,由于大量的重复开发,并且整个系统没有很好的规划和架构。京东商场的整个系统还遇到了另一个问题,就是系统过于复杂,以至于无法调整。

 

由于很长一段时间都是优先响应业务部门,整个系统都是能打补丁绝不重构,这样,到2017年左右,整个系统已经复杂到难以调整的地步。能打补丁就绝不重构,效率很低。

 

除了内部环境的变化,外部市场的变化,也让京东意识到需要一个部门或团队,专门对于这些复用性极高的产品功能进行开发,并对整个核心系统进行管理。

 

京东过去几年,开始在东南亚国家进行业务布局,相继在多个国家成立了电商、金融公司。这些业务在落地时其实也遇到了类似的问题。

 

对于电商业务而言,就像我们刚刚说的,他的核心业务流程不会有太大的差异,你究竟是在中国批发商品进行售卖,还是在泰国批发商品进行售卖,电商系统的内核并没有太大差异

 

而且,抛开电商业务的特点不谈,许多业务流程也是高度标准化,可复用空间很大的。

 

比如说:ERP系统、CRM系统、人力资源系统、财务系统、客服系统等等这些系统都有了很成熟的解决方案,与业务之间的配合也已经非常完善,并且这些系统也不是当地业务的主干流程,但开发工作量非常大。

 

另一方面,京东前几年在泰国、印尼成立的电商公司,这些市场的规模并不大,但是,这个市场当中,除了本地已有的电商平台,一些别的电商巨头也已经在东南亚开始投资,为了能够更好的应对市场竞争,就必须确保产品有足够的竞争力,刚刚我们提到的所有的模块和功能都需要有。

 

但是,实际开发的过程中,大家才发现。因为京东商场自己的平台太过复杂,很难直接复用到新的平台,到最后,很多功能其实相当于又重新开发了一遍并没有想象中的那样高效。

 

比如说,京东在泰国的商城,大家都预计能够大约有三个月或者半年完成工作,但实际进行下来,由于整个系统需要重新开发,实际上整个泰国站的开发工作又用了整整一年的时间。

 

新业务开拓的速度下降,也让京东意识到,必须要能够建立一个独立的部门和产研团队对基础和底层的系统,统一来进行规划和设计。这也是2018年京东商城提出中台战略的大的业务背景。

 

从京东商城的案例当中能够看出来,这里面其实存在很多问题和矛盾冲突。这些问题有一个很基础的大背景是,企业内部的业务发展状况,以及由于一些历史问题导致效率整个放缓,如果想要能够在接下来的发展中持续保持战斗力,承接更大规模的服务体量和业务增速,这些问题就必须要回答和解决。

 

进一步,我们抽象京东商场发展中存在的问题是,能够看到,大约是两类问题,

 

一类是,许多业务需求或功能需求高度类似,通用化程度很高,但是由于没有专门的团队负责规划和开发,大量的系统重复开发、重复建设,导致复用性低、效率低、产研资源浪费、用户体验不统一。

 

另一类是,早期业务发展过程中,为了解决一些当下的业务问题,垂直的/个性化的业务逻辑与基础系统耦合太深,由于没有平台性质的规划,横向系统之间、上下游系统之间的交叉逻辑也非常多,这样导致在新业务、新市场的拓展过程中,系统没法直接复用,甚至没法快速迭代。

 

这两类问题,在软件开发领域,有专门的名称,叫做“重复造轮子”和“烟囱式架构”,这两类问题本质上是企业在发展过程当中,为了解决当下的业务问题,快速上线了很多功能,而欠下了许多技术债,当企业进入成熟期之后,发现这些问题的存在,严重影响了企业的运行效率和运营成本。

 

如何能够机制化,产品化地解决这些问题,能够更好地通过产品的形式,将企业内部具有很强的通用性的数据、功能、产品甚至经验进行统一规划和开发,进而更好地帮助前台业务部门更多地关注业务,提高业务运营效率,进而提升企业竞争力,是企业开发中台的基本出发点。

现阶段,大多数提出中台战略,或者建设大中台的公司,大多数也有类似的困境,业务高速发展多年,许多问题积重难返或者大量在解决“重复造轮子”的问题,中台这个概念,很多情况下是因为契合了大公司业务的发展的情况,而被大家广泛认可。

 

二、中台是为了承接业务大规模增长而修炼的能力

 

前面的内容我们讨论了京东商城、提出中台的一个业务背景,这个案例似乎给了我们一种感觉,中台是只有大公司才能做的事情。因为毕竟只有大公司在会有这种多条业务线,需要大量通用功能的场景,也只有只有大公司有能力拿出如此大的资源打造个中台。

现实情况也如我们所说,很多公司的中台业务,实际业务发展到一定阶段,进入一个瓶颈之后,为了能够应对接下来的问题,才一点一点从内部开始推动解决之前的问题。

 

但这其实只是中台建设的一个层面。

 

中台作为一种产品设计思路,或者系统架构思路,并不受限于公司的规模,理论上讲,任何一家即将或者正在面临业务高速增长的状态时,都很值得利用和借鉴中台的思路,将目前业务当中大量可复用的功能和场景进行梳理,为业务的高速增长做好准备。

 

这在中小公司当中,是有现实意义的。

 

对于很多中小公司,当他们走出生存困境,进入到高速发展阶段时,会遇到很多的问题,但大概率会遇到的一个问题是,过往的业务模型,产品能力很有可能没法完全承接住大规模用户增长带来的压力。

 

而当你具体到每个用户的时候,你又能发现,他们遇到的问题你之前都遇到过,只不过,因为一下来的太多,你没法像过去一样提供达预期,甚至超预期的服务时,对方就会产生不满。

 

如果你这时为了临时解决一个问题,快速上线一个功能,也不是不可以,只不过,很有可能你的解决方案会不断带来新的问题,最后陷入到功能太过复杂,以至于积重难返的地步。

 

所以,在有可能的情况下,公司将一些大概率长期有价值的功能,专门模块化,进行开发和优化,确保即使业务规模进一步扩大,也能够满足业务需求。甚至,随着能力或方法论的不断优化,甚至有可能某一天成为整个行业的方法论。

这个过程,就很像是在高速飞行过程中修飞机一样。一方面,机翼已经千疮百孔,摇摇欲坠,另一方面,发动机还在运转,你还能往前飞,但你知道,如果再进入到下一场战斗,你不见得还能确保飞机不会坠落,所以,必须抢在下一次战斗前把飞机修好。

 

随着业务的发展,你对飞机的要求,也不仅仅是修好,可能会希望,能够提前预防一些问题。或者,知道你的飞机哪里战斗力最强,就把哪里做到最好。或许,就能够回避之后的一些问题。

 

这或许是中台这个概念,对于中小公司内部产品规划的一个启发。

 

三,中台哪里难?

 

之前的内容,我们其实花了很大的篇幅来讨论,为什么会有中台,中台解决怎样的问题,以及中台适用怎样的场景。

 

但是,具体到业务场景当中,中台产品经理又在做什么事情,解决怎样的问题?如果想要成为一名优秀的中台产品经理,又会遇到怎样的困难和挑战?

 

就邹毅老师的经验而言,中台产品经理面对很多挑战,其中,最主要要是最困难的挑战,主要集中在这样两个方面。

 

一方面,是思维的差异。

 

很多产品经理并不是从一开始就从事中台相关的事宜,也不是一开始就有中台这样的定位,更多情况下,他们是从前台业务部门,或者以业务为导向的产研部门转型到中台产研部门。

 

这时,其实要面临很大的思维方式、做事方法的转变。

 

在业务部门或者以业务为导向的产研部门,最核心的目的就是达成业务目标,要求你速度足够快、功能高效地解决当下的业务问题,当前业务发展的效率是最关键的。

 

至于说,这个功能将来有没有可能适用于别的场景,有没有可能解决别的问题,这个问题实在是没那么重要。

 

但是,对于中台不能如此,

 

对于中台产品经理来说,必须思考的问题是,这个功能在现在或者将来能满足多少业务场景?如果将来有新的业务出现,是不是能够复用?或者说,需要做多大的调整才可以复用?甚至于,这个功能有没有可能对外输出,提供SaaS化的服务。

这些问题,是中台部门需要思考的问题。

 

这是思维上的差异。

 

另一方面,是环境的变化。

 

当你在业务部门的时候,响应业务是相对轻松的,但是,在中台部门,响应多个业务,就没有那么轻松了。

 

就拿需求调研为例。

 

在业务部门或以业务为导向的产研部门的时候,你只要和对接的业务人员沟通清楚需求就OK了,毕竟,你只要了解这一个或对应的多个部门的业务需求即可,业务目标相对比较明确。

 

但是,当你需要响应多个业务部门的时候,就没有那么容易了。

 

你会发现,同样一个需求,A部门的流程和B部门流程完全不同,或者,流程是相似的,但到具体细节的时候,却有很大差异。

 

更可怕的是,同样一个问题,由于业务的发展阶段不同,对于问题的态度也全然不同:有的部门业务已经非常成熟,自己流程也很清晰,所以不太希望你来调整他们现有的流程;但是,有的部门还处于探索期,还没有遇到你提出的问题,可能压根就不理你……

 

这时,对于中台产品经理的挑战就非常大。

 

他们可能会将大量的精力耗散于不同部门之间的沟通协调,反复对同一个需求进行确认,很长时间没有明显突破。这个时候,就要求中台产品经理有很强的沟通、协调和协作能力。

 

并且,因为他们接下来要做的解决方案,是要服务于多个业务,这个时候,需要中台产品经理有很强的逻辑思考能力,看到不同需求之间的共性需求,并提炼出一个产品化的解决方案。

 

甚至于,对于一些尚未遇到这个问题的业务部门,可能还要帮他们前置地思考解决方案。

 

这又很要求产品经理的逻辑思考和抽象思考能力。

 

既需要沟通协作的软技能,又需要逻辑抽象的硬思考,这可能才是中台产品经理最有挑战的地方。

虽然有挑战,但是也不见得没有方法。最后,我们就简单讲一讲关于中台建设的产品经理的一些思路。

 

最后

 

当然,对于中台产品经理来说,刚刚我们提到的内容,也只是帮助中台产品经理,对于中台产品这个岗位所要面临的挑战和工作,能够有一些初步框架性的理解。

 

但是,在实际业务场景当中要解决的很多复杂问题,受限于篇幅,我们还没有详细讨论。

 

对于中台产品而言,他们的能力要求其实跨越非常大。一方面,需要极强的逻辑思维和战略分析能力,能够看到业务当中的关键流程,理解业务接下来的发展方向,并将其转化为产品功能,与研发一起实现。另一方面,又需要极强的沟通和交流能力,能够在与多个业务线,需求、背景、想法各不相同的相关方一起,推动完成相关功能的实现。

 

这背后,就是技术,也是艺术。

 

某种意义上,能够掌握掌握这两种似乎有些对立思维,并能够灵活运用,可能距离成为一个优秀的中台产品经理,就不太远了。

评论(2)
阅读(5991)
文章评论

请您,再发表提问