本文是一個業務前端對如何支撐好業務，以及在這過程中如何獲得個人成長的總結。一些心路曆程的變化可能不是在某個瞬間，而是在實踐過程中潛移默化形成的。
作者 | 吳佐衍(永霸)
來源 | 阿裡開發者公衆号
緣起
本人自 14 年校招加入淘寶 UED（淘系前端前身）後，一直從事淘寶的業務前端開發工作，至今已有 8 年多。一直想對自己已經度過的四分之一職業生涯（如果我能幹 30 年的話）做個簡單總結，無奈『拖延症』嚴重，直到年前拾酒小姐姐邀約做年終總結時，才下定決心，于是有了這篇文章。
本文是一個業務前端對如何支撐好業務，以及在這過程中如何獲得個人成長的總結。一些心路曆程的變化可能不是在某個瞬間，而是在實踐過程中潛移默化形成的。
關于我
在職業生涯前五年，我是一線開發，期間也承擔過虛拟 TL 的工作；從 19 年開始，成為淘系基礎鍊路（現在是使用者産品技術）的前端負責人；在業務方面，我先後支撐過一淘（海淘&特賣）、淘寶教育、淘寶 PC 首頁、淘系店鋪、淘系基礎産品（首頁、資訊流、商品詳情、交易、消息）等。在技術方面，做過跨端（Weex/小程式/Hybrid）、搭建、全棧、開放（二方&三方）、資料（體驗度量&監控）等；
我經曆的那些心路曆程
為什麼做前端
我大學讀的是信管，在新生見面會時被系主任種下了要讀博才能在本專業有所成的種子。于是順理成章又上了幾年學，讀研期間進行文本挖掘領域的研究工作。在完成詞語與句子的研究之後，受限于語料庫無法在篇章層面更進一步，遂決定投身工業界。
在找實習碰一鼻子灰之後，我發現自己沒想清楚未來要做什麼，也沒有擅長的領域。調研（碰壁）了一系列方向之後，我感覺還是可以當個程式員。于是專研了一段時間的 C 與 PHP 後，我順利加入到做淘寶直通車的創業公司實習。在此非常感謝創業公司老闆楊哥給菜雞的我學習的機會。實習期間幾乎天天早九晚十，一個人負責網站的資料庫設計、接口封裝與 UI 實作。我也首次接觸到前端頁面開發的工作，我發現前端比後端（PHP）有意思多了，一行代碼就能改變世界。在實習結束後，我把學校圖書館裡能找到的前端相關的書都看了一遍，也跟拿到百度 offer 的師姐取了很多經；在研二暑假時到人人網實習并在校招時加入淘寶 UED。
總結下，大學期間系統學習了管理學與計算機科學的相關的基礎知識，大概處于什麼都會又什麼都不會的階段；研究所學生期間培養了自己發現問題、定義問題與解決問題的能力。回首大學與研究所學生生涯，我認為這個階段最重要的是找到自己熱愛并且能夠充分發揮自己比較優勢的領域，并為之努力，為自己長久的職業生涯做準備。
做好本職工作
正式工作後，我的工作主要圍繞如何快速融入團隊，獲得快速成長，在支撐好業務的同時證明自己的能力。也可以總結為既快又好（保質保量）的完成業務需求，同時獲得技術成就感。
在業務支撐方面，我沒遇到太多的挑戰，可以高品質快速完成配置設定給我的任務，例如，正式入職第一個月我就獨立負責了當時一淘最大的營銷活動——88 海淘節，2 周時間開發了十幾個頁面。這期間有個小插曲，稍微有點追求完美的我，在視覺還原方面一直很自信，當我自信滿滿的把做好的 demo 發給設計師體驗時，設計師非常詫異的問我，線（邊框）呢？我更詫異了，什麼線，哪有線（事後發現是我顯示器的像素太低，#999 的邊框在我顯示器上不顯示）。
在技術方面主要是快速學習，并嘗試做些改變。這段時間，我對各種技術方案充滿好奇，想知道某某功能、元件、庫是如何實作的，背後的原理是什麼，造了大量輪子。大概包括三個層面，第一、純粹造個輪子，沒實作過的庫/元件都自己重新實作一遍，例如，waterfall 元件/分頁元件/jQuery 等；第二、嘗試換個理念重新實作輪子，例如，有段時間特别想解決業務代碼裡回調地獄的問題，學習了有限狀态機的程式設計模式，并把該理念應用到多個業務項目中 ；第三、嘗試前端領域一些新特性或者新架構，15 年年初用 React 重構了一個頁面，不過學藝不精沒有享受到 React 帶來的好處，反而在狀态管理方面遇到了不小的挑戰。
在融入方面，認真的寫好每天的日報、周報，積極參與團隊内部分享與 coding 比賽等，也拿了些獎。常言千裡馬常有而伯樂不常有，但你需要先證明自己是千裡馬，那麼日報、周報、周會、ATA、coding 就會成為展現你實力的舞台。
總結下，在這個階段，我對各種新技術充滿好奇，願意花時間去學習與驗證，以實作技術的自我滿足與自我成長；業務對我而言是個非常稱職的前端，但可能也僅此而已。
把事情做到極緻
随着對業務的了解加深，以及該了解的技術都了解之後，面臨的問題是如何把一件确定性的問題解決好，做到超出大家的預期——把事情做到極緻。從這個階段開始，我基本不會為了技術而技術，技術是我解決業務問題的手段與工具。
如何把事情做到極緻呢？前提是要熟悉我們的業務，即他的使用者是誰，他為使用者解決了什麼問題；通過競品調研、内部廣泛溝通與自身體驗，确認理想與現實的差距，進而确認業務痛點。有了方向之後，我們需要定義一個有挑戰且大家廣泛認同的目标，注意這裡的目标不是你認為的 NB 的目标，而是這個領域裡專家（業務&技術）認為 NB 的目标；在制定政策時，最好能夠借助團隊的力量，順勢而為；在設計技術方案時，重要的是找到最合理的路徑，而不是技術挑戰最大方案。
在 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 的負責人嗷嗷（首頁的前前任主管），他說『如果你要做就把性能提升一倍，要不然就别做了』。我的内心的想的是 P8 的嘴，騙人的鬼。于是我又找了釋然（首頁前任的主管），他說『好啊，那你就做到淘寶、天貓、京東第一』。
這時我就更加郁悶了，京東首頁首屏是 SSR 直出，天貓首頁首屏基本是一個大 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工程與算法、調控）等方面遠超過我之前負責的項目。到目前為止，摸爬滾打的半年多，雖然遠稱不上做的好，但也有些感悟：
1、職責：前端業務支撐與技術負責人的差别是，前者是面向崗位做需求傳遞，後者是面向業務做研發結果傳遞。前者隻需要做好自己就好，後者需要協同多個産品與技術團隊，排除各種不确定風險，為業務帶來确定性的傳遞；
2、視角：技術 PM 不但需要具備端到端的技術視角，同時需要具備業務視角；前者不但要懂前端，懂用戶端、還要懂服務端與算法；後者從宏觀層面要了解公司戰略、業務目标、業務政策、政策到産品落地等；微觀層面要了解業務的核心名額，看報表、切流、A/B 等。
3、組織：複雜多團隊協同的項目管理，依靠個人無法把握項目全貌，需要借助組織與團隊的力量。應該花更多時間調研現狀與問題，制定大家廣泛認同并行之有效的規則來解決這些問題。
4、業務：導購鍊路與交易鍊路的最大差别是——靈活。在交易鍊路裡，系統的設計是在确定性的業務流程裡産出确定性的結果。在系統運維方面也是以穩定性為前提，正常的釋出節奏每周一次。但在導購鍊路裡，系統的設計是在标準的資料處理流程裡産出最佳的業務效果，資料結果的内容是多變的，不确定性的。我們曾經做過一次釋出統計，在 ND 前端幾乎每天釋出一次，自我感覺已經很快了；但服務端（工程&算法）每天可以釋出幾十次。最近幾年千人千面的個性化算法大放異彩，原因之一是有一套低成本快速試錯的基礎設施，線上時刻跑着 N 個實驗，優中選優；
嘗試做好一個技術産品
從 17 年底開始，我一直在負責淘系前端的監控産品——JSTracker。持續投入這個領域的原因是，我堅信在業務與技術體系越來越複雜的背景下，通過線上大資料的分析與挖掘才是保障業務體驗與穩定性的唯一出路。這個産品大概經曆了以下幾個階段：
1、可用性更新：JSTracker 是集團最早的監控平台，由于年久失修，在我接手時幾乎處于不可用狀态，每逢大促必降級，在最需要監控的時候反而不能使用。是以，這個階段我主要是重構了底層的資料鍊路（采集+流計算/離線計算+存儲）與産品 UI 大更新，并首次平穩度過了雙十一，DAU 從原來的個位數上漲到 20~30；
2、端到端的監控更新：在可用性問題基本解決之後，工作重點轉到豐富平台資料，降低業務的接入成本。開始接入各種端到端的資料源并打通内部各種業務平台、運維平台與釋出平台，DAU 提升到 50；
3、領域深度建設：當端到端的資料源都接入之後，需要建構平台的核心競争力與影響力。于是從 20 年開始參與到集團前端委員會共建，首次提出并建設了端到端的灰階監控與跨端性能度量方案，其中團隊自研的首屏算法在準确性與效率上有明顯突破。并通過安全生産推動業務治理提升健康水位，團隊也在 20 年首次上了 D2 的演講，DAU 也上漲到 100；
點選檢視原文，擷取更多福利！
https://mp.weixin.qq.com/s?__biz=MzIzOTU0NTQ0MA==&mid=2247532215&idx=1&sn=91ed9e74f4d0a93be2b277f3bb55549e&chksm=e92a43b8de5dcaaebad18450eb14a882aa7860dd55fc62e6a306995d02d390270489751f2d5f&token=552668333&lang=zh_CN#rd
版權聲明：本文内容由阿裡雲實名注冊使用者自發貢獻，版權歸原作者所有，阿裡雲開發者社群不擁有其著作權，亦不承擔相應法律責任。具體規則請檢視《阿裡雲開發者社群使用者服務協定》和《阿裡雲開發者社群知識産權保護指引》。如果您發現本社群中有涉嫌抄襲的内容，填寫侵權投訴表單進行舉報，一經查實，本社群将立刻删除涉嫌侵權内容。