本文作者永霸负责了淘宝PC改版,他坚信历史的发展是螺旋式上升的,那些只要认为是对的事情,未来一定会发生/被证实的。
缘起
本人自 14 年校招加入淘宝 UED(淘系前端前身)后,一直从事淘宝的业务前端开发工作,至今已有 9 年。一直想对自己已经度过的四分之一职业生涯(如果我能干 30 年的话)做个简单总结,无奈『拖延症』严重,直到年前被邀约做年终总结时,才下定决心,于是有了这篇文章。
本文是一个业务前端对如何支撑好业务,以及在这过程中如何获得个人成长的总结。一些心路历程的变化可能不是在某个瞬间,而是在实践过程中潜移默化形成的。
关于我
▐ 为什么做前端
我本科读的是信管,在新生见面会时被系主任种下了要读博才能在本专业有所成的种子。于是顺理成章又上了几年学,读研期间进行文本挖掘领域的研究工作。在完成词语与句子的研究之后,受限于语料库无法在篇章层面更进一步,遂决定投身工业界。
▐ 做好本职工作
正式工作后,我的工作主要围绕如何快速融入团队,获得快速成长,在支撑好业务的同时证明自己的能力。也可以总结为既快又好(保质保量)的完成业务需求,同时获得技术成就感。
在业务支撑方面,我没遇到太多的挑战,可以高质量快速完成分配给我的任务,例如,正式入职第一个月我就独立负责了当时一淘最大的营销活动——88 海淘节,2 周时间开发了十几个页面。这期间有个小插曲,稍微有点追求完美的我,在视觉还原方面一直很自信,当我自信满满的把做好的 demo 发给设计师体验时,设计师非常诧异的问我,线(边框)呢?我更诧异了,什么线,哪有线(事后发现是我显示器的像素太低,#999 的边框在我显示器上不显示)。
▐ 把事情做到极致
随着对业务的理解加深,以及该了解的技术都了解之后,面临的问题是如何把一件确定性的问题解决好,做到超出大家的预期——把事情做到极致。从这个阶段开始,我基本不会为了技术而技术,技术是我解决业务问题的手段与工具。
总结下,要把事情做到极致,最核心的是要找个好的目标,评判的标准也很简单,当你跟大家说你要做 xx 时,看大家的第一反应是什么?如果是你怎么做到的?那么恭喜你找到了一个非常好的目标;如果大家反应是你为什么要做,那么你可以再探索探索。
▐ 数据驱动
如果只做一个业务,在把已知的问题都解决了之后,我还能做什么,这个事情曾经困扰了我一段时间。本质上是在 0->1 的功能实现之后,如何才能做更深次的突破。我找到的答案是数据驱动。
▐ 业务增值
当我们有众多选择的时候,如何判断哪个是最重要的。一个技术团队做什么才能对公司产生最大的价值。
▐ 技术敢为业务先
技术团队接需求、做需求总是简单的。在电商竞争越来越激烈的今天,作为一个技术团队如何帮助业务从不确定性中寻找确定性,让业务走的更快、更远。
职责:前端业务支撑与技术负责人的差别是,前者是面向岗位做需求交付,后者是面向业务做研发结果交付。前者只需要做好自己就好,后者需要协同多个产品与技术团队,排除各种不确定风险,为业务带来确定性的交付;
视角:技术 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。
个人的感悟主要有以下几个方面:
学会延迟满足,当你坚信自己的判断是对的,那么就应该持续投入,然后等待开花结果的那一天。
技术产品要明确自己的定位,构建自己的核心竞争力。应该避免大而全,什么都有也往往意味着样样普通。普通是没有竞争力的,即吸引不了用户,也留不住用户。
资源总是有限的,我们需要谨慎选择自己的投入方向,控制自己的欲望,识别最重要的问题把他解决好。
新成员的加入可能对技术产品的发展带来质的变化。总结下,虽然做了很多年,但当前产品也仅处于可用的水平,未来如何设计一个好看又好用的产品还需要更多摸索。
▐ 尝试带好一个团队
从 19 年开始实线带团队之后,在团队建设方面有些实践,积累了点经验。但团队管理博大精深,还需要进一步学习与实践。
人:招聘与人才培养是团队梯度建设的核心工作,寻找那些志同道合,能为团队带来业务与技术上改变的人才。知易行难,招聘时往往会陷入特定的挫折与压力而放低要求,明知不可为而为之。另外,对技术团队来说最重要的是公开透明,对每个人成员最重要的是真诚,真心希望每个人都得到自己想要的。团队规模某种意义上决定了管理的模式,10 个人与 30 个人的是不完全一样的。
事:从个人到团队最大的变化在于,如何从个人成功转变为带领团队走向成功。个人是一人吃饱全家不饿,此处不留爷自有留爷处,所有的事情都是相对可控的。团队更多的意味着责任,帮助业务更好的发展,帮助团队成员更好的成长,跟合作伙伴更好的协同;成为业务的第一责任人与所有业务的 backup,团队迷茫时要成为大家前进的灯塔。
行:作为 Leader 要控制自己的欲望,给团队成员更多的发展空间;尝试建立规则而不是自己动手干每一件事。更多的输出为什么要做,如何推导,而不是如何做。
one more thing
在 17 年晋升之后,对于个人与团队未来的发展与定位陷入比较长时间的迷茫。当时处于知道自己维持现状肯定不行,但又不知道该往哪走;跟主管 1v1 的时候吐了一番苦水,主管建议找展炎聊聊,于是趁着谈薪的节点跟展炎吐槽了一番。本来期待着展炎安慰下心灵,指引前行。没想到展炎第一句就是:『永霸这不应该啊,作为团队的核心员工你应该帮助团队找到定位....(大意如此,记不清了)』。聊完之后觉得费解,事后静下心,反复回思了谈话内容,确实是自己的问题,我除了吐槽之外并没做些力所能及的事情改变现状。追思读研时,在做课题研究时遇到类似的问题,我要做篇章级别的工作,但发现词语与句子层面的基础工作都没有,也是找导师吐槽了一番,然后停步不前。直到突然有天醒悟,既然没有词语、句子的相关工作,那不就说明这个小领域还是空间么,顺理成章的发了第一、第二篇论文;人总是会在似曾相识的地方连续踩坑,这时候需要有人拉你一把或者自己顿悟。在此也非常感谢展炎,指引了前进的方向,也给了满满期待。在日常工作过程中,不可避免会遇到很多挑战与阻力,这时候我们应该沉下心,做调研摸清现状,而不应过分强调当下的困难,无法自拔。这时候更需要有拨云见日的勇气与自信。
总结
本文是个人职业生涯至今的总结,受限于本人经历、业务与大环境等方面的限制,难免会存在很多不足与偏见。期待你找到自己的柳暗花明。最后以王国维治学三境界共勉。
昨夜西风凋碧树,独上高楼,望尽天涯路。
衣带渐宽终不悔,为伊消得人憔悴。
众里寻他千百度,蓦然回首,那人却在,灯火阑珊处。
团队介绍
我们是大淘宝技术用户产品技术前端团队,主要负责商品详情、正逆向交易(下单、订单、退货退款等)、消息、社交等电商基础产品,在技术方面正在探索面向极致效率与体验的跨端混合容器方案、面向二方端到端开放的新奥创方案以及面向前端安全生产与跨端体验度量方案。