本文是一个业务前端对如何支撑好业务，以及在这过程中如何获得个人成长的总结。一些心路历程的变化可能不是在某个瞬间，而是在实践过程中潜移默化形成的。

缘起

本人自 14 年校招加入淘宝 UED（淘系前端前身）后，一直从事淘宝的业务前端开发工作，至今已有 8 年多。一直想对自己已经度过的四分之一职业生涯（如果我能干 30 年的话）做个简单总结，无奈『拖延症』严重，直到年前被邀约做年终总结时，才下定决心，于是有了这篇文章。

本文是一个业务前端对如何支撑好业务，以及在这过程中如何获得个人成长的总结。一些心路历程的变化可能不是在某个瞬间，而是在实践过程中潜移默化形成的。

关于我

在职业生涯前五年，我是一线开发，期间也承担过虚拟 TL 的工作；从 19 年开始，成为淘系基础链路（现在是用户产品技术）的前端负责人；在业务方面，我先后支撑过一淘（海淘&特卖）、淘宝教育、淘宝 PC 首页、淘系店铺、淘系基础产品（首页、信息流、商品详情、交易、消息）等。在技术方面，做过跨端（Weex/小程序/Hybrid）、搭建、全栈、开放（二方&三方）、数据（体验度量&监控）等；

我经历的那些心路历程

为什么做前端

我本科读的是信管，在新生见面会时被系主任种下了要读博才能在本专业有所成的种子。于是顺理成章又上了几年学，读研期间进行文本挖掘领域的研究工作。在完成词语与句子的研究之后，受限于语料库无法在篇章层面更进一步，遂决定投身工业界。

在找实习碰一鼻子灰之后，我发现自己没想清楚未来要做什么，也没有擅长的领域。调研（碰壁）了一系列方向之后，我感觉还是可以当个程序员。于是钻研了一段时间的 C 与 PHP 后，我顺利加入到做淘宝直通车的创业公司实习。在此非常感谢创业公司老板杨哥给菜鸡的我学习的机会。实习期间几乎天天早九晚十，一个人负责网站的数据库设计、接口封装与 UI 实现。我也首次接触到前端页面开发的工作，我发现前端比后端（PHP）有意思多了，一行代码就能改变世界。在实习结束后，我把学校图书馆里能找到的前端相关的书都看了一遍，也跟拿到其他公司 offer 的师姐取了很多经；在研二暑假时到人人网实习并在校招时加入淘宝 UED。

总结下，本科期间系统学习了管理学与计算机科学的相关的基础知识，大概处于什么都会又什么都不会的阶段；研究生期间培养了自己发现问题、定义问题与解决问题的能力。回首大学与研究生生涯，我认为这个阶段最重要的是找到自己热爱并且能够充分发挥自己比较优势的领域，并为之努力，为自己长久的职业生涯做准备。

做好本职工作

正式工作后，我的工作主要围绕如何快速融入团队，获得快速成长，在支撑好业务的同时证明自己的能力。也可以总结为既快又好（保质保量）的完成业务需求，同时获得技术成就感。

在业务支撑方面，我没遇到太多的挑战，可以高质量快速完成分配给我的任务，例如，正式入职第一个月我就独立负责了当时一淘最大的营销活动——88 海淘节，2 周时间开发了十几个页面。这期间有个小插曲，稍微有点追求完美的我，在视觉还原方面一直很自信，当我自信满满的把做好的 demo 发给设计师体验时，设计师非常诧异的问我，线（边框）呢？我更诧异了，什么线，哪有线（事后发现是我显示器的像素太低，#999 的边框在我显示器上不显示）。

在技术方面主要是快速学习，并尝试做些改变。这段时间，我对各种技术方案充满好奇，想知道某某功能、组件、库是如何实现的，背后的原理是什么，造了大量轮子。大概包括三个层面，第一、纯粹造个轮子，没实现过的库/组件都自己重新实现一遍，例如，waterfall 组件/分页组件/jQuery 等；第二、尝试换个理念重新实现轮子，例如，有段时间特别想解决业务代码里回调地狱的问题，学习了有限状态机的编程模式，并把该理念应用到多个业务项目中。详细参考 基于有限状态机的JavaScript编程；第三、尝试前端领域一些新特性或者新框架，15 年年初用 React 重构了一个页面，不过学艺不精没有享受到 React 带来的好处，反而在状态管理方面遇到了不小的挑战。

