关于如何打造前端技术中台的思考和探索

9,331 阅读12分钟

前言

我从 15 年开始参与前端技术中台团队的工作, 中间主导过大型的前端技术中台架构设计和实施, 在 19 年积累了一些前端技术中台团队的领导和管理经验, 目前负责一个 15 人左右的前端技术中台团队.

之所以说这 5 年的经历和现状, 主要是想说, 搞前端技术中台这件事, 严格来讲, 我没搞成, 我花了 5 年的时间, 从思考实践失败再思考再实践, 直到最近去了趟西北, 当然西北之行除了感慨沙漠戈壁之辽阔和中台这件事并没有啥关系. 只是回来之后我想通了一些事, 感觉能把前端技术中台说清楚了.

正文

中台概念,始于马云在 supercell 的考察, 马云回来后就在阿里提出了中台战略, 这个概念纷纷扰扰至今, 其实是众说纷纭并没有一个标准. 中台中台, 就好像中国人的中庸之道, 可圆可方, 在模棱两可之间.

但 supercell 毕竟是家游戏公司, 要搞清楚什么是中台, 还是得从这家公司说起.

supercell 的中台

对于 supercell 这家芬兰移动游戏公司来说, 中台并不是个明确的概念, 事实上这家人数不多的公司屡屡创造爆款游戏, 然而在马云看来这正是中台的魅力

通过大量的标准件, 降低创意实施的成本, supercell 正是借助其强大的游戏打造平台, 以非常低的成本快速实施一个一个游戏创意, 并测试出其中最棒的那个, 随后大力推广, 但如果你玩过这家公司的游戏, 你会发现他的游戏在视觉效果上非常雷同, 风格接近.

并且 supercell 的游戏都是以快节奏的竞技游戏为主, 并没有做出像吃鸡, 王者荣耀那样复杂的游戏. 内容相对简单, 上手快, 玩得爽是这家公司游戏的主要风格和特征.

这引发了我对中台的思考? 是 supercell 的中台能力不足以支撑他制作不同风格不同类型的游戏么? 还是说其实中台本身就具有很强的局限性?

对于写代码的我们来说, 答案是显而易见的, 中台并不是万能的, 中台对业务的高效率支撑的前提是仅限于明确的业务范围, 在 supercell 这里就是典型的快节奏小游戏, 类似的视觉素材, 设计风格.

也就是说, 基于 supercell 的中台, 创意并不是无限的, 游戏制作者必须在一定的限制条件内去构思游戏, 并实现出来, 不然其成本会非常高.

这让我想起了另一个词 平台

中台和平台的关系

平台是一个很宽泛的概念, 外卖可以是平台, 搞技术的可以是开放平台, 订票打车可以是平台, 以前美团的某个高管曾说过, 打造一个平台的前提是能够实现服务的标准化, 且平台的供需两端是动态不平衡的, 这句话是什么意思?

简单来说, 如果你发现市场里有这样一种供需, 比如打车, 乘客大概率不会遇上同一个司机, 反之亦然, 并且打车这件事可以被标准化一种流程, 那这就是一个平台, 但如果乘客和司机是一种长期合作关系, 那随着这种关系的建立, 供需会趋于平衡, 也就是越来越少的人会通过平台来打车, 那这种平台就没有价值了.

回过头来说中台, 中台, 平台, 都是台, 中台会有平台这种特性么?

我仔细想了想还真不是, 不仅不是, 反而相反, 上面说了平台的两个特征, 标准化服务, 供需不平衡, 我觉得要加一个个性化要素, 因为供需不平衡导致平台可以承载完全不同的要素, 也就是服务流程标准化, 但是服务的内容可以千奇百怪, 非常个性, 美团就是个典型的例子

如果中台和平台具有相同的特征, 那中台就没有意义了, 我仔细研究了下, 发现中台不仅和平台大相径庭, 而且几乎具有完全相反的特征

平台: 服务标准化, 要素个性化, 供需动态不平衡, 具有普适性

中台: 服务个性化, 要素标准化, 供需动态平衡, 具有局限性

这里提到的中台概念更更具有商业内涵, 如果你关注一些创业内容的文章, 可能会看到诸如商业中台这样的词语, 考虑到我们毕竟是搞技术的, 关于中台为何如此定义, 暂且不表, 我们先用这种定义来看我们的前端技术中台如何映射上这些特征.

打造前端技术中台的动机

中台起源于 supercell, 那这个动机必然是不能脱离这家公司的, 对于 supercell 来说打造一个游戏中台的目的很简单, 就是为了让创意的实现成本更低, 出爆款游戏的效率更高, 这和 2C 业务领域非常契合, 由于我在 2B 领域工作, 所以还是来看下对于一家 2B 的公司来说, 打造前端技术中台的动机又是什么

上面提到了两个点

  • 低成本实现创意
  • 高效率生产爆款

对于目前我们所处的财税领域这个行业来看, 由于政策和市场的变化, 我们需要具备非常快速的产品响应能力, 虽然我们并没有游戏公司那种追求爆款的动机, 但是我们依然需要我们的产品能够具有很好的动态性, 能够适应政策市场的变化, 能够满足不同规模客户的需求. 这是我们能够抢占市场先机的有力因素.

同时这种动态性必须是低成本的, 因为如果成本很高, 那显然会丧失了推出产品的时机失去客户.

所以从动机上来讲是相似的, 我们需要低成本开发产品, 高效率响应政策和市场变化.

而这正是打造前端技术中台的初衷.

因为在前端技术领域, 政策和市场的变化必然导致产品形态在视觉和交互上的变化, 这种变化会因为企业客户的不同规模产生较大差异. 如果我们以常规的前端代码生产链路, 那显然是明显跟不上需求, 生产力会受到很大限制

