毕业 10 年的前端，如何突破自我，提供更多业务价值？

hwyzw

    前言

    今年是我毕业的第 10 个年头，半途而废成为了一名前端和尚，头衔一直都是前端的，你可以说我很专注，有时候也会有些遗憾。一直以来，当人们问你做什么时，我会说前端或全栈，人们会说，“哦，你做页面！我心里难免会有些失落。前端是一个资源型角色，由于在认知上对业务缺乏深度的理解，而且通常负责的业务领域范围很广，所以很难积累和沉淀。如果你问一个毕业 10 年的 Java 老手，他肯定在和你聊高流量下的分布式架构，而前端可能还在讨论 vue 和 react 昨天晚饭后，或者谁更强。如何突围，如何为业务提供更多价值，前端一直在努力探索。互联网上有很多启发性的文章，但每个人都面临着不同的环境和不同的业务，它们可能并不都适用。结合我这几年在阿里云的前端经验，我也做了一个总结。

    1.0版 - 工具和团队

    今年是我在阿里云工作的第五个年头，我从来没有想过我会在同一家公司待这么久，更别说我可以在一个职位上安顿 4 或 5 年。我刚加入阿里云控制台团队，主要负责云盾控制台、DRDS 控制台等，发现开发过程中大部分场景都是“表单”和“表单”......也是持久的）。这时候我也想出了做一个 IDE，可视化地构建 UI 视图的想法，但当时仅限于精力和团队的方向，也没有像今天这样流行，所以我没有尝试，很遗憾。但能做到这一点，也算是种在了我心里。

    后来，由于组织架构的调整，我从控制台团队独立出来，负责当时网站运营的方向，开始了从0到1组建团队的艰难过程。当时的业务比较简单，主要是：阿里云官网和官网和云市场业务。由于主要由控制台团队使用，感觉上手成本更高，而当涉及到组建新团队和我自己的选择时，React 就成了我的首选。那时，Voe 还不成熟，事实上，唯一的选择就是 React。当时 Def 还处于 1.0 时期，为了稳定和降低开发成本，我们很自然地在 xef 上做插件开发，结合自身业务特点，分装响应模板，定制开发周期。后来，由于 xef1.0 升级到 2.0，我们工具的不稳定是变化造成的，而且变化非常大，我们的工程系统逐渐独立，这就导致了后来的 DBL（当时叫雕爆）。我跟上司汇报的时候，上司觉得这个名字不雅，坚持要隐瞒一个更有内涵的名字——真的很难记，现在甚至记不起来了。在这个阶段，我们做了很多技术上的尝试，团队成员都非常努力，也非常有激情。凭借 Dawn 基于中间件的设计，可以说工程化已经达到了比较高的水平，无论未来进行多少次升级，或者出现新的打包工具，对我们的影响都会相对较小。面向未来的模式允许我们只修改内核，而用户不会意识到它。新的工程方案也在与阿里云其他团队积极沟通交流，之前顺风解风的协议也已达成协议，将其作为阿里云的统一建设工具进行推广，但执行效果不是很好。同时，新方案也完全遵循集团的标准，与淘宝阿大团队无缝对接。另一个好处是 Dawn 不仅限于 React，你可以使用任何框架;Dawn 不仅限于 redux，你可以使用任何你喜欢的数据管理，事实上我们有自己的 mota、mobx 等。

    黎明连接：

    说完工程，我们其实应该说组件化，这是一个绕不开的问题，但对我们来说也是一个困难的过程。15 年里，我们用的是 antd（开源），但是在上层做了一层业务封装;后来走红起来，和UED沟通后，考虑到集团的统一，使用了一段时间（已经开源了）;最后，我们选择自建组件库，这是一个非常无奈的举动。其中一个重要的原因就是我们的前端业务需要“阿里云自己的设计元素”，经过团队长时间的建设，APS 组件库已经作为团队构建库的基础，在其之上构建业务组件，并在其上构建业务解决方案。

    除了抛弃传统的前端领域，我还尝试做了很多跨栈的事情。在我负责的业务中，由于 “end” 业务是真实的，所以我们更加 “full-stack”。前端学生做全栈，但说实话，这是不可能的——绝大多数前端学生在架构、运维部署方面还是没有什么经验，他们的考虑更多地与表示层有关。在全栈路径上，由于我们负责核心交易链，所以没有使用大家熟悉的 Java 语言作为后端。实际上，做出这个决定是相当困难的，而且有一个故事要讲。本来有一个系统是前端同学用来写的，但是因为业务很复杂，而且前端一直是资源瓶颈，一个人干了三个人的工作，所以这个同学最后处理不上，辞职了。这样的系统就变成了后端想要无法连接，前端又“没人力”连接的情况，非常尴尬。从那时起，业务系统就决定直接使用 Java。

    在全栈路上，我们有两个主要策略：

    在大型前端下为您自己的部分业务编写 Java

    利用通过代理进行的转账的统一配置

    大前端写 Java，阿里云其实很多前端都有这个能力，我自己也有独立开发几个系统从 0-1 上线、分布式部署和支持国际化的经验。做了一段时间后，我发现其实效率不错，没有比 Java 更高效远的体验感了

    使用代理的统一配置，社区中一些人提到了对它感兴趣，顺便了解到后端数据可以通过代理转换成前端需要的格式，非常吸引人，而且一下子就全部搞定了。同时，我还做了一个版本给团队推广，同时做了一个Java版本的demo，用于后端的推广。同时，我们了解到B2b Mbox平台和我们想要的能力差不多，我们请他们与我们分享，但是因为整个业务系统都是建立在他们的平台上，存在一定的风险，所以我们决定建立自己的代理平台，这也是“云查询”平台的背景。云查询主要由展峰主导和推动，并在集团内部取得了良好的影响力，很多 BU 和很多部门都做了分享。在业务方面，通过云查询，实现应用的运维部署无忧，实现业务逻辑和接口的转化，自动扩容。特别是营销系统，在元策&银天和展峰得的合作下，实现了相对较大的效率提升，并支持了阿里云去年的双11。关于“云查询”一文的具体介绍，可以参考我的另一篇文章。

    经过长时间的发展，我们逐渐将其作为基础能力沉沦，在云查询之上成长出不同的“轻应用”，以支持不同的垂直业务场景。例如，视觉建设领域“壁橱”，基于权限和角色的中后台解决方案“Flex”等;

    我记得在 5 年前我说过我想做这件事，但我没有开始;两年前，我看到其他云厂商有，但由于业务压力，我们没有得到业务压力;今年，我们终于有了一点起点，我们已经在和同学们一起努力，在此基础上打通我们的曙光和云查询，并做云集成和一站式研发体验。

    通过上述技术基础设施，我们建立了良好的基础。业务布局对应团队和组织的建设。在过去的几年里，团队已经从0-1的建设转变为xx个在职学生，形成了4个梯队，三个3个业务方向和一个技术架构方向，一路走来，我感觉团队管理的水很深，很多时候并不是说你带的人越多越好，我最近看到一本书提到了一个词“情感成熟”， 这非常重要。一个有好技能和业务的好人，不一定能把团队管理好，需要适应不同阶段不同角色的要求，最重要的是要时刻保持忧心和不断学习。在团队建设方面，我们需要专注于差异化，尤其是我们希望成为的业务团队，做生意，而不仅仅是绩效管理。

    2.0，也就是在过去的一年里，在商业思维的指导下，我们拥有了一部分业务，并利用横向技术开拓和横向商业思维，取得了一些成果，然后进入了 2.0。

    2.0 商业思维 - 从横向角度推动商业赋能

   

    我们通常将组织中的人员分为：one-word、|-type、T-shape 和 + type。前端恰好是一个  团队，负责的业务范围非常广泛，而前端是一个非常稀缺的职位，招聘难度很大，所以板块越大，资源瓶颈就越明显。“一字”角色团队的典型问题是，他们对业务没有深入的理解，单纯的构建营销，从技术层面可视化中后台，结果并不令人满意。说起来，你可能会觉得自己往下看不下去，天花板就在那里，如何突破的例子并不多。我写这个总结是因为其中一些感受，我希望能给你一些意见来帮助你思考。

    虽然我们从商业角度来看不够深入，但从专业技能的角度来看，我们是标准的“字体”。前端经过 10 年的发展，语言、框架、工具逐渐稳定下来，各端的表现越来越流畅，生态非常活跃。这 10 年前端生态的快速发展，也验证了我们这些人都有非常强的学习能力，估计 7 天有个框架，3 天有个数据库并不难（稍微夸张一点，但表达了这样的意思）。前端直接连接客户，对客户体验的敏感度、对流程数据的敏感度、对业务逻辑的感知是我们生存的根本，也是我们得不到的能力，不能失去。

    有句话说：充满温暖和情欲是不合适的，所以让我们来对比一下。随着工具的改进，前端人员也希望使用技术来增强他们的业务能力。如何赋能？挡在我们面前的是意识。在市场营销中，在认知、需求、品牌、品类、价格这五大要素中，“认知”是最重要的。比如阿里在做电商，腾讯在做社交，百度在做搜索，BAT 不断布局主营业务领域，构建了巨大的生态，做了很多次尝试，但似乎到头来，围绕自身基因的生态投资成功率更高。那么我们想给企业赋能，瓶颈是 “你剪页” 也要赋能吗？有好的体验，提高效率好吗？坦率地说，我们不能立刻解决资源瓶颈问题，毕竟现在毕业生都在申请算法、人工智能和人工智能;我们不能做一轮体验增强计划;这是一个漫长的过程。但是，如果我们能从商业角度出发，通过技术手段发现问题并协助解决，沉淀平台以应对未来不断变化的需求，可能会更实际。作为一个团队，TL 不仅为学生提供“| ”能力的深度，也希望能带给团队更多的业务经验。离开企业去谈论技术，谈论中台是一座空中城堡;离开业务的前端注定是轮子的重塑，这种低级的重复正在发生，并且可能会持续很长时间。

    长期以来，我一直在尝试抽象和整合我们“槽”业务的广度，希望将“点”形成“线”，进而形成一个整体的“面”解决方案。在我负责的业务中，主要有四个方向：

    官方网站和营销 — 为长尾

    小二学生商品化过程

    核心销售流程 - 核心竞争力层

    销售、合作伙伴

    官方网站和营销：它主要包括客户获取、激活、转化和保留的几个节点，并构建高效的“人”、“商品”和“领域”。长期以来，阿里云的内容维护和营销推广都基于集团的 CMS。此外，我们没有招商选品的系统，导致这种简单的人肉运营推广方式存在很多弊端，比如效率低下、不能复用、无法做个性化、数据处理监控精度不够。此外，“投放”能力的建设还不够，没有办法实现对精炼人群的精准营销内容投放。为了解决这些问题，从去年开始，前端团队和 PD 携手合作，推动构建完善的营销体系

    在现有产品的基础上，构建了“营销产品”的概念。更抽象的“货”，可视化在线配置直接拉取实时价格和库存。通过我们的 1.0 工具构建的 DAWN，打通了开发流程，使整个开发环节保持一致，成本更低。抽象商品可搭配专为商品打造的 UI 视图，形成场景能力沉淀。

    构建 ACE（云）架构体系，打通建设体系，通过技术降级开辟各个“场域”，从而更好地承载营销产品的交付。

    通过全链路场景下曝光、点击、转化、最终成交产品信息等数据的积累，生成用户画像，提供内容场景化的解决方案（将不同场景下的产品或信息精准展示给用户），提升“人”的定位。

    商业化产品分配：上文提到“营销产品”时，提到了“基础产品”。目前，阿里云的基础产品主要分为：“公有云产品”和“技术输出”。过去很长一段时间，我们专注于公有云的能力建设，直到今年年初才开始逐步集成到专有的云系统中。在商品化体系中，我们小二需要配置销售规则、价格，定义商品模型;同时，复杂规范之间的约束也极其复杂。在如何提升商业化投入产出的良好体验方面，我们还有很长的路要走。结合今年的自有云项目，从模板出发，聚合一类产品，简化商品模型配置的步骤，大大提高配置效率和提升体验。

    销售与合作伙伴：15年刚开始组建团队（这里指的是前端团队，不是业务团队），15年到18.3个月的核心KPI大多数部门的核心KPI是收入，是首次用户的数量，主要关注的是中长尾客户，并已经实现了非常高速的市场增长。后来，团队的范围扩大了，我们还负责销售和合作伙伴系统，并围绕“营销”，“商业机会培养”，“商业机会转化”和“合同履行”建立了我们自己的销售CRM系统。toC 的业务通常比较容易理解，毕竟我们也是 c 的成员。这次toB的经历，结合No.1业务岗位的培训课程，让我明白了销售系统的核心，除了工具，我最想要的是解决方案，以及产品能力的丰富。

    在对各个方向的业务进行了一般性的介绍之后，让我们回到我们讨论的主题 - 借助横向优势，整合资源和架构，提供业务赋能。为了分析它们之间的共性，经过多次讨论，我们终于走到了一起，对我们的业务流程有一个大致的了解：

    从这个流程的大局来看，每个分店都需要依靠“销售能力”，也就是销售能力

   

    经过一段时间资源密集型、耗时的烟囱式开发，抽象出销售的核心支撑层——紫金雀。在这个层面上，我们定位为业务的中间平台，偏向于前端层面，也是大前端的领域品类。唯一需要指出的是，我们使用的是 Java，它不起作用，没有区别。最终架构如下所示：

    在新的架构模式下，我们减少了大量的前后端沟通，比如“分销和采购市场”，传统方式需要 1-2 个月才能开发出来，我们 2 周就能搞定。在可预见的未来，新的架构模型可以很好地支持各种新的营销方法，以及销售和合作伙伴的“解决方案”。

    我想说的是，如果没有我们整个业务的水平视图，我们的抽象就不会那么通用，这就是前端团队的优势。如果我们在前端没有稳定的技术生态系统，我们就没有机会进行业务赋能。这就是未来的前端，利用横向优势进行整合，结合某个领域做深做透，形成纵向深度，给业务提供价值，也让我们的技术解决方案“有针对性”。前端经常围绕一个点做需求，获取工具，但因为没有业务属性而无法提供解决方案;只有结合业务特点，做好沉淀，工具才能成为释放更大价值的平台。

    3.0 探索利用技术能力为业务提供附加值

    “云计算”的核心是解决企业成本问题，以低成本获得超强的计算和存储能力，获得高并发下弹性扩展的能力。云计算提出了很多概念：IAAS、PAAS、SAAS......相比于前端角色，体感不是很强。但 BAAS 的出现让前端大放异彩。仔细想想，我们需要在后台开发大量的应用，并逐渐沉淀成领域能力，提供 BaaS 服务给前端调用，而前端也不需要再考虑部署和运维，只关心业务代码。目前市面上有很多公司提供类似的服务，比如专门从事后端数据存储、数据分析、消息推送的公司。那么，Baas 会成为前端的春天吗？我们拭目以待。

    拉扯理想，我们也来聊聊目前的状况。目前阿里云大概是 Buy In，我们卖的是 IAAS 层的资源，用户的核心业务流程还是基于我们自己的研发体系。在前端的深度领域，我们将基于云打造“云端一站式研发流程”，将企业的前端变成“Work In or Dev In”。通过对企业前端生命周期的分解，整个过程贯穿：

    1. 创建阿里云关联的代码

    2. 以阿里云的前端构建工具 dawn 作为基础构建能力，可以自定义团队搭建的中间件（lint、mock 等），以及构建阶段（init、dev、test 等）;基于工程能力，为各种应用框架提供统一的规范和初始化模板。

    3. 代码点击  后，会自动编译并发布到 CDN。在这个

    基本流程之上，我们提供了相关能力，通过调用 BaaS 域的服务能力和触发 FaaS 网关的能力，我们实际上可以成为一个完整的一站式、前端主导的应用开发。

    记得我之前提到过，我们的应用程序 “cloud query” 是一个层，我们在这里逐渐将能力下沉，并将其转化为基础能力。几乎所有的公司都有营销建设体系，过去建设的玩法不够多样化，主要依靠 CMS 能力自己发展，而随着各种“端”能力的延伸和多样化，营销建设越来越复杂。而我们基于“云查询”的“橱柜”构建系统，借助“云一站式研发流程”，可以提供良好的SAAS服务。这就是我们的优势，而“云前端解决方案”只适合我们来做这个，这里只是其中一种场景，还有很多类似的机会。

    整体感觉是，借助前端的春天来了。抓住我们的核心竞争力，同时发现业务中的问题，并推动解决到底，这是最好的出路。你问我是做什么的，我......我是阿里云的 CPO。

    PS：阿里云智能商业中台和阿里通信P6-P8前端，欢迎来逗。基地可以是北京或杭州，杭州工作站在美丽的西溪公园。彼此相邻的是UED女孩和测试女孩。

    简历投递地址：