在融入方面，认真的写好每天的日报、周报，积极参与团队内部分享与 coding 比赛等，也拿了些奖。常言千里马常有而伯乐不常有，但你需要先证明自己是千里马，那么日报、周报、周会就会成为展现你实力的舞台。

总结下，在这个阶段，我对各种新技术充满好奇，愿意花时间去学习与验证，以实现技术的自我满足与自我成长；业务对我而言是个非常称职的前端，但可能也仅此而已。

把事情做到极致

随着对业务的理解加深，以及该了解的技术都了解之后，面临的问题是如何把一件确定性的问题解决好，做到超出大家的预期——把事情做到极致。从这个阶段开始，我基本不会为了技术而技术，技术是我解决业务问题的手段与工具。

如何把事情做到极致呢？前提是要熟悉我们的业务，即他的用户是谁，他为用户解决了什么问题；通过竞品调研、内部广泛沟通与自身体验，确认理想与现实的差距，进而确认业务痛点。有了方向之后，我们需要定义一个有挑战且大家广泛认同的目标，注意这里的目标不是你认为的有挑战的目标，而是这个领域里专家（业务&技术）认为有挑战的目标；在制定策略时，最好能够借助团队的力量，顺势而为；在设计技术方案时，重要的是找到最合理的路径，而不是技术挑战最大方案。

在 15 年做淘宝教育时，图片是淘宝主流的素材，视频是非常少的，手淘甚至不能全机型播放视频，更别提横全屏播放了。但对淘宝教育的用户来说，买课看视频是最基本的诉求。为了解决视频播放问题，我尝试了 Native 与纯 Web 方案，几乎把实验室所有机型都测了一遍，但部分机型依然会黑屏。在穷途末路之际，发现 UC 正在推进 UC 浏览器内核接入手淘。我尝试联系了 UC 播放器的同学，大家一拍即合，在解决 Android 播放问题的同时也帮助 UC 播放器在手淘内落地。在 iOS 端为了解决横全屏播放的问题，先是脑洞了下用 CSS3 旋转的 Video 的方案，后续又脑洞了下旋转 WebView，至此彻底解决全屏播放问题。

总结下，要把事情做到极致，最核心的是要找个好的目标，评判的标准也很简单，当你跟大家说你要做 xx 时，看大家的第一反应是什么？如果是你怎么做到的？那么恭喜你找到了一个非常好的目标；如果大家反应是你为什么要做，那么你可以再探索探索。

数据驱动

如果只做一个业务，在把已知的问题都解决了之后，我还能做什么，这个事情曾经困扰了我一段时间。本质上是在 0->1 的功能实现之后，如何才能做更深次的突破。我找到的答案是数据驱动。

我对数据有种信仰，相信数据能够帮助我发现问题与解决问题。数据驱动具备以下几个特点。第一，数据思维，即从感性分析到理性分析。感性是主观上认为好与不好，但是否真的好或者不好不确定。理性分析是建立在逻辑与数据分析基础上的。以淘宝教育视频播放为例，直观感受是视频不能播放，时不时黑屏；用数据说话应该视频只有 95% 播放能成功。第二、数据价值，从关注功能价值，即从无到有，从 0 到 1；转变到更关注长期价值，实现从 1 到 99 的突破，即高质量的发展。第三、数据能力，我们需要具备数据的分析、处理与解读能力，例如，写 SQL 跑数据。

16 年我接手了当时还是 DAU 几千万的淘宝 PC 首页。在设定目标时，主管问我『你准备做什么？』，我跟前任，PD，开发都聊了聊，又自己调研了一番，觉得性能优化还有空间（首页作为淘宝的面门，性能一直是很好的）。于是我跟主管说我要做性能优化，他说好『要不暂定 20%』？我当时就慌了，之前都做那么好了，在没有大的技术变革之前，感觉有点难。我又找了当时 TMS 的负责人嗷嗷（首页的前前任主管），他说『如果你要做就把性能提升一倍，要不然就别做了』。于是我又找了释然（首页前任的主管），他说『好啊，那你就做到第一』。这时我就更加郁闷了，天猫首页首屏基本是一个大 slide，而淘宝首页支持千人千面，首屏就有 10+ 个接口。郁闷之后，虽然不知道如何达到，但也知道大家对这件事情的普遍认知；于是我开始定目标、确定数据平台、做 A/B 等，通过数据观测每次优化后的效果以及潜在空间。通过一系列操作之后，终于在 17 年元旦时达成了目标。

