李成熙：前端如何突破技術(shù)與業(yè)務(wù)的瓶頸

作者：李成熙，Shopee 金融商家前端團(tuán)隊(duì)負(fù)責(zé)人。2014 年度畢業(yè)加入騰訊 AlloyTeam，先后負(fù)責(zé)過 QQ 群、花樣直播、騰訊文檔等項(xiàng)目。2018 年加入騰訊云云開發(fā)團(tuán)隊(duì)。2019 年加入 Shopee 金融前端團(tuán)隊(duì)任一線前端 Leader。專注于性能優(yōu)化、工程化和小程序服務(wù)。

微信轉(zhuǎn)載前，請聯(lián)系公眾號/作者，未經(jīng)許可不能轉(zhuǎn)載!

上次寫總結(jié)文章，是來 Shopee 剛好半年后，那時剛剛適應(yīng)從個人貢獻(xiàn)者到技術(shù)架構(gòu)師和管理者的身份轉(zhuǎn)變，有一些感悟與心得，拿出來與大家分享。又一年過去了，來 Shopee 已經(jīng)一年半，團(tuán)隊(duì)從剛開始時的 4 個人，到現(xiàn)在 18 人，公司股價，也從當(dāng)初的 20 美金，到 180 美金。很有幸，公司在進(jìn)步，我也在進(jìn)步。

今天主要想分享三個作為前端，可能經(jīng)歷的瓶頸，然后講講我為了突破這些瓶頸，所做的一些思考與努力。這三個突破，分別是

• 從個人貢獻(xiàn)者到技術(shù)架構(gòu)師與管理者轉(zhuǎn)變的突破
• 從帶領(lǐng)單項(xiàng)技術(shù)到帶領(lǐng)多項(xiàng)技術(shù)的突破
• 從帶技術(shù)到帶業(yè)務(wù)的突破

瓶頸一：從個人貢獻(xiàn)者到技術(shù)架構(gòu)師與管理者轉(zhuǎn)變的突破

其實(shí)這個可以從架構(gòu)能力與管理能力兩個層面講。咱們先來講一下架構(gòu)能力。

架構(gòu)師

所謂架構(gòu)能力，簡單地說就是將不同的模塊、組件、系統(tǒng)組裝起來，聯(lián)動發(fā)揮作用，解決業(yè)務(wù)或技術(shù)需求的一個過程，網(wǎng)上可能有更詳盡的解釋，大家可以自行去了解。開發(fā)者在個人貢獻(xiàn)者階段，更多只是接受架構(gòu)師指派的任務(wù)，完成自己一個小模塊的設(shè)計(jì)與代碼。而在架構(gòu)師的階段，要擔(dān)負(fù)起的責(zé)任與工作則更多，而且既要兼顧全局，有時也要 Review 細(xì)節(jié)的落實(shí)，有時候是又當(dāng)建筑設(shè)計(jì)師，又當(dāng)工地監(jiān)工。

作為架構(gòu)師，首先要對需求的把握非常清晰，一個是需求要落實(shí)的功能點(diǎn)，另一個是要考慮一些特性，譬如性能，未來的擴(kuò)展性等等。以最近我們計(jì)劃要做的一個產(chǎn)品的官網(wǎng)為例，這個官網(wǎng)比較核心的特性，一個是發(fā)布新聞、一些推廣活動還有常見問答，另一個是可以提供這些內(nèi)容的相關(guān)搜索，還有對個別商家做一些排行榜。

由于后臺的人力不足，我們是計(jì)劃由前端完成大部分的前端與后臺開發(fā)工作，這里就需要由一位既懂前端，又懂后臺的架構(gòu)師去設(shè)計(jì)把關(guān)這里的架構(gòu)（當(dāng)然分開架構(gòu)也可以）。這里你可能會有疑問，為什么前端的架構(gòu)師，有能力在這個需求里，對前后臺做架構(gòu)設(shè)計(jì)呢？前端的同事是何德何能可以承擔(dān)這里的前后臺開發(fā)呢？這里就涉及到技術(shù)管理的梯隊(duì)建設(shè)與才能儲備，咱們講管理的時候再詳聊。

