故事的开始

这个最早由阿里在2015年提出的“大中台,小前台”战略中延伸出来的概念,最近在国内大热。阿里、腾讯、百度、京东、美团、滴滴等一众互联网巨头,从去年到今年,接连开始组织架构的调整,意图建设中台......
而上周一个阳光明媚的下午茶时间,我正狗啃着手抓饼。老板忽然把我们一班人拉进会议室,语重心长跟我们说 —— 我们要搞数据中台!
虽然一个会议下来,连他都没说明白“中台”到底是什么?但秉承不懂就少说,我苟了过去...直到吃完月饼,我们来对比下有无“中台”的情况

项目现状

项目有很多对内/对外/辅助,但无论项目内部的如何复杂,大体的结构都是 “用户前台”和“管理后台”。

用户前台

面向用户、直接产生交互,页面注重设计/交互,与服务端产生数据交换引导用户完成业务流程. 比如:

管理后台

面向运营人员的配置管理系统,后台为前台提供了一些简单的配置。比如:
用户前台、管理后台、用户之间的关系如下:
传统模式下,项目迭代周期基本以月、季度为单位。长开发周期也意味着需求一旦变动,要么996,要么交付推迟
而且项目之间相对独立,许多项目都在重复发明相同的“轮子”。让项目越来越臃肿的同时,也让开发效率越来越低。
但现实是互联网进入下半场,企业竞争越来越激烈的今天。产品项目不能够快速迭代、低成本试错的后果,就等同让企业处于一定的竞争劣势。
为了解决以上问题,而应运而生的是“中台”概念

中台概念的先行者 Supercell

容忍失败,甚至为失败喝彩

Supercell,失败从来不是可耻的记录,而反倒是一种进步的动力。一款游戏推出遭到失败后。其管理者的反应是“太好了,这款游戏失败了,证明了我们剔除一条错误的道路”。独特的“庆祝失败”根植于其企业文化之中,潘纳宁认为:“我们是在从失败中吸取教训的基础上建立了这家公司。失败得越快,我们学习得越快,也会变得越好”。
失败时成功之母,能够真正做到从失败中获取需要的信息,学习如何成功

深度利用云计算/微服务等技术,升级单个员工价值

Supercell采用的是亚马逊的aws服务,他们每天需要处理万亿字节的数据,这些日志将会被用来改善游戏体验。充足且统一的公共业务模块,辅助团队避免重复劳动,专注于玩法、游戏体验创作即可快速堆砌产品。提升单个员工价值的同时,也降低了试错的成本

小而精的团队

300人的团队被分成若干个小团队,5-7个游戏开发者组成一个小团队,开发自己的游戏,以最快的速度推出公测版,检测游戏受用户欢迎的情况。这些小团队又被称为“细胞”(cell)。团队小意味着试错成本不会太高,时间和方向也可以及时调整和转变,以满足高速变化的市场需要,对战机的把握更加敏捷,一旦发现正确目标,就可以全力投入扩大战果

信息共享

他们会给公司内部所有人分享所有的信息。每天早上,所有人都会收到邮件,包括每款游戏的详细数据,工作环境非常透明化。游戏表现好,所有人都看得到,如果表现不行,所有人也都知道。这样一来,会形成压力比较大的工作环境,但对于合适的人来说,这也是他们努力的动力。

总结要有想法

中台解决的问题

往技术层面说,中台解决的问题是 ——多项目且 项目相对独立,导致需要重复造轮子,如:文件上传 / 订单模块 / 支付模块 / 搜索模块...引起的研发周期长,程序员996了都不能灵活应对业务变化 的情况
往业务层面说,中台解决的是 —— 因为项目相对独立,技术重复造引起的 研发周期长/ 面对市场需求总是慢半拍(不灵活) / 试错成本高/不利于创新

中台解决的方式

通过统一的公共技术模块抽离形成服务。再次需要该服务时通过接口调用完成,避免重复造轮子,避免研发周期拉长明确业务流程,封装成公共业务流程模块。