业务增值

当我们有众多选择的时候，如何判断哪个是最重要的。一个技术团队做什么才能对公司产生最大的价值。

当我们在设定技术目标与规划技术体系时，通常会按照体验、稳定性、效率（降本提效）等维度去拆解；但每个人（团队）的精力（资源）都是有限的，我们应该如何选择，如何判断事情的轻重缓急。要回答这个问题，我认为要回归到商业本身。商业的本质是交易，商业公司存在的价值在于创造了利润。对于电商公司而言，利润的大小很大程度上取决于用户规模与交易规模，而利润增长的来源可以是开源也可以是节流。同时，我们应该认识到在商业公司里，技术存在的价值是以实现业务价值为前提的，不存在为了技术而技术；如果有也是为了实现业务未来潜在的长期价值。因此，我们要根据业务短期目标与长期目标来构建我们的技术体系，通过技术目标的达成来牵引业务目标的实现。

我从 19 年开始负责淘系基础产品前端团队时，当时面临的问题是如何让这个小团队产生更大的价值。我们都知道，技术团队是擅长做研发提效的。但不到 10 个人的小团队，即使设置一个远大的目标——效率提升一倍，人员减半。但这个收益对公司来说杯水车薪，且不可持续；转换下视角，我们是否可以帮助淘系实现电商 GMV 的提升呢？我们可以做个简单的推导 GMV = 客单价 订单数，订单数 = DAU 浏览转化 * 成交转化；我们团队负责的商品详情、购物车与下单是『成交转化』最核心的三个产品。淘系每年的 GMV 规模是几万亿，如果我们能将交易转化提升 1%，那就是几百亿。目标看起来不错，听起来也有吸引力，那么如何去做呢？我们可以把交易转化的产品流程转为用户交互与数据通信的漏斗模型；那么做交易转化提升就可以转化为：去除漏斗中的某个流程，或提升某个流程的转化率。根据这个策略，我们团队在 H5 与小程序交易链路上做了稳定性改造、对标手淘的能力补齐、体验升级与产品优化等一系列优化，帮助业务实现年化预计几亿到几十亿的 GMV 增量。一个前端的追求可以是什么？是自己的代码跑在亿万用户的设备上，更是一行代码就可能带来百万、千万甚至上亿的商业价值。

技术敢为业务先

技术团队接需求、做需求总是简单的。在电商竞争越来越激烈的今天，作为一个技术团队如何帮助业务从不确定性中寻找确定性，让业务走的更快、更远。

伟人对领导有个通俗的定义『坐在指挥台上，如果什么也看不见，就不能叫领导。坐在指挥台上，只看见地平线上已经出现的大量的普遍的东西，那是平平常常的，也不能算领导。只有当还没有出现大量的明显的东西的时候，当桅杆顶刚刚露出的时候，就能看出这是要发展成为大量的普遍的东西，并能掌握住它，这才叫领导』。技术应当比业务领先半步，为了业务提前做技术布局，挖掘出现在可能不是但不久可能是业务强诉求的事情。从宏观层面看，我们需要了解国家政策、行业格局与技术趋势；在微观层面我们需要知道自己的业务从哪里来，未来走到哪里去；并结合自己团队的技术现状与人员储备提前做调研与分析。

从 19 年开始，国内移动互联网流量逐步见顶，越来越多的淘系业务希望从其他渠道（尤其是支付宝）获取更多流量。在 18 年淘宝与支付宝小程序架构合并之后，小程序是最适合做多 APP 投放的跨端方案。但当时淘系电商只支持 Native 与 H5 两种方案，前者投放到其他 APP 成本非常高；后者在管控、安全与体验方面存在较大的瓶颈。基于上述判断，我们做了详情与交易链路的小程序化改造，将基础链路新奥创 + DX 的技术方案适配到小程序场景中，形成小程序电商套件。该方案较好的满足业务可管控的开放诉求，页面性能方面也有一倍左右的提升。虽然项目立项时希望接入小程序的业务并不多，但在 20 年迎来了爆发式的增长。该方案也为后续适配微信小程序奠定了基础。