基于該需求的特性，我們在做設(shè)計(jì)之前，還需要收集一下這個站點(diǎn)未來可能的訪問量（數(shù)據(jù)），這些數(shù)據(jù)對我們的技術(shù)選型非常關(guān)鍵！沒錯，我們點(diǎn)出了架構(gòu)第一個重要的環(huán)節(jié)，技術(shù)選型。據(jù)了解，該站點(diǎn)每天訪問量，每秒的并發(fā)都不大，基本不需要上到一些應(yīng)對高并發(fā)的手段。另外，由于要做內(nèi)容的全文搜索，如果通過數(shù)據(jù)庫的全文檢索，盡管使用量不大，但隨著內(nèi)容越來越多（運(yùn)營人員更新內(nèi)容的頻率還是很高的），查詢性能會越來越慢。而且我們的數(shù)據(jù)庫暫時跟一些核心交易數(shù)據(jù)放在同一個數(shù)據(jù)庫集群里，這種耗時操作可能會加大對數(shù)據(jù)庫集群的壓力，因此我們可能需要用到ElasticSearch幫我們做切詞與搜索。而對商家數(shù)據(jù)做排行榜，這個由于涉及到核心數(shù)據(jù)，我計(jì)劃是讓后臺的微服務(wù)出一個 API，再由咱們 Node.js(由于是前端來實(shí)現(xiàn)后臺能力，基于熟悉度的考量，用Node.js對于前端來說，開發(fā)與維護(hù)都相當(dāng)方便) 服務(wù)層去調(diào)用。

在技術(shù)選型的基礎(chǔ)上，架構(gòu)師平時積累的一些經(jīng)驗(yàn)、方法論、指標(biāo)關(guān)注面，在架構(gòu)設(shè)計(jì)中，也起到比較重要的作用。這里以團(tuán)隊(duì)做的熱更新服務(wù)、配置中心、運(yùn)營搭建頁面這幾個平臺為例。剛組建團(tuán)隊(duì)的時候，我們亟需熱更新平臺來給React Native提供動態(tài)更新的能力。這里當(dāng)時是采用了MySQL + Redis + Node.js + Serverless Function(做代碼差分)的架構(gòu)。

有了熱更新服務(wù)的經(jīng)驗(yàn)，后面在做配置中心和運(yùn)營搭建頁面的時候，也從中吸取了經(jīng)驗(yàn)，用了類似的架構(gòu)做數(shù)據(jù)的存儲與緩存。但隨著業(yè)務(wù)的發(fā)展，我們發(fā)現(xiàn)為了讓系統(tǒng)的可用性更高、性能更好，在一些場景里，對數(shù)據(jù)量比較大的讀取，經(jīng)常會將數(shù)據(jù)放到內(nèi)存里（Redis 讀取大數(shù)據(jù)也會有瓶頸）；另外在做差分的時候，為了保證準(zhǔn)確性，設(shè)計(jì)了一個任務(wù)隊(duì)列，保證任務(wù)不會被重復(fù)運(yùn)行，也安排了一些失敗重試、人工處理等的機(jī)制。在設(shè)計(jì)任務(wù)隊(duì)列的時候，我們有考慮過引入 Kafka 這類中間件，但實(shí)質(zhì)上用MySQL也能滿足到訴求，那考慮到可移植性，因此咱們直接就用MySQL頂上。上面講的這些例子，都是在業(yè)務(wù)發(fā)展過程中，架構(gòu)的演進(jìn)，并且在這種迭代的過程中，自己的架構(gòu)經(jīng)驗(yàn)與方法論也不斷豐富，日后遇到類似的問題，就像砌積木那樣子，搬出曾經(jīng)用過、思考過、驗(yàn)證過的種種方案，構(gòu)建成心目中的模樣。你可能會說，架構(gòu)師的工作難度蠻大的，時刻會遇到自己無知的領(lǐng)域，比如自己之前沒有用過的一些中間件，在真正面臨需求的時候，怎么會想得到？這里感覺并沒有捷徑，只有在日常工作中不斷涉獵，打開自己的眼界，才能在不斷變化的需求世界里更為從容。

