写点什么

从 P4 到 P9, 在马云家写代码到双 11 前端 PM

  • 2020-04-23
  • 本文字数:5649 字

    阅读完需:约 19 分钟

从P4到P9, 在马云家写代码到双11前端PM

今年的双 11 已经是阿里资深前端技术专家舒文来阿里的第 11 年,从应届生到双 11 前端 PM,他一路升级打怪,实现了岗位上从 P4 到 P9 的晋升。这第 11 届双 11 顺利结束之际,他把在阿里这些年的成长经历做一个总结和分享,希望你能在他的故事中得到些许启发。


P4:懵懂学生入行记 (2008.10-2009.12)


2008 年 10 月,入职阿里巴巴日文站,以前端岗加入 UED 团队。日文站的业务源于阿里巴巴国际站 - 提供在线的平台化服务,专注撮合中日贸易。


在那个前端的鸿蒙年代,页面重构工程师和 Javascript 程序员还是两个细分职位: 在阿里,前端、交互、视觉共同划属用户体验部门。


而在部份公司,有专门的重构工程师。


在日文站亦如是:现实情况是杭州和东京的团队,具备写 JS 能力的工程师均不多。不少同事专注在 HTML/CSS 领域,且专研极深。举个例子:在日文站,所有的 HTML/CSS 代码必须通过两个 Lint 工具:HTML 文書の文法をチェックし、採点します、[The W3C Markup Validation - 这让代码的规范性更好外,也能获得更好的搜索引擎分析 &索引权重。


随着业务发展,需求场景多且复杂起来,对 Javascript 开发能力要求就越高。同时,也激发了我的技术热情。除了看书,我迫切想参与其他事业部的前端交流会。感谢时任主管的支持,我开始主动跨部门沟通,将他山之玉和学习所得有了更多结合。慢慢地,在团队内部提出一些技术方案并逐渐应用到杭州/东京两个团队 (特别感谢最早时代的 D2)。


在那个阶段,我几乎参与了所有较为复杂的项目。结合当年的热门大作《高性能网站建设指南》、Yahoo 网站性能优化黄金法则,负责了主站的性能优化,取得了一些不错结果。


2009 年 10 月获得了日文站优秀员工,年底顺利晋升到新的层级(P5)。



P5:从热血到成长(2010.01-2011.06)


2010 年开始,业务略微调整,参与“日本买家获得”(Buyer Growth)。这个业务本质是通过平台技术优化(SEO、SEM 等)获得更高的搜索引擎权重、提高 Landing 到转化。


在这期间,随着被认可度提升、持续的项目历练,我的自信心也得到了锻炼。除了参与更复杂的项目外,我开始主动对业务和技术体系做出一些提案(Proposal) - 包括参考 Google Webmaster Guidelines 进行技术优化、参与了各种 SEO 项目,提出了现在回想起来各种或靠谱或不靠谱的提案。非常感谢历任主管的支持和包容,让一个楞头青能够没有后顾之忧地敢想敢做。


日文站初版克隆自 Alibaba.com,加之外包参与、跨东京和杭州多团队开发等原因,全站前端框架混杂,包括不限于 YUI/Mootools/PrototypeJS/ExtJS/TBra 等前端框架 &类库混杂在同一业务甚至页面。新人上手、多人协作、性能优化的成本很高,但历史原因积重难返,大家苦不堪言。


结束一个大项目后,时值“愤青”的我对全站的代码做了个调研和分析,说服了主管们,决定启动一个重构项目——旨在将全站混杂的代码统一到 jQuery。并大体确定了执行方案:随业务迭代上线、项目成员 1 人,我兼任 PM、开发/自测。


在之后,一个如同打了鸡血般的前端程序员,白天黑夜的翻历史 PRD、熟悉代码逻辑、阅读各种类库的手册,陆续将各业务线的脚本重写了一遍,边做业务项目边重构,整个项目持续了半年多,直到 11 年 Q1 完成。


现在回想起来,有些事情真需要一股冲动,正如买房、结婚。如果主管让我再多考虑半天,我兴许就怂了。当然,人生也可能走入另外一条主线。


2011 年日文站业务合入 B2B,我也参加并通过新事业部的年中晋升(至 P6 ) 。



2011 年阿里巴巴日文站誓师大会


P6:内部创业 + 前端的无线爆发 (2011.07-2014.06)


两段非常宝贵又特别的经历。


2011 年下半年主动选择加入阿里内部的创业项目:打造一款面向个人消费者的云产品。 团队不大,20 多人,各路专家云集,各负责人级别都很高。很享受这段工作旅程,我第一次参与桌面 Hybrid 端项目,第一次开发 SPA Web 应用,第一次参与跨桌面软件/PC Web/H5 的项目,第一次领略敏捷管理的魅力。在来自美国的技术 Leader 带领下,我接触到很多新领域,极大地开阔了技术视野。


“创业失败是要承担风险的,没有加薪,没有晋升,而且还是 996,直到项目成功”。第一次面试这个项目前,业务负责人,阿里工号 16 的虚竹告诉我。


不算幸运的是,最终这个项目没有取得如预期的成功,业务有了变化和调整。


但幸运的是:这段经历让我亲身体验了一把“创业”,也感受了技术以外的方方面面艰难。这个过程中形成的产品和业务思维,对我日后带来了深刻影响。当然,也在我之后几百次想离职创业时,这段经历让我能够静下心来思考创业的内核 - “为什么要创业?我有什么资源、能做什么事情、创造什么价值?”


忘了说,这段经历之所有特别,还因为办公地点在湖畔花园——马老师家。



湖畔花园办公场地


2012 年 7 月,加入到天猫的前端团队。 主管给予了充分的信任,让我负责天猫 H5 首页的研发,开始接触淘宝前端—— 一个更成熟完整的技术体系。


2012 年底,@三七 加入天猫带领前端团队,作为国内前端领域最早的拓荒者之一,他在随后的两年时间给天猫的前端技术带来体系化的变革——从模块化到工程化再到生产环境的 NodeJS,并引入了 Mobile First 理念。在他的支持下,我带领了一支前端小组陆续参与多条业务线的开发工作。我自己也加入集团级技术建设,主导跨端 Web 的项目,推进了前端体系的移动化建设。


除专业技术外,花了比原来更多的功夫在团队工作上,包括不限于团队氛围、风格和文化的打造,学会在内网分享中学习借鉴前辈大拿的的管理方法论。在阿里的文化中,非常强调传承。一个人牛不算什么,让一群人厉害才算厉害,最好是让下属比自己还强。


时间花在哪儿,结果就会在哪儿。团队内一些业务尖兵逐渐冒出头来,在后来几年成为天猫甚至大淘系的中坚力量。


这个过程既痛苦又快乐。痛苦在于要做越来越多的超过自己能力层级、远离舒适区的工作,快乐的则是能明显感知到自己在这个过程中的快速成长。


很幸运,在 14 年年中,顺利通过晋升(P7)。


P7:从双十一中打将出来 (2014.08 - 2016.01)


2014 年注定是难忘的一年。在这一年,我开始负责营销活动的业务,并担任 2014 年双十一前端技术 PM 工作。


营销活动是一个顶有趣、富有故事的业务:


从技术上:它可以极致简洁到切一个页面上线就行,也可以复杂到如双 11 一般 ——它是阿里技术的年度大考。


从业务上:它既可以简单到直接把现实生活的促销活动进行虚拟世界的进行流程投射,也能如互联网史上的春运般整合零售生态和供应链。


我和多个团队在天猫制定了各个维度的技术规范,如内控标准、外包规范,有惊无险地渡过了 14 年双十一。



在 PC 时代,营销活动的研发模式,对于前端来说,实在过于“简朴”:“5 到 6 位正式前端常年带着数十个外包,根据运营需求开发成百数千的页面,通过一个叫做 TMS 的运营系统预留坑位给运营同学填数据,交由后端应用推上线(CDN)。” 这类业务活动频次高、页面量大、协同成本高。某种意义上讲,对前端技术挑战并不高,为了更高效的研发,我们能做的是不断提高组件和模块复用率。


感谢 TMS,它帮助前端们快速迭代出一个又一个页面,支持了集团的业务,即使在今天,它的设计思路都能称得上精巧犀利。


发生变化来自 2014 年双十一前,线上发生了一次令我终生难忘的离奇故障(涉及敏感信息,略过细节):当时因临时未排查出原因,VP 现场观摩面,我和 CDN 运维团队的同学们能做的只是不断重启集群应用缓解问题。


我作为时任前端 PM,也因技术方案选择失误受到批评责罚。(时隔多年,大家也偶尔调侃,责罚不冤,幸而那天的问题提前暴露而未发生在 11.11 号当天,否则后果难料 )。


那年双 11 最终还是完美谢幕,GMV 571 亿,移动端成交 42.6% ,很多人敏锐的感觉到:移动化时代到来了。


之后技术复盘,我们针对问题做了多轮讨论和推演,决定启动一个代号“斑马”的产品项目:基于我们对营销的理解,运营的实际需求、过往的技术痛点,设计一个高效的页面系统来支持运营快速发布活动上线,更重要的是它是完全的基于 Mobile First 设计的系统。


正所谓 “一饮一啄,莫非前定” ,因为过去一年的打磨锤炼、痛过后的反思,我们很快把方案框架敲定,并和多个业务搭档共同推进项目实施。


项目于 15 年初立项,我代表团队“激进”的将阶段目标定为“支撑 2015 年 3 月的春季大促” 。这种既要支撑日常高频的大促业务,又要同时从 0 到 1 做平台研发,不啻于“飞行中升级引擎”,困难很大。但我背后的思考是:“这就如同创业,没有一往无前的决心和一鼓作气的气势,等想多了细了,多半就怂了怕了”。


我负责整个系统及 PM 工作,团队培养出来的中坚力量们承担各个功能模块研发。为实现我们心中所定计划,整个项目组如同创业般激情,为了一个共同的目标奋进。春节假期不少同学还在主动提交代码,节后迅速返回公司继续项目。


很幸运,克服了重重困难,“斑马”项目顺利上线,并成功支持了 2015 年第一个 S 级大促。基于新的系统,我们共同把营销活动送上新的轨道:因模块化带来的效率提升让我们完全解除了外包依赖、因具备跨端能力运营们可以单次同时进行 PC 和无线活动、我们设计并推动了 CDN 构架,单在 15 年双 11 就节省了数千万预算。


随着技术迭代,“斑马”这个技术产品,在后面几年成为阿里的基础运营平台之一。


2015 年 5 月,我参与了 P8 的晋升提名,结果未通过。Leader 和我沟通:“成长很快,能力和规划出色,业务成果需要时间验证”。我很坦然接收了建议,晋升答辩中的技术评委的建议中肯不失公正,让我受益很大。


“但行好事,莫问前程”——在随后的时间,“斑马”的能力更为完备。我再次担任了 2015 年双 11 的前端 PM 工作,业务也顺利上线。那一年,双 11 当天 GMV 912 亿,移动端成交 68%。


16 年 1 月,新主管告诉我,绿色通道通过,晋升至 P8。



双十一令牌/虎符


P8:立足业务,敢想敢造 (2016.02 - 2019.07)


一次偶然的机会,看到一张图 :如遵循民意苹果手机会变成什么样?给我带来一些对业务和技术的思考:“页面发布系统本质上是一个通用的工具平台:前端/运营/设计师都是它的用户,每个角色都有对它的功能需求。但每个新增功能在解决一类用户需求的同时又增加了平台复杂度,降低的客户的易用性,丢失掉另一类用户的民心。”


“这兴许是一个产品的轮回宿命”,我内心有些敬畏地想。带着这个敬畏,时间到了 2017 年,随着斑马的功能日趋复杂,我决定将运营操作平台和底层技术能力进行剥离:


将斑马定义为运营系统,专为运营打造极致的页面搭建。


将底层能力抽象成服务平台(代号“天马”),提供开放的研发标准、搭建方案、页面渲染能力。


随着时间推移,“天马”的开放能力不断完善,越来越多的事业部基于它构建面向业务的平台系统,带来的技术回报是:技术复用减少从 0 到 1 的研发 &硬件成本、标准统一使跨业务协同变为可行。


而在技术的另外一边,业务发生着悄无声息的变化:16 年双 11GMV 1207 亿、17 年双 11 则是 1682 亿。每年双十一在如此巨大的基数下还能持续业务高增长,个性化算法、推荐技术的大规模应用起到了非常重要的作用。在全局效率上,大数据优于人工干预逐渐得到了共识。在我看来,这些变化意味着时下大家认可的大促会场模式,也将带来新的变化。


2018 年 2 月,我在内部做了个分享,描述了对营销活动未来的预判:


业务化:面向“活动”组织,而非页面。


产品化:构建常态化、心智化的大促产品矩阵,而非单纯是模块级的抽象。


智能化:投放算法化和规则化,而非运营的动态化。


基于以上预判,我和团队的小伙伴,计划联同业务、上下游技术团队共同构建一个面向营销活动的平台产品(项目代号:方舟)。


很感谢历任主管实仙/四虎的信任,愿意帮我顶住重重压力,经过多轮沟通,我们达成了一致共识。


和过去几年稍有不同的是,我逐渐把包括不限于方舟的一些重要产品放手给团队中的骨干/TL,让他们去规划、去驱动、去变革。我更多做了辅导性、资源性、业务判断的全局性工作。


随着时间的推移,越来越多的结果开始凸现:


斑马逐渐成为集团级的通用平台,数万小二同学用它发布管理业务。


方舟作为业务平台交付成为大促体系的核心部分,并成功应用到双 11 期间,在效率、效果和交付质量上取得瞩目的结果。


天马通过“开放共建、出海上云”,为集团多个 BU 提供基础的技术搭建服务。


在业务中,团队中沉淀出一个个技术产品:渲染引擎、API 聚合网关等,也把曾经仅服务于内部的产品开放到商家、ISV。


在 2018 年中,提名参加晋升面试,结果未通过,技术委员会的评委们建议更多参与“集团级的技术建设、更高格局的视野”。


我很快走出了沮丧,毕竟在阿里,常胜不常有失败倒常伴。更重要是,主管 @四虎 的开导让我开始思考更全局的未来。


随后的时间,我继续投入了 2018 的双 11 前端整体工作,推进了多个端技术方案落地天猫。感谢阿里前端技术委员会主席圆心的举荐,我加入前端委员会,担任搭建技术方向的 Sponsor - 旨在站在集团视角,定制标准、融合并打通搭建技术体系,在更大范围内赋能业务。


在集团内各个前端 Leader 的支持下,我们很快跨多个事业群达成了共识,制定完善了技术标准,基于一体化方案启动了多个层面的项目。


2019 年 5 月,参加了年度晋升,顺利通过 P9 晋升。感恩。


P9:不止于前端


现在,仍然有太多的事情值得去深入:


  1. 以双 11 为代表的大促前端体系仍然是业内最具技术挑战的业务场景之一,包括不限于客户端容器技术、服务端渲染(Node)、框架与组件体系、跨终端技术等综合应用。

  2. 阿里有数以亿计的消费者,如何为我们的消费者构建一个好玩有趣的互动购物体验,是我们这个团队一直需要探索和改进的。

  3. 在未来,源自于前端的搭建技术,不仅能支持小二还能服务生态角色,不仅能支持国内还要服务全球。


除以上,我也深度参与阿里前端技术委员会的工作:


在阿里的前端体系,除了搭建方向以外,有相当数量的跨事业群共同建设的技术方向 &项目,包括不限于 Serverless、IDE、智能化、中后台、数据可视化、工程化、Node 技术等。这些技术方向或者始于前端,但又不止于前端,共同为打造行业领先的技术生态服务。


本文转载自技术琐话公众号。


原文链接:https://mp.weixin.qq.com/s/W7QGj3OqAbX8gDlna2jg7g


2020-04-23 17:381118

评论

发布
暂无评论
发现更多内容

第二周作业

极客大学架构师训练营

透过本质和发展看编程

拈香(曾德政)

架构师 面向对象设计 极客大学架构师训练营 面向对象设计原则

架构师训练营第二周学习总结

王鑫龙

极客大学架构师训练营

设计原则

GalaxyCreater

架构

你不会还不懂依赖倒置吧?赶紧来看看

hellohuan

设计模式 极客大学架构师训练营 设计原则

视频豪横时代,应用如何快速构建视频点播能力?

阿里云Edge Plus

音视频 CDN 直播 点播

架构师训练营第二周命题作业

hifly

设计模式 极客大学架构师训练营 UML 依赖倒置原则 接口隔离原则

架构师训练营 Week02 学习心得

极客大学架构师训练营

架构师训练营2 ——框架设计

默默

第 02 周学习总结

夏秋

软件的本质与设计原则

dony.zhang

学习总结 -- Week2

吴炳华

极客大学架构师训练营

0期架构Week2作业1

Nan Jiang

【漫画】云通信企业公众号,打造私域流量的利器

阿里云Edge Plus

云通信

架构师训练营——第二周总结

jiangnanage

架构师 0 期 | 架构师怎样实现架构目标?

刁架构

设计模式 极客大学架构师训练营

作业

chenzt

第 02 周作业

夏秋

极客大学架构师训练营

架构师训练营第二周学习总结

whiter

极客大学架构师训练营

架构师训练营第二周命题作业

兔狲

作业

江帅帅:精通 Spring Boot 系列 05

古月木易

Spring Boot

第2周作业

娄江国

极客大学架构师训练营

DIP和SIP的理解和学习

拈香(曾德政)

极客大学架构师训练营 面向对象设计原则 DIP 设计原则 SIP

江帅帅:精通 Spring Boot 系列 05

奈学教育

Spring Boot

聊聊面向对象的设计(OOD)原则

Jerry Tse

极客大学架构师训练营 作业

架构师训练营第二周作业

Jerry Tse

极客大学架构师训练营 作业

0期架构Week2作业2

Nan Jiang

7-ELEVEn工作法

wujunmin

管理 零售

设计一个软件框架的关键点

dony.zhang

银行业数据治理之「数据资产管理」

数据司令

大数据 数据仓库 金融科技 数据治理 数据资产

【架构师第二周作业】依赖倒置

浪浪

从P4到P9, 在马云家写代码到双11前端PM_文化 & 方法_技术琐话_InfoQ精选文章