当下的突破

尝试做好一个业务的技术负责人——技术 PM

虽然从负责淘宝首页时，我就开始担任技术 PM 的工作，后来也在多个项目中担任技术 PM 工作。但这些项目所涉及的技术栈与技术方案是我熟知的，项目的规模也比较小，整体风险可控。从 22 年 7 月，我开始负责信息流二跳——ND 的技术 PM 工作。ND 是一个沉浸式无尽内容与商品的信息流产品，业务量级（几十亿PV）、战略地位（淘系前三）、团队协同规模（小100人）与技术复杂度（端侧 Native/Weex，数据服务 TPP工程与算法、调控）等方面远超过我之前负责的项目。到目前为止，摸爬滚打的半年多，虽然远称不上做的好，但也有些感悟：

职责：

前端业务支撑与技术负责人的差别是，前者是面向岗位做需求交付，后者是面向业务做研发结果交付。前者只需要做好自己就好，后者需要协同多个产品与技术团队，排除各种不确定风险，为业务带来确定性的交付；

视角：

技术 PM 不但需要具备端到端的技术视角，同时需要具备业务视角；前者不但要懂前端，懂客户端、还要懂服务端与算法；后者从宏观层面要理解公司战略、业务目标、业务策略、策略到产品落地等；微观层面要理解业务的核心指标，看报表、切流、A/B 等。

组织：

复杂多团队协同的项目管理，依靠个人无法把握项目全貌，需要借助组织与团队的力量。应该花更多时间调研现状与问题，制定大家广泛认同并行之有效的规则来解决这些问题。

业务：

导购链路与交易链路的最大差别是——敏捷。在交易链路里，系统的设计是在确定性的业务流程里产出确定性的结果。在系统运维方面也是以稳定性为前提，正常的发布节奏每周一次。但在导购链路里，系统的设计是在标准的数据处理流程里产出最佳的业务效果，数据结果的内容是多变的，不确定性的。我们曾经做过一次发布统计，在 ND 前端几乎每天发布一次，自我感觉已经很快了；但服务端（工程&算法）每天可以发布几十次。最近几年千人千面的个性化算法大放异彩，原因之一是有一套低成本快速试错的基础设施，线上时刻跑着 N 个实验，优中选优；

尝试做好一个技术产品

从 17 年底开始，我一直在负责淘系前端的监控产品——JSTracker。持续投入这个领域的原因是，我坚信在业务与技术体系越来越复杂的背景下，通过线上大数据的分析与挖掘才是保障业务体验与稳定性的唯一出路。这个产品大概经历了以下几个阶段：

可用性升级：

JSTracker 是集团最早的监控平台，由于年久失修，在我接手时几乎处于不可用状态，每逢大促必降级，在最需要监控的时候反而不能使用。因此，这个阶段我主要是重构了底层的数据链路（采集+流计算/离线计算+存储）与产品 UI 大升级，并首次平稳度过了双十一，DAU 从原来的个位数上涨到 20~30；

端到端的监控升级：

在可用性问题基本解决之后，工作重点转到丰富平台数据，降低业务的接入成本。开始接入各种端到端的数据源并打通内部各种业务平台、运维平台与发布平台，DAU 提升到 50；

领域深度建设：

当端到端的数据源都接入之后，需要构建平台的核心竞争力与影响力。于是从 20 年开始参与到集团前端委员会共建，首次提出并建设了端到端的灰度监控与跨端性能度量方案，其中团队自研的首屏算法在准确性与效率上有明显突破。并通过安全生产推动业务治理提升健康水位，团队也在 20 年首次上了 D2 的演讲，DAU 也上涨到 100；

终端时代：

