这个最早由阿里在2015年提出的“大中台,小前台”战略中延伸出来的概念,最近在国内大热。阿里、腾讯、百度、京东、美团、滴滴等一众互联网巨头,从去年到今年,接连开始组织架构的调整,意图建设中台......
而上周一个阳光明媚的下午茶时间,我正狗啃着手抓饼。老板忽然把我们一班人拉进会议室,语重心长跟我们说 —— 我们要搞数据中台!
虽然一个会议下来,连他都没说明白“中台”到底是什么?但秉承不懂就少说,我苟了过去...直到吃完月饼,我们来对比下有无“中台”的情况
项目有很多对内/对外/辅助,但无论项目内部的如何复杂,大体的结构都是 “用户前台”和“管理后台”。
面向用户、直接产生交互,页面注重设计/交互,与服务端产生数据交换引导用户完成业务流程. 比如:
面向运营人员的配置管理系统,后台为前台提供了一些简单的配置。比如:
用户前台、管理后台、用户之间的关系如下:
传统模式下,项目迭代周期基本以月、季度为单位。长开发周期也意味着需求一旦变动,要么996,要么交付推迟
而且项目之间相对独立,许多项目都在重复发明相同的“轮子”。让项目越来越臃肿的同时,也让开发效率越来越低。
但现实是互联网进入下半场,企业竞争越来越激烈的今天。产品项目不能够快速迭代、低成本试错的后果,就等同让企业处于一定的竞争劣势。
为了解决以上问题,而应运而生的是“中台”概念
Supercell,失败从来不是可耻的记录,而反倒是一种进步的动力。一款游戏推出遭到失败后。其管理者的反应是“太好了,这款游戏失败了,证明了我们剔除一条错误的道路”。独特的“庆祝失败”根植于其企业文化之中,潘纳宁认为:“我们是在从失败中吸取教训的基础上建立了这家公司。失败得越快,我们学习得越快,也会变得越好”。
失败时成功之母,能够真正做到从失败中获取需要的信息,学习如何成功
Supercell采用的是亚马逊的aws服务,他们每天需要处理万亿字节的数据,这些日志将会被用来改善游戏体验。充足且统一的公共业务模块,辅助团队避免重复劳动,专注于玩法、游戏体验创作即可快速堆砌产品。提升单个员工价值的同时,也降低了试错的成本
300人的团队被分成若干个小团队,5-7个游戏开发者组成一个小团队,开发自己的游戏,以最快的速度推出公测版,检测游戏受用户欢迎的情况。这些小团队又被称为“细胞”(cell)。团队小意味着试错成本不会太高,时间和方向也可以及时调整和转变,以满足高速变化的市场需要,对战机的把握更加敏捷,一旦发现正确目标,就可以全力投入扩大战果
他们会给公司内部所有人分享所有的信息。每天早上,所有人都会收到邮件,包括每款游戏的详细数据,工作环境非常透明化。游戏表现好,所有人都看得到,如果表现不行,所有人也都知道。这样一来,会形成压力比较大的工作环境,但对于合适的人来说,这也是他们努力的动力。
往技术层面说,中台解决的问题是 —— 多项目 且 项目相对独立,导致需要重复造轮子,如:文件上传 / 订单模块 / 支付模块 / 搜索模块...引起的研发周期长,程序员996了都不能灵活应对业务变化 的情况
往业务层面说,中台解决的是 —— 因为项目相对独立,技术重复造引起的 研发周期长 / 面对市场需求总是慢半拍(不灵活) / 试错成本高 / 不利于创新
说了那么多,举个例子:
他们开发出的游戏看上去风格迥异,却存在许多共同之处。在业务上,共通的东西包括支付系统、用户系统等等,在技术上,共同的东西包括游戏引擎,内部开发工具等等。而这些共通的资源,都可以由一个强大的“中台”来提供:
中台的架构思想改变的不只是项目结构,也影响了研发团队的组织形式。SuperCell公司把这种高效的组织形式称为“部落”。
紧随其后,国内互联网公司也纷纷开始了各自的中台战略。阿里巴巴提出了“大中台,小前台”的战略:
图中,阿里巴巴许多产品线的共通业务经过下沉,形成了中台的各种业务中心,而Aliware则是阿里巴巴的技术中间件平台,为各大业务线提供技术支持。
以上就是中台概念的具体含义。
“中台概念”往小地说,就是“微服务”。但中台需要使用 产品管理 的方式来对待。因为中台对外提供的服务需要不停的迭代,适应业务的需求,而不是等业务来提需求。对,技术人员也要懂业务。
至于 产品 和 项目 管理有什么区别?这你得找产品交流下心得、切磋下武艺~