前言
今年是我毕业的第 10 个年头, 半路出家做了前端, title 一直是前端, 你可以说我很专注, 有时候也有些遗憾. 一直以来, 当别人问起你是做什么的, 我说前端或者全栈, 别人说: 哦, 做页面的啊! 心里难免有些失落. 前端是个资源型角色, 在认知里对业务的理解深度不够, 加上通常负责业务领域很广, 比较难有积累和沉淀. 如果你问一个毕业 10 年的 JAVA 老司机, 他跟你谈的一定是大流量下的分布式架构, 而前端可能还是昨天茶余饭后讨论 vue 和 react, 或者是 angular 谁更强. 如何突破, 如何提供业务更多价值, 前端们一直在苦苦探寻. 网上很多文章, 给人启发, 但每个人面对的环境, 负责的业务不同, 不一定都适用. 结合自己过去几年在阿里云的前端经验, 也做个总结.
1.0 版本 - 工具 & 团队
今年是我来阿里云的第五个年头了, 从没有想过会在一个公司呆的如此之久, 更没想过我能在一个岗位上沉淀 4,5 年. 刚入职在阿里云控制台团队, 主要负责云盾控制台, drds 控制台等, 开发过程中发现大部分场景是「表格」,「表单」, 为了避免自己不断重复开发, 封装了 simpleForm 以及控制台 cli 脚手架, 可以做到新开发控制台一键敲定(这个脚手架直到去年还有人问我如何用...... 也是经久不衰). 这个时候也萌生了做个 ide, 可视化搭建 UI 视图, 不过限于精力和当时团队的方向, 且当时 vscode 还没今天这么流行, 没有尝试, 比较遗憾. 不过做 webIDE 这个点, 算是在心里种下了.
后由于组织结构调整, 我从控制台团队独立出来, 负责当时的网站运营方向, 开始比较艰难的从 0-1 组件团队过程. 当时业务相对比较简单, 主要是: 阿里云官网以及官网的 Node.JS, 云市场业务. 由于在控制台团队主要用的 AngularJS, 感觉上手成本比较大, 在建立新团队, 以及我自己可以选择的时候, React 成了我的首选. 当时 vue 还没成熟, 其实能选的也只有 react. 新的技术体系, 需要有配套的工程化体系, 当时 Def 还处在 1.0 时期, 为了稳定以及减少开发成本, 很自然我们在 xef 上做了插件式开发, 结合自己业务特性, 分装了响应的模板, 以及定制了开发周期. 后由于 xef1.0 升级 2.0, 导致我们工具的不稳定, 且改动非常大, 逐步将我们的工程化体系独立, 这就有了后续的 DBL(当时叫屌爆了). 我跟老板做汇报时, 老板觉得这名字上不了大雅之堂, 还硬是憋了个比较有内涵的名字 -- 实在不好记, 我现在都记不起来了. 这个阶段, 我们做了很多技术上的尝试, 团队成员都非常苦逼, 也非常有激情. 团队基础设施建设, 我们一直在优化, 随着 Dawn 的基于中间件式的 pipeline 方式设计, 可以说是将工程化做到一个比较高的高度, 未来不管是 webpack 升级到多少, 或者新的打包工具出现, 对我们来说影响都比较小. 面向未来的模式, 让我们只需要修改内核, 使用者无感知. 新的工程化方案也积极跟阿里云其他团队沟通和交流, 之前跟风驰和释然也达成一致意见作为阿里云统一构建工具推进, 不过落地的不是很好. 同时, 新的方案也完全遵循集团的标准, 跟淘宝阿大团队无缝对接. 另外还有一个好处是: dawn 不局限在 react, 你可以使用任何框架; dawn 不局限在 redux, 你可以使用任何你喜欢的数据管理, 实际上我们自己有用 mota,mobx,graphql-apollo 等等. Dawn 连接: https://github.com/alibaba/dawn
讲完工程化, 其实应该讲讲组件化, 这是个无法回避的问题, 但这对我们来说也是个艰难的过程. 15 年的时候, 我们用过 antd(已开源), 但是在上层做了一层业务封装; 后来 fusion 开始盛行, 在跟 ued 沟通后, 考虑到集团统一, 用了一段时间的 fusion(已开源); 最后我们还是选择了自建组件库, 这是一个很无奈的举动. 具体细节不表, 其中一个重要原因是我们的前台业务需要「阿里云自己的设计元素」, 在经过团队很长时间的建设, APS 组件库已经作为团队组建库的基础, 在其之上构建了业务组件, 并在之上构建了业务解决方案.
除了折腾传统前端领域, 也尝试做了很多跨栈的事情. 在我所负责的业务中, 由于「端」业务的确实, 我们更多的是偏「全栈」. 前端同学做全栈, 讲实话是不行的 -- 绝大部分前端同学在架构, 运维部署方面还是经验偏少, 考虑更多的是跟展现层相关. 在全栈路径上, 由于我们负责的是核心交易链路, 我们没有用大家熟悉的 Node.JS, 而选择跟后端一样的语言 --Java. 做这个决策, 其实是挺困难的, 也是有故事的. 原先有个系统, 前端同学用 Node.JS 写的, 但由于业务非常复杂, 加上前端一直是个资源瓶颈的角色, 一个人干三个人的活, 所以这个同学最后搞不定, 离职了. 这么个系统就变成了后端想接无法接, 前端「没人力」接的状况, 非常尴尬. 从那以后, 业务系统中就决定了直接使用 Java.
在全栈路上, 我们主要有两个策略:
大前端下自己写部分业务的 Java
利用 serverless 通过代理统一配置化转
大前端写 Java, 阿里云其实非常多的前端都已经具备了这个能力, 我自己也有独立开发几个系统从 0-1 上线, 分布式部署且支持国际化的经历. 做了一段时间后发现, 其实效率上还好, 并没有传说中 Node.JS 比 Java 要高效很多的体感.
利用 serverless 通过代理统一配置化转, 有段时间看社区有部分人提到 Graphql, 对此产生了兴趣, 就顺便了解了下, 通过代理的方式可以将后端数据转换成前端需要的格式, 非常吸引人, 也就一下子扎进去. 我自己也同时做了 Node.JS 的版本给团队同学普及, 同时做了 Java 版本的 demo 给后端普及. 同时了解到 b2b 的 Mbox 平台跟我们想要的能力比较像, 找过他们给我们分享, 但由于业务系统整个搭建在他们平台有一定得风险, 于是决定了自建代理平台, 这也是「云查询」平台的背景. 云查询主要是战锋主导并推进落地的, 在集团内取得了不错的影响力, 很多 BU 很多部门去做过分享. 在业务上, 通过云查询, 我们实现了不用管应用的运维和部署, 实现业务逻辑和接口的转换, 并自动扩容. 尤其是营销体系, 在元策 & 隐天和战锋得协同下, 取得了比较大的效率提升, 并支持了阿里云去年的双十一. 具体「云查询」文章介绍可以看我另外一篇文章.
云查询经过一段比较长时间的发展, 我们已经逐步将它作为基础能力下沉, 在云查询的 serverless 之上长出了不同的「轻应用」, 以支持不同的垂直业务场景. 比如: 可视化搭建领域「页橱」, 基于权限 & 角色的中后台解决方案「Flex」等;
还记得我之前说过 5 年前我想做 WebIde, 没有开始; 2 年前, 看到其他云厂商有 WebIDE, 我们由于业务压力, 业务压力没有搞成; 今年我们总算是有一点启动, 已经和 appStudio 的同学在共建, 基于 appStudio 基础之上把我们的 dawn, 云查询做打通, 做云端集成化, 一站式的研发体验.
通过以上的技术基础建设, 已经为我们构建了很好的基础基础. 业务布局对应着团队, 组织的建设. 过去几年, 团队从 0-1 建设, 到目前 xx 个在岗同学, 形成了 4 个梯队, 三个 3 业务方向 & 一个技术架构方向, 一路走来, 感觉带团管理水很深, 很多时候不是说你带的人越多越好, 最近看到一本书提到一个词「情感成熟」, 这个非常重要. 一个技术好, 做业务的好手未必能管理好团队, 在不同阶段需要适应不同角色的要求, 最重要的是时刻保持忧患意识, 保持持续学习. 在团队建设时, 需要重点区分 manager 和 leader, 尤其是业务团队我们更希望成为 leader, 去带着做业务, 而不仅仅是做绩效管理.
2.0, 也就是过去一年, 我们在业务思维指导下, owner 了部分业务, 并利用横向的技术打通, 横向的业务思维, 取到了一些成果, 接下来进入 2.0
2.0 业务思维 - 以横向视角推进业务赋能
我们通常把组织中的人分为: 一字型,| 字型, T 字型,+ 字型. 前端正好是 - 字型团队, 负责的业务非常广, 而前端又是个非常稀缺的岗位, 招聘很困难, 所以盘子越大资源瓶颈越明显.「一字型」角色团队, 典型的问题就是对业务的深度理解不够, 单纯从技术层面去做营销的搭建, 中后台的可视化, 结果都不尽如人意. 这么说起来, 可能你觉得没法往下看了, 天花板在那里, 如何突破其实并没有太多可参考的例子. 我写这篇总结, 正是有些这样的感悟, 希望给大家做一些输入, 帮助大家去思考.
「一字型」虽然从业务上看我们的深度不够, 但从专业技能看我们是标准的「| 字型」. 前端经过这 10 来年的发展, 语言, 框架, 工具已经逐步趋于稳定, 各种端的性能也越来越流畅, 生态非常活跃, 任何你碰到的困难相信社区都已经有比较成熟的方案. 前端生态快速发展的 10 年, 也验证了我们这些人有着非常强大的学习能力, 7 天一个框架, 3 天一个数据库估计都不是太大难事(略夸张, 但表达的是这么个意思). 前端直接对接客户, 对客户体验的敏感, 对流程数据化的敏感, 对业务逻辑流程的感知, 都是我们生存的根, 也是我们独一无二的能力, 这个根我们不能丢.
有句话叫: 饱暖思淫欲, 不太恰当, 姑且一比. 在前端纵深领域的深耕, 让我们成为了「紧缺资源」, 随着工具的完善, 前端们也更希望利用技术为业务赋能. 如何赋能? 挡在我们面前的是「意识」. 在营销中, 认知, 需求, 品牌, 品类, 价格五个要素中,「认知」最为重要. 比如阿里是做电商的, 腾讯是做社交的, 百度是做搜索的, bat 在自己主营业务范畴不断布局, 构建了庞大的生态, 做过很多尝试, 但看起来最终还是围绕本身的基因做生态投资成功率要高一些. 那我们想要业务赋能, 瓶颈就在于「你个切页面」也要赋能吗? 好好做好体验, 提效不好吗? 我认为「体验, 提效」这是前端最核心的能力, 也是毕生都努力要实现的目标, 坦白讲我们没法马上解决资源瓶颈问题, 毕竟现在毕业生都在应聘算法, ai, 人工智能; 我们也没办法搞一轮体验提升计划; 这是个很漫长的过程. 但如果我们能以业务的角度出发, 去发现问题进而辅助以技术手段解决, 并沉淀平台, 应对未来千变万化的需求, 可能更为实际一些. 做为团队的 TL, 除了在专业上给与同学「|」型的能力纵深, 也更希望带着团队同学获得更多业务体感. 离开业务谈技术, 谈中台都是空中楼阁; 离开业务谈前端, 注定只能是重复造轮子, 而这种低水平的重复正在发生, 且可能会持续很久.
在很长一段时间里, 我都试图把我们「一字型」业务广度做个抽象和融合, 希望把「点状」形成「线」, 进而形成整体「面」解决方案. 我所负责的业务中, 主要有 4 个大方向:
官网 & 营销 - for 长尾
商业化流程后台 - for 小二
核心售卖流程 - 核心能力层
销售, 合作伙伴
官网 & 营销: 主要包含获客, 激活, 转换, 留存几个节点, 构建高效的「人」,「货」,「场」. 很长一段时间里, 阿里云的内容维护, 营销大促都是基于集团 CMS 来的. 传统大促会场, 卡片的方式, 前端挖坑后运营编辑内容, 而阿里云的「商品」跟淘系有着比较大的差别, 另外我们也没有招商, 选品的体系, 导致这种简单人肉运行的大促方式存在很多弊端, 比如不高效, 不复用, 不能做个性化, 数据流程监控力度不够精细等. 此外「投放」能力的建设还不够, 没有办法做到精细化的人群做精准的营销内容投放. 为了解决这些问题, 去年开始, 由前端团队和 pd 一起推进完善的营销体系建设:
在原有商品的基础上, 构建了「营销商品」的概念. 更抽象的「货」, 且可视化在线配置直接拉取了实时价格和库存. 通过我们 1.0 工具建设的 dawn, 打通开发流程, 使得整个开发链路一致, 成本更低. 可抽象的货匹配上专门为货打造的 UI 视图, 形成场景能力沉淀.
构建 ACE(Alibaba Cloud Experience)架构体系, 打通搭建体系, 通过技术降级打通各类「场」, 更好的承载好营销商品的投放.
通过全链路场景的曝光, 点击, 转化, 以及最终成交的商品信息等数据的积累, 生成用户画像, 提供内容场景化方案 (在不同场景中精确得向用户展示商品或信息) 完善「人」的定位.
商业化商品配置: 上面提到「营销商品」时提到「基础商品」. 目前阿里云基础商品主要分为:「公有云商品」和「技术输出型」. 过去很长一段时间我们偏公有云的能力建设, 今年年初才开始逐步融入专有云体系. 在商业化系统中, 我们的小二需要配置售卖规则, 价格, 需要定义商品模型; 同时复杂的规格之间的约束, 异常复杂. 如何提高商业化的输入和输出的强体验, 我们还有很长的路要走. 结合今年的专有云项目, 从模板的方式出发, 将一类产品做个聚合, 简化商品模型配置的步骤, 大大提高了配置效率, 提高体验.
销售 & 合作伙伴: 15 年刚开始组建团队(这里指的都是前端团队, 不是业务团队),15 年 - 18.3 月大部门的核心 kpi 是营收, 是首购用户数, 主打的是中长尾客户, 获得了非常高速的市场增长. 后来团队 cover 范围不断扩大, 也负责销售 & 合作伙伴体系, 围绕着「市场营销」,「商机培育」,「商机转化」,「合同履约」构建了我们自己的销售 crm 系统. toC 的业务通常比较好理解, 毕竟我们也是 c 的一员. 这段 toB 的经历, 结合业务一号位的培训班, 让了解到销售系统的核心, 除了工具, 最想要的是解决方案, 是产品能力的丰富.
大概介绍了各个方向的业务, 回到我们讨论的主题来 -- 借助横向优势, 整合资源 & 架构提供业务赋能. 为了分析他们之间的共性, 我们经过很多次的讨论, 终于汇聚得到我们的业务流程大图(对外脱敏后的示意图):
从这个流程大图中, 各个分支最后都需要依赖「售卖能力」, 这个售卖能力
表现在营销中是「弹窗 buy(减少跳出, 直接购买)」, 购物车(多产品交叉购买, 数据算法推荐), 套餐(多产品打包优惠售卖), 提货券(下单和生产分离的售卖能力);
表现在销售链路中是「产品配置清单」,「采购单」,「CBM 提供给大客户的 CTO 价格计算器」
表现在商品商业化链路中是「模板化」配置清单能力
在一大团子中找到业务的共性「售卖能力」, 在经历一段时间比较耗资源, 耗时的烟囱式开发方式后, 抽象出了售卖的核心支持层 -- 紫金阙. 这一层, 我们定位为业务中台, 偏前端层面, 也是大前端的领域范畴. 唯一需要指出的是, 我们用的是 Java, 没有用 Node.JS, 无其他差别. 最后架构如下(脱敏, 细节忽略):
新的架构模式下, 我们减少了大量的前后端沟通, 比如「分销采购市场」以传统开发方式需要 1-2 个月, 我们 2 周就搞定了. 新的架构模式, 在可预见的未来, 可以很好的支持各种营销新玩法, 也可以支持销售和合作伙伴的『解决方案』.
我想说的是, 如果没有我们全量业务的横向视角, 我们的抽象方案不会这么通用, 这是前端团队的优势. 如果没有大前端稳定的技术生态, 我们也没机会去做业务赋能. 这才是前端的未来, 利用横向优势整合, 结合某个领域做深做透, 形成垂直深度, 为业务提供价值, 也让我们的技术方案「有的放矢」. 前端经常是围绕一个点做需求, 得到工具, 但无法提供解决方案, 因为没有业务属性; 唯有结合业务特性, 做好沉淀, 工具变成平台才能释放更大价值.
3.0 探索以技术能力为业务提供增值
「云计算」核心是解决企业成本的问题, 用低成本获得超强的计算, 存储能力, 获得高并发下弹性扩容的能力. 云计算提出了很多概念: IAAS,PAAS,SAAS... 相对前端角色来讲, 体感并不是很强. 但是 BAAS 的出现, 让前端眼前一亮. 试下想, 原先我们需要大量后台开发的应用, 逐步都沉淀成领域能力, 提供 baas 服务给前端调用, 前端再也不用考虑部署, 运维, 只关心业务代码, 想想也是心动. 目前市面上提供类似服务的公司很多, 有专门做后台数据存储的如 Leancloud, 有做数据分析的, 有做消息推送的等. 所以, Baas 会是前端的春天吗? 这个拭目以待.
扯了理想, 我们也说说现状. 目前阿里云大概是 Buy In Aliyun, 我们售卖的是 IAAS 层的资源, 用户核心的业务流程还是基于自己的研发体系. 在前端这个纵深领域内, 基于云打造「云端一站式研发流程」, 将企业前端变成: Work In Aliyun or Dev In Aliyun. 通过对企业前端生命周期的分解, 通过 WebIDE 来承载整个流程:
1. 将创建关联阿里云的 code
2. 阿里云前端构建工具 dawn 作为基础构建能力, 可定制化团队构建的中间件(webpack,lint,server,mock 等), 构建 stage(init,dev,test,publish); 基于工程化化能力提供统一的规范, 提供各种不同应用框架的初始化模板.
3. 代码点击发布后, 自动编译, 并发布到 cdn.
在此基础流程之上, 我们提供 serverless 相关能力, 通过调用 BaaS 领域服务能力, 以及 FaaS 网关触发能力, 实际上我们可以完全一站式, 且是前端主导的应用开发.
还记得我前面提到我们的 serverless 应用「云查询」, 这一层我们逐步进行能力下沉, 变成 serverless 基础能力. 各公司几乎都有营销搭建体系, 过去搭建的玩法不够多样, 主要依托 cms 能力自行开发, 随着现在各种「端」能力的延伸, 多样性化, 营销搭建也变得越来越复杂. 而我们基于「云查询」之上沉淀出的「页橱」搭建体系, 完全可以借助「云端一站式研发流程」提供很好的 SAAS 化服务. 这是我们的优势,「云端前端解决方案」也只有我们适合做这个, 这里只列举了其中一个场景, 类似的机会还有很多.
总体感觉, 一云多端借助 serverless 前端的春天已然来临. 抓住我们核心的竞争力, 并同时发现业务中的问题, 跨端推进解决, 这是最好的出路. 你问我做什么的, 我...... 我就是阿里云 CPO(首席页面仔啊)
ps: 阿里云智能业务中台 & 阿里通信招 P6-P8 前端, 欢迎来撩. base 可北京可杭州, 杭州工位在美丽的西溪园区哦. 旁边挨着的都是 UED 妹子 & 测试妹子. xiaoming.dxm@alibaba-inc.com
来源: https://yq.aliyun.com/articles/695361