随着 22 年淘系前端从横向支撑到业务垂直化，以及终端工程师的岗位设立。平台定位建设跨端体验度量、安全生产（发现与定位）、用户交互分析三个方向。为了解决不同跨端技术方案导致度量体系不统一的问题，协同手淘 Native、Weex、PHA、Flutter 架构组以及魔兔、JSTracker、TMQ、ATS 平台共同推出淘系跨端容器页面耗时标准并在容器与观测平台落地，成为手淘的统一标准；为了加快线上问题的排查效率，协同手淘基础架构，跨端架构，魔兔完成全链路日志（渲染容器日志、网络库日志、后端接口日志、业务监控日志）的串联，为手淘线上问题快速排查奠定新的基础。团队也连续三年上了 D2 的演讲，DAU 也来到了 170。

个人的感悟主要有以下几个方面：

1、学会延迟满足，当你坚信自己的判断是对的，那么就应该持续投入，然后等待开花结果的那一天。

2、技术产品要明确自己的定位，构建自己的核心竞争力。应该避免大而全，什么都有也往往意味着样样普通。普通是没有竞争力的，即吸引不了用户，也留不住用户。

3、资源总是有限的，我们需要谨慎选择自己的投入方向，控制自己的欲望，识别最重要的问题把他解决好。

4、新成员的加入可能对技术产品的发展带来质的变化。

总结下，虽然做了很多年，但当前产品也仅处于可用的水平，未来如何设计一个好看又好用的产品还需要更多摸索。

尝试带好一个团队

从 19 年开始实线带团队之后，在团队建设方面有些实践，积累了点经验。但团队管理博大精深，还需要进一步学习与实践。

人：

招聘与人才培养是团队梯度建设的核心工作，寻找那些志同道合，能为团队带来业务与技术上改变的人才。知易行难，招聘时往往会陷入特定的挫折与压力而放低要求，明知不可为而为之。另外，对技术团队来说最重要的是公开透明，对每个人成员最重要的是真诚，真心希望每个人都得到自己想要的。团队规模某种意义上决定了管理的模式，10 个人与 30 个人的是不完全一样的。

事：

从个人到团队最大的变化在于，如何从个人成功转变为带领团队走向成功。个人是一人吃饱全家不饿，此处不留爷自有留爷处，所有的事情都是相对可控的。团队更多的意味着责任，帮助业务更好的发展，帮助团队成员更好的成长，跟合作伙伴更好的协同；成为业务的第一责任人与所有业务的 backup，团队迷茫时要成为大家前进的灯塔。

行：

作为 Leader 要控制自己的欲望，给团队成员更多的发展空间；尝试建立规则而不是自己动手干每一件事。更多的输出为什么要做，如何推导，而不是如何做。

one more thing

在 17 年晋升之后，对于个人与团队未来的发展与定位陷入比较长时间的迷茫。当时处于知道自己维持现状肯定不行，但又不知道该往哪走；跟主管 1v1 的时候吐了一番苦水，主管建议找展炎聊聊，于是趁着谈薪的节点跟展炎吐槽了一番。本来期待着展炎安慰下心灵，指引前行。没想到展炎第一句就是：『永霸这不应该啊，作为团队的核心员工你应该帮助团队找到定位….（大意如此，记不清了）』。聊完之后觉得费解，事后静下心，反复回思了谈话内容，确实是自己的问题，我除了吐槽之外并没做些力所能及的事情改变现状。追思读研时，在做课题研究时遇到类似的问题，我要做篇章级别的工作，但发现词语与句子层面的基础工作都没有，也是找导师吐槽了一番，然后停步不前。直到突然有天醒悟，既然没有词语、句子的相关工作，那不就说明这个小领域还是空间么，顺理成章的发了第一、第二篇论文；人总是会在似曾相识的地方连续踩坑，这时候需要有人拉你一把或者自己顿悟。在此也非常感谢展炎，指引了前进的方向，也给了满满期待。在日常工作过程中，不可避免会遇到很多挑战与阻力，这时候我们应该沉下心，做调研摸清现状，而不应过分强调当下的困难，无法自拔。这时候更需要有拨云见日的勇气与自信。

总结

本文是个人职业生涯至今的总结，受限于本人经历、业务与大环境等方面的限制，难免会存在很多不足与偏见。期待你找到自己的柳暗花明。最后以王国维治学三境界共勉。

昨夜西风凋碧树，独上高楼，望尽天涯路。

衣带渐宽终不悔，为伊消得人憔悴。

众里寻他千百度，蓦然回首，那人却在，灯火阑珊处。