小結(jié)一下，成為架構(gòu)師需要做到的事情：

1. 根據(jù)需求特性、指標(biāo)數(shù)據(jù)、團(tuán)隊(duì)熟悉度，做好技術(shù)選型。
2. 根據(jù)經(jīng)驗(yàn)、方法論、指標(biāo)數(shù)據(jù)，不斷豐富與完善自己的架構(gòu)方案與套件
3. 不斷學(xué)習(xí)，沒有捷徑

管理者

技術(shù)管理這個話題，可能講幾天幾夜也講不完，這里我只摘取我認(rèn)為最為重要與關(guān)鍵的一些做法與理念。在理念上，我認(rèn)為要讓大家高效工作、快樂工作，在實(shí)施上，要想盡辦法給團(tuán)隊(duì)、給成員賦能。

從業(yè)界的趨勢來看，許多業(yè)務(wù)、技術(shù)領(lǐng)域也已經(jīng)走到了深水區(qū)、國際比較前沿的階段，不是簡單的拼人力、拼時間就可以將事情做對、做漂亮的，讓大家抱著快樂的心情，發(fā)揮自己的創(chuàng)造力地去做事情，比讓大家拼盡一切時間，還時不時在工位摸魚，更能可能將事情做好。畢竟我們是將要在國際舞臺上跟巨頭拼刺刀的公司，在找對方向后，跟時間賽跑是沒問題的，但在找對方向之前盲目地虛耗大家的精力與創(chuàng)造力，可能會引發(fā)一將無能，累死三軍的局面。

高效工作，可以從個人與團(tuán)隊(duì)兩個角度進(jìn)行賦能。

個人層面上，本質(zhì)就是希望個人的能力不斷提升，大家能夠找到自己發(fā)展的目標(biāo)，技能上做到一專多長，并且最終達(dá)成為一位自帶“體系”的技術(shù)人。譬如今年我們團(tuán)隊(duì)來了一位 React Native 的大牛，自己的曾經(jīng)的創(chuàng)業(yè)項(xiàng)目也是整體用 React Native 搭建 iOS和 Android 的 APP。但 React Native，有一個很重要的特性就是熱更新，在他之前的項(xiàng)目里還沒用到過，更別說自研了。來我們團(tuán)隊(duì)后，有契機(jī)讓他參與熱更新項(xiàng)目的研發(fā)，并且也讓他多了解客戶端實(shí)現(xiàn)這套體系的一些基本的邏輯。后續(xù)如果公司有新的業(yè)務(wù)有需要到 React Native，那這位同事就可以作為自帶“體系”的架構(gòu)師，去幫忙搭建業(yè)務(wù)的架構(gòu)，促進(jìn)業(yè)務(wù)的發(fā)展。

團(tuán)隊(duì)層面上，做好模塊劃分、流程優(yōu)化、技術(shù)規(guī)劃與梯隊(duì)建設(shè)。