常规的前端代码生产链路

目前通用的做法, 从客户那里搜集需求, 产品经理绘制原型, 编写需求文档, 因为产品缺少交互设计和技术背景, 在这一环节会非常耗时, 产品要反复和技术设计确认原型的可行性, 文档的满足性. 但是众所周知, 越是复杂的产品, 包含的细节会越多, 但是确认的时间并不是无限的, 在有限的需求确认时间内, 我们往往很难把每个产品的点都确认到位, 因此通常依赖开发的经验, 或者在开发过程中, 砍需求.(经常会有开发吐槽产品需求不合理, 但其实是这种模式下的必然现象)

过了需求确认环节, 不同的产品会使用不同的工具, 目前来看已经是平台型工具了, 通过一些相对普世的原型要素来搭建原型, 比如墨刀这样的工具, 然后交给交互设计师进行视觉设计.

同样的交互设计师会再次和开发确认交互的可行性, 这又是一个耗时的过程, 并且交互设计师和产品一样会使用各种不同的设计工具, 这些工具也具有平台型特征, 即会有大量相对标准的交互设计素材供他们使用, 但通常都要修改.

最后作为前端工程师, 我们对着产品文档, 原型, 交互设计稿进行代码编写, 相同的, 我们也使用具有平台型的开发工具, 比如 vscode , vscode 上有很多插件, 都可以帮助我们提高代码编写效率.

在这条链路中, 你会发现, 我们目前代码的生产效率其实已经达到了一个上限, 这个上限正是由于各个不同角色使用的工具构成的. 这些工具普遍的特征是平台化且不互联互通.

平台型的工具帮助我们获取不同的相对标准的生产要素, 无论是原型要素还是交互设计要素还是代码要素, 但是在上文中我提到了平台的几个特征, 个性化的生产要素和标准的服务流程, 我们仔细品味下, 在这个代码生产链路中其实是相反的, 每家公司虽然大概率使用相同的平台型工具生产代码, 但每家公司的生产流程其实是不标准的, 即我们并不是按照平台型工具定义的流程来生产代码, 同时对于生产代码使用的要素, 对于单个公司来说其实是标准的, 即一个公司内使用的生产要素不会有太大的个性化, 因为这样会导致效率损耗, 但是我们使用的各种个性化的要素和公司业务要求的标准化的冲突导致我们经常需要进行二次修改的工作.

也就是通常说的, 看起来差不多, 但是改一改就很麻烦.

技术中台是为技术平台的不适应而生

技术平台不适应, 并且不存在也不可能存在能够高效率支撑所有公司业务的技术平台, 而中台恰恰为此而生.

就像我上面提到的, 中台具有个性化服务流程, 标准化生产要素这样的特征. 这就决定了中台天然具有局限性, 不可能服务不相同的业务, 即只有相同的业务才能共用中台, 而诸如前端领域里像飞冰这样走平台路线的产品其实恰恰并不能帮助前端开发提升多少效率. 而让飞冰这样的平台提供能够满足不同业务的生产要素显然也是伪命题.

因此打造一个前端技术中台, 就应该接受一个基本的原则, 中台就是为当前的特定业务服务, 且不具备普适性. 并且服务的业务种类越广泛, 中台的维护和实现难度就越大, 因此要打造前端技术中台需要考虑支撑的业务范围, 并控制实施成本.

目前我自己得到的一些结论, 大体上, 一个前端技术中台具备两条基本的生产链路, 并且这些链路是动态平衡的, 即我上面提到的供需之间不应该经常变化

要素支撑链路, 前端工程师 → 交互设计师 → 产品 → 客户

需求传递链路, 客户 → 产品 → 交互设计师 → 前端工程师

日常工作中, 经常有些公司的产品会绕过交互直接对接开发, 甚至有开发直接对客户的情况, 这种不平衡会导致你中台的作用无法发挥出来, 因此要确保要素供需的平衡也是打造一个前端技术中台的非常重要的前提

后话

基于以上思考, 我们团队开始尝试打造一个关于财税领域前端技术中台, 致力于提供可扩展可集成的财税交互模块, 目前会先以表格这样的重交互场景去切入, 后续有实践了我和各位进一步分享我们团队的一些成果

评论中有人提到, 组件化, 模块化, 我想说的是相对于组件化模块化这种方式是从技术角度出发, 是解决问题的思维方式, 而中台其实是一种利用产品思维解决问题的思维方式, 两者有很大差异, 技术角度解决问题通常都是单点的, 比如我们现在技术栈不统一, 所以我们要统一技术栈, 因为公司里重复开发组件, 所以我们要打造一个组件库, 或者我们对某个相同的逻辑抽象出一个模块, 这些其实都是比较典型的技术思维, 即我们仅仅从技术使用者的角度利用我们已知的技术来解决问题, 但如果是产品化思维, 你需要考虑更多, 你打造的可能不是一个组件库, 是一个组件中台, 如果是组件库, 最后可能是可以开源的, 因为你解决的问题是一个宽泛的问题, 这样你不会考虑你公司内其他角色的真实感受, 比如产品, 比如运营, 甚至你的用户, 但如果你打造的是一个组件技术中台, 你能开源么? 如果你往深了做大概率是没法开源的, 因为你要做好这个东西, 需要考虑不同层次的使用者的感受, 平衡你提升他们体验需要付出的成本, 这是典型的产品化的思维, 而当下的前端工程师作为最贴近用户的一群人, 恰恰缺少的就是这种产品化思维, 以及将技术产品化的能力.