所謂模塊劃分，就是大家在相對穩(wěn)定的模塊中工作，當(dāng)你比較熟悉業(yè)務(wù)邏輯的話，工作都相對容易。當(dāng)然對相似工作內(nèi)容產(chǎn)生倦怠人皆有之，這個又可以開另一個專題闡述了。早期我在這里也踩過一些坑，也是由于團(tuán)隊(duì)早期的業(yè)務(wù)比較緊，盡管同事還是會盡量做他們熟悉的模塊，奈何不同的版本，不同模塊的業(yè)務(wù)壓力大小不盡相同，會經(jīng)常抽調(diào)同事去負(fù)責(zé)全新的模塊，這樣其實(shí)對工作的效率與質(zhì)量都是不利的，花的時間長，產(chǎn)生的 BUG 也多。所以后續(xù)也盡量讓人員相對更加固定，即使后續(xù)某個模塊非常忙，也盡量由負(fù)責(zé)該模塊的同事主導(dǎo)業(yè)務(wù)開發(fā)的工作，支援的同事需要在良好的指引下（文檔一定要完備）開展工作。

流程優(yōu)化，即使減少工作中的流程對研發(fā)人員帶來的桎梏。工作流程有許多，創(chuàng)建新項(xiàng)目的流程，如 Git 工作流、任務(wù)工作單管理流程等等。如何優(yōu)化流程我認(rèn)為主要是識別反人性的流程，然后用工具優(yōu)化之。這里以團(tuán)隊(duì)中的任務(wù)工作單流程優(yōu)化為例，在 Shopee，研發(fā)團(tuán)隊(duì)有采用一款任務(wù)工作建單平臺做研發(fā)流程的管理的，大家都會在這個建單平臺上面記錄工作量以及扭轉(zhuǎn)狀態(tài)。團(tuán)隊(duì)剛開始的時候人比較少，誰忙誰閑一目了然，但隨著團(tuán)隊(duì)人員不斷增加，單純通過肉眼、心算去看看大家的忙閑程度，分配工作就變得極具挑戰(zhàn)性了，在沒有工作的幫助下，管理半徑就會限制在 5 - 8 個人左右，而且為了分配工作會把自己忙死——要做大量的手動統(tǒng)計(jì)工作。于是為了提供管理的效率，我決定寫了一個腳本，幫我通過建單平臺的開放 API，將團(tuán)隊(duì)內(nèi)成員的工作量，全部都拉下來放到 Excel 里被自動將工作量總量統(tǒng)計(jì)出來。這樣分配工作，只需要跑一個腳本，就可以輕松統(tǒng)計(jì)出每個人的已經(jīng)排的工作量。當(dāng)然，如果能統(tǒng)計(jì)出甘特圖是最完美的，但受限于個別數(shù)據(jù)團(tuán)隊(duì)沒有要求填（比如工作開始時間），因此就無法畫出來。

除此以外，由于項(xiàng)目經(jīng)理一些研發(fā)統(tǒng)計(jì)的需要，對每個同事建任務(wù)單的要求、填字段的數(shù)量都越來越多。將心比己，即使是我本人作為 member，都可能會疏忽未能填寫完成準(zhǔn)確。這些措施對管理上可能會更加方便，但對每個研發(fā)來說都會增加負(fù)擔(dān)與困擾。于是我們也計(jì)劃做一些工具與平臺，一方面方便管理者做統(tǒng)計(jì)，另一方面也減少研發(fā)人員在一些行政、流程上的事情浪費(fèi)過多的時間。

技術(shù)規(guī)劃，主要就是引領(lǐng)整個團(tuán)隊(duì)的技術(shù)方向，并努力將之落地，這個是技術(shù)管理者體現(xiàn)價值的非常重要的環(huán)節(jié)。因?yàn)槟K劃分、流程優(yōu)化，有做導(dǎo)師帶過小項(xiàng)目之后，都能得心應(yīng)手，但技術(shù)規(guī)劃，怎么順應(yīng)著業(yè)務(wù)的發(fā)展變化，提前做一些技術(shù)的儲備與布局，怎么將團(tuán)隊(duì)的技術(shù)水平帶到業(yè)界一流水平，這個是當(dāng)上技術(shù)管理者之后才能得到的體會。

所謂的規(guī)劃，不能是單點(diǎn)的突破，而是需要多點(diǎn)，并且點(diǎn)連成線面；不能只著重于一個個工具與平臺的建設(shè)，而更要關(guān)注這些工具與平臺如何有機(jī)地結(jié)合在一起，協(xié)同發(fā)揮作用，形成體系。當(dāng)然，也需要這些技術(shù)與時俱進(jìn)，在技術(shù)的規(guī)劃前路上，也逐步識別并摘除一些技術(shù)債務(wù)。

梯隊(duì)建設(shè)也是我認(rèn)為非常重要的一環(huán)。能否規(guī)劃與組建你的團(tuán)隊(duì)，是技術(shù)管理者與架構(gòu)師非常重要的區(qū)別之一。梯隊(duì)建設(shè)為什么重要，那是因?yàn)榱己玫奶蓐?duì)建設(shè)，一方面能讓你的團(tuán)隊(duì)人員更穩(wěn)固，畢竟大家都有成長的訴求，無論是當(dāng)技術(shù)管理還是架構(gòu)師，都或多或少需要帶人完成更具挑戰(zhàn)性的項(xiàng)目，單打獨(dú)斗能成事者寥寥無幾。今年年中的時候，大批校招生準(zhǔn)備進(jìn)場。當(dāng)時分析自己的團(tuán)隊(duì)，有 5 - 6 個高級或者準(zhǔn)高級工程師了，這些高級的工程師工作經(jīng)驗(yàn)都比較豐富了，但一直沒有帶人的機(jī)會，同時也由于業(yè)務(wù)比較繁忙，于是我就趁機(jī)會要了足夠數(shù)量的畢業(yè)生，讓他們帶帶人。我是希望通過手把手帶人，可以更好地激發(fā)他們的責(zé)任心，也可以讓畢業(yè)生跟著他們?nèi)プ鲆恍┘夹g(shù)規(guī)劃里的項(xiàng)目，讓這些高級工程師也多鍛煉架構(gòu)與管理能力。雖然早期難免會有陣痛，比如畢業(yè)生對流程不熟悉，研發(fā)質(zhì)量可能會有下降，但經(jīng)過三個月的試用期后，畢業(yè)生的工作都步入正規(guī)，有充足人力的情況下，許多的技術(shù)規(guī)劃落地都比較順利。

其次，梯隊(duì)建設(shè)的好壞，能決定你之前的技術(shù)規(guī)劃能否順利落地。除了前面提到的不同職級與經(jīng)驗(yàn)的人的比例要均衡，還需要在各個技術(shù)方向有技術(shù)儲備，最好是有技術(shù)領(lǐng)頭人，甚至能有技術(shù)小組，畢竟孤身一人去探索某個技術(shù)方案還是挺孤獨(dú)寂寞的，也沒有人一起做技術(shù)討論。另外有這樣的一個技術(shù)小組，也可以有備份人。在團(tuán)隊(duì)中，因應(yīng)著定下的技術(shù)規(guī)劃，基本上每個體系的建設(shè)都會成立一個技術(shù)小組，這些人可能在公司組織上并不是同一個組，但只要他們對這塊感興趣，或者在這塊有建樹，就可以參與到這塊的建設(shè)中。比如在 Web 體系建設(shè)小組里面，有三位同事，這塊需要負(fù)責(zé)的項(xiàng)目比較多，包括 Web 發(fā)布的自動化、精細(xì)化，Web 組件建設(shè)，F(xiàn)igma 組件生成自動化，同構(gòu)渲染研究等都?xì)w屬到這里，每個人都有自己主攻的方向，但每一個時期側(cè)重點(diǎn)可能有不同，有可能會有有幾個人共同參與到某一個項(xiàng)目的建設(shè)當(dāng)中，快速將該項(xiàng)目先做成。

高效工作 如果落實(shí)得好，快樂工作其實(shí)也就達(dá)成一半以上了，因?yàn)楦咝Чぷ骺梢宰尮ぷ餍侍岣撸影鄿p少，也能讓大家有成長的快感，再加之以打造良好的技術(shù)氛圍（技術(shù)分享、外出參與技術(shù)會議、內(nèi)部開放的技術(shù)討論），相信員工的工作滿意度會相對較高。

小結(jié)一下，成為好的管理者，需要通過賦能做到：

1. 高效工作

• 模塊劃分，讓職責(zé)明確，業(yè)務(wù)熟練
• 流程優(yōu)化，減少行政工作，提高代碼時間
• 技術(shù)規(guī)劃，指明方向，甩掉債務(wù)，提升個人技能與團(tuán)隊(duì)效益
• 梯隊(duì)建設(shè)，儲備技術(shù)與落地規(guī)劃

2. 快樂工作

• 高效工作是前提
• 打造良好的技術(shù)氛圍

瓶頸二：從帶領(lǐng)單項(xiàng)技術(shù)到帶領(lǐng)多項(xiàng)技術(shù)的突破

隨著職級的提升，要跟跨團(tuán)隊(duì)的技術(shù)合作、甚至帶跨技術(shù)的項(xiàng)目、同時帶其它的技術(shù)組的情況會越來越多。如果倒推幾年，前端要進(jìn)入后臺、客戶端的領(lǐng)域，難度還是比較大的，這個是整個業(yè)界都存在的問題。但隨著一些重要的技術(shù)的誕生與成熟，比如 Node.js，React Native, Electron 進(jìn)入前端人的視野，前端有更多的機(jī)會可以參與到這些。所以從大局上、宏觀上講，我們要多支持這些技術(shù)的成長，無論是給這些開源項(xiàng)目貢獻(xiàn)源碼、布道、貢獻(xiàn)最佳實(shí)踐，最終都能讓我們自己受益。所以我在團(tuán)隊(duì)里也比較鼓勵大家貢獻(xiàn)開源項(xiàng)目，或者通過造開源項(xiàng)目的周邊小輪子練練手。

但從自己團(tuán)隊(duì)的業(yè)務(wù)與技術(shù)發(fā)展，這個微觀的層面來看更著重看的是自己團(tuán)隊(duì)在某塊跨領(lǐng)域技術(shù)的知識儲備、人才儲備與項(xiàng)目歷練。舉個例子，如果前端要能夠承接個別的中后臺業(yè)務(wù)，必需要團(tuán)隊(duì)里面的 Node.js 基建設(shè)施比較完善，并且要有相關(guān)的人才能夠 Hold 得住，否則哪里報了 Node.js 的錯誤，哪里產(chǎn)生的性能瓶頸，哪里出現(xiàn)疑難雜癥，沒有人有思路解決，這就很可能會阻塞到業(yè)務(wù)的進(jìn)展。

我個人的建議是，首先要讓基建設(shè)施完備，譬如將 Node.js 部署到 K8S 的設(shè)施搭建起來，包括進(jìn)程管理器、上報埋點(diǎn)的工具庫、Node.js 的基礎(chǔ) Docker 鏡像等等?；ㄍ陚浜?，我們先用一些技術(shù)項(xiàng)目練手，尤其是在許多跟客戶端一起合作的項(xiàng)目里，由于有前端能寫 Node.js 的緣故，一些大前端的公共平臺，比如熱更新發(fā)布平臺、配置中心等的一些項(xiàng)目，都可以由前端來做主要推手，通過這些項(xiàng)目來積累一些高并發(fā)、高可用的后臺開發(fā)與運(yùn)維經(jīng)驗(yàn)，從而獲取后臺開發(fā)的經(jīng)驗(yàn)。如果不想如此的激進(jìn)，也可以從一些偏管理后臺的項(xiàng)目開始，這些老板們是比較放心讓 Node.js 來實(shí)現(xiàn)的。當(dāng)擁有了基礎(chǔ)的 Node.js 開發(fā)與運(yùn)維經(jīng)驗(yàn)后，可以開始在業(yè)務(wù)中做一些嘗試，尤其是那些中臺的接口轉(zhuǎn)發(fā)項(xiàng)目、或者是同構(gòu)渲染提升性能的項(xiàng)目。只有跨越出來，能做一些用戶側(cè)業(yè)務(wù)的 Node.js 服務(wù)，這樣才能更進(jìn)一步通過解決用戶側(cè)的服務(wù)挑戰(zhàn)來提升團(tuán)隊(duì)的實(shí)力。我們當(dāng)時是選擇了一個非常適合前端 Node.js 來實(shí)現(xiàn)的服務(wù)，就是用戶購買商品后的訂單詳情頁。這個頁面，產(chǎn)品要求的動態(tài)化非常高，不同產(chǎn)品的字段不盡相同，而且可能時不時調(diào)整順序或者添加字段。而且后臺提供的定的接口，又不太好表現(xiàn)一些字段的分類、字段的排序、字段展示的格式等。于是我們就提出，用 Node.js 做一個中間服務(wù)，將這些商品的詳情字段全部做成可配置化，并在 React Native 側(cè)做了一個基礎(chǔ)的展示引擎，基于后臺返回的字段動態(tài)渲染。

有了不少的技術(shù)項(xiàng)目還有這次業(yè)務(wù)項(xiàng)目的實(shí)踐成功，大大增強(qiáng)了前端的信心，等到后續(xù)后臺由于人力原因無法投入太多精力到產(chǎn)品官網(wǎng)的開發(fā)，前端就順其自然地接受了這個挑戰(zhàn)，會去做全站的前后臺開發(fā)任務(wù)，在業(yè)務(wù)中更深層次地使用 Node.js。

做一下小結(jié)，想突破目前單一技術(shù)的管理，如果以中后臺為例的話，可以嘗試走以下的步驟：

1. 搭好基礎(chǔ)設(shè)施，以小項(xiàng)目練手
2. 在大前端中主導(dǎo)一些相關(guān)的后臺項(xiàng)目建設(shè)，贏得高可用、高性能的經(jīng)驗(yàn)
3. 切入中臺業(yè)務(wù)，嘗試后臺服務(wù)的中間層
4. 往“后”拓展，可嘗試非核心業(yè)務(wù)的全棧落地

瓶頸三：從帶技術(shù)到帶業(yè)務(wù)的突破

前端，乃至大部分的研發(fā)，被作為工具人，長久只是需求的實(shí)現(xiàn)機(jī)器，能真正突破從做技術(shù)到帶業(yè)務(wù)的人少之又少。這個突破有兩個層次，一個是成為這個業(yè)務(wù)模塊的整體技術(shù)負(fù)責(zé)人，另一個層次是直接成為這個業(yè)務(wù)的總負(fù)責(zé)人。遺憾的是，本人都未能達(dá)到這些層次，目前只是粗略地談一下我自己做的一些嘗試，而且主要是第一個層次的嘗試。

一個研發(fā)是不是關(guān)注業(yè)務(wù)，其實(shí)只要你問一下他，是否知道這個產(chǎn)品面向的用戶，用戶規(guī)模、活躍用戶有多少，GMV 有多少等等的一些關(guān)鍵業(yè)務(wù)數(shù)據(jù)，如果他能答出一些，而不是完全不知道，那證明這位研發(fā)還是比較關(guān)心業(yè)務(wù)的。有這樣良好的關(guān)心業(yè)務(wù)數(shù)據(jù)的習(xí)慣，相信更進(jìn)一步，讓這位研發(fā)不僅只了解自己模塊的業(yè)務(wù)邏輯，可以將后臺、客戶端跟某個模塊相關(guān)的業(yè)務(wù)邏輯都了解一遍還是比較容易的。并且老板、產(chǎn)品、測試人員來問的時候，都能比較清楚地做出解釋，那這位研發(fā)熟悉業(yè)務(wù)的名聲就已經(jīng)遠(yuǎn)播了。

但是，有的時候盡管你可能對這些業(yè)務(wù)有所了解，但由于在前端這個崗位上，天然可能就比后臺有一定的劣勢——畢竟業(yè)務(wù)的最主要的流程是在后臺實(shí)施的。這些對于金融、電商的行業(yè)尤其如此，可能相比之下，社交、內(nèi)容、工具等平臺，前端的話語權(quán)可能反倒更大一些。加上如果你做了大量的技術(shù)項(xiàng)目，盡管你對業(yè)務(wù)其實(shí)也了解，也可能會給別人留下過于關(guān)注技術(shù)，而忽略業(yè)務(wù)的印象——畢竟每次項(xiàng)目會上，需要解決的后臺的問題，比前端和客戶端高出一大截，我們也不太好去插話。因此，在重視技術(shù)建設(shè)的同時，也可以多對業(yè)務(wù)的流程提出一些優(yōu)化，比如后續(xù)我就吸取一些經(jīng)驗(yàn)教訓(xùn)，希望在一些商品上新的流程上做一些簡化，減少每次上新投入的人力，使整個項(xiàng)目組的人力規(guī)劃可以向其它更重要的事情上傾斜。

此外，我們也可以嘗試針對業(yè)務(wù)當(dāng)下或者未來的訴求做一些產(chǎn)品的孵化。比如作為金融電商平臺，比較容易想到的就是一些常規(guī)運(yùn)營頁面的搭建工具，畢竟前端在產(chǎn)品做用戶增長這塊，還是可以發(fā)揮比較大的作用。于是斷斷續(xù)續(xù)，我們團(tuán)隊(duì)就搭建了一個可以跨多個 APP 運(yùn)行的運(yùn)營頁面搭建工具。在做這些項(xiàng)目的孵化過程中，并不是一帆風(fēng)順的，比方說這些產(chǎn)品要從策略、設(shè)計(jì)到落地都需要團(tuán)隊(duì)的人從頭做起，推動運(yùn)營人員的使用也并非一帆風(fēng)順，也成就也有挫敗。但經(jīng)過這些歷練之后，讓自己對業(yè)務(wù)、產(chǎn)品的把握也會有另一番的見解。雖然目前的這些努力未有很明顯的成效，但團(tuán)隊(duì)人員在產(chǎn)品設(shè)計(jì)、打磨、落地方面的能力得到了儲備，正所謂養(yǎng)兵千日，用在一時，相信未來可能將會有這些產(chǎn)品、人員發(fā)揮的地方。

小結(jié)一下，從帶技術(shù)到帶業(yè)務(wù)的一些努力：

1. 關(guān)注業(yè)務(wù)，從關(guān)注業(yè)務(wù)的數(shù)據(jù)、邏輯開始，并且多端的邏輯都需要熟悉
2. 技術(shù)項(xiàng)目與業(yè)務(wù)項(xiàng)目都要兩手抓，并且需要有自己團(tuán)隊(duì)主推落地的一些核心業(yè)務(wù)需求與優(yōu)化
3. 嘗試孵化與業(yè)務(wù)相關(guān)或者與公司發(fā)展戰(zhàn)略一致的產(chǎn)品

總結(jié)

來 Shopee 一年半，變化翻天覆地，從來不敢想象自己會有機(jī)會去突破這些職業(yè)的界限，或者摸到這些職業(yè)界限的天花板。希望這些粗淺的經(jīng)驗(yàn)?zāi)軌驅(qū)髞矶加行﹩l(fā)，也希望一些同行、前輩可以多多指點(diǎn)，不吝賜教。同時感謝我團(tuán)隊(duì)的同事與老板，這一年多以來對我不遺余力的支持！

最后

點(diǎn)個在看支持我吧，轉(zhuǎn)發(fā)就更好了