作者|犽羽
出品|阿里巴巴新零售淘系技術部
前言
作為一個業務前端，完成業務需求的同時，還要處理各種線上問題，加班辛苦忙碌了一年，還要被老闆說“思考是不夠的”、“沒有業務 sence”，出去面試，被問項目，也說不出什麼有亮點或者有挑戰的東西，想做點牛逼的東西，也沒有發現什麼有價值的方向，好不容易找到一些方向，還要被老闆一頓質問，業務價值是什麼？ROI 怎樣？最終可能就只是做了一點性能優化工作，抽離了一些可複用的組件……不禁讓人感嘆，業務難、前端難、做業務的前端更難！
如果你也有這樣的感受和困境，我想告訴你，這真的是太正常了，在阿里內部的技術論壇就有多篇關於這個問題的思考，我根據根據自己理解和調研，同時參考了多位不同前端領域專家的總結，整理成這篇文章，希望能對大家有所幫助。
業務前端的困境
▐ 業務前端“好忙”
業務前端，顧名思義，做業務的前端，直接與業務的 PD、運營接觸，對產品的用戶直接負責。在實際的工作中，業務前端經常忙於業務的各種會議、項目和答疑，即便一條業務線上有多個前端同學支持，面對成山的需求，可能依然感到吃力，這其中的原因可能有：
用戶側產品往往需要快速上線，大部分需求都需要倒排工期，開發時間尤其緊張
對業務不熟悉，在項目需求已確定的時候才去參加視覺評審，沒有辦法判斷需求背後的業務邏輯跟業務大節奏是否匹配、需求本身是否能夠達成業務目標、有沒有更好的實現方式，只能接下需求，然後排期
維護成本高，每天還要忙於解決各種線上問題，比如這裡樣式有點問題，那裡怎麼沒有顯示……各種瑣碎問題讓你過的非常“充實”
需求響應速度較慢，比如業務的技術棧較老，或者定製邏輯過多，邊寫代碼還要邊查文檔，查不到可能還要查源碼，效率大幅降低。又或者跟別的業務技術體系不同，難以複用和沉澱，如果要用，可能還要重寫一遍……
▐ 業務前端是“資源”?
前端崗位的特點就是有視覺稿就可以完成工作，不需要理解業務全貌，所以在繁忙期很容易讓前端忽視了業務思考，加上之前描述的各種原因，業務前端經常淪落為“資源”，當你淪落為“資源”的時候，其實就已經失去了和業務平等對話的資格，他們只會把你當成莫得感情的開發機器，跟你輸入需求，讓你吐出頁面，而你在這樣的關係中，本來寫著還算工整的代碼，為了快速實現業務需求，也開始寫起亂糟糟的代碼，對於你所創造的產品也沒有話語權，久而久之也失去了激情和耐心。
失去激情，寫的不開心也就算了，因為你沒有做出什麼特別的東西，老闆也不會特別認可你的辛苦，還會覺得你思考不夠、沒有業務 sence，對業務沒有助力，沒有讓業務因為你的存在而有所不同……
**▐ 業務前端想突破
**
好吧，那我決定做點什麼改變一下，於是跟老闆提出了一系列想法：
- 這裡技術體系太老了，為了進一步提升開發效率，我們想要搞技術重構
- 前後端聯調有點費勁，我們想搞個聯調數據中臺，提升聯調效率
- 那裡展現速度太慢了，我們要搞性能優化
- ……
老闆往往會來一系列靈魂提問：
- 為什麼要做？（有什麼業務價值？有什麼技術價值？）
- 為什麼是現在做？
- 為什麼是你做？
- ROI（投入產出比）怎麼樣？
還沒有開始，躁動的心就被老闆的一系列“質疑”澆了一盆冷水。
如果沒有回答好這些問題、說服老闆，自然也爭取不到什麼資源，只能一個人搞搞，一個人搞的往往質量不行、也沒有人用，久而久之自己也不維護了，只能又開始埋頭在需求中。
乾的不開心，也沒有成長，最後只能暗淡離職，但換了一個公司就會好嗎，很可能又是類似的過程……
這真的堪稱是業務前端的“困境”，那麼如何突破這種困境呢？首先我們就要擺正心態，從瞭解業務開始。
瞭解業務
▐ 業務和需求
在瞭解業務之前，首先我們要知道，業務跟需求是不一樣的。理解需求並不等於理解業務，需求是業務經過產品消化後的產物，可能已經經過演繹或者拆解，因此需求並不是業務本身，當然瞭解的需求越多，對業務的全貌也會更加了解。
那麼什麼是業務呢？業界對"業務"有多種定義，但是其主要思想基本不變，業務就是一系列人通過一系列活動完成某一任務的過程，因此，業務可大可小，可以無限拆分。
我們本文涉及的業務泛指商業業務，就是與該 BU 或者公司商業模式直接關聯的業務或其組成部分。
▐ 前端為什麼要學習業務
前端即使不學習業務，其實也不影響做需求，畢竟你只要告訴我交互是什麼樣的，前端就可以幫你實現，而且已經有產品經理的角色了，大家各司其職不就好了，為什麼一個做技術的，要狗拿耗子、或者是越俎代庖呢？這就要說到：
只有瞭解業務，才能從技術的角度想到業務方不曾想到的地方；不瞭解業務，你可能聽不懂業務方要什麼，甚至連需求的業務邏輯都搞不清，這種情況的合作模式只有一種，需求下來了，你接住，然後給排期。也許，這個需求的設計不合理，你不知道；這個需求有更好的實現方案，你不知道；這個需求可以通過現成的關聯產品方案解決，省時省人力，你也不知道。
只有瞭解到業務背後的原因，才能從全局的視角去規劃技術的未來。不瞭解業務，會讓你離用戶的真實需求很遠，你越難發現其中的一些痛點和挑戰，沒法真正提出你的思考和解決方案，去解決用戶的難題。
作為一名產品研發工程師，自然是希望親手打磨一款解決用戶問題、體驗友好的產品，如果產品能得到用戶認可，產生影響力、自然會特別有成就感。
阿里作為一家商業科技公司，對技術人的要求就是技術與業務相結合，在滿足業務需求的基礎上，成為技術與業務的橋樑，主動走進業務，思考如何通過技術手段幫助業務做贏、滿足市場和用戶需求，先一步技術規劃、人才儲備、技術架構和技術預研。
▐ 你瞭解業務嗎？
那麼目前你瞭解你對接的業務嗎？不妨嘗試回答下以下問題：
業務做的是什麼？產品大圖有嗎？
業務的核心指標是什麼？KPI目標是什麼，這些數字背後的含義是什麼？要達成這些目標，業務策略是什麼？
業務的用戶是誰？流量怎麼分層？佔比多少？分別在業務中是怎樣的定位？
業務的商業模式？靠什麼吸引流量，盈利模式是怎樣的？
我們做的頁面是什麼東西？為業務帶來什麼價值？要創造更多的價值，我們可以做什麼？
▐ 如何學習業務?
業務領域知識的閱讀
找到該領域相關的評分較好的書籍集中閱讀，快速形成知識框架。
瞭解業務背景和規劃
剛剛接手新的業務，可以邀請業務方老闆或者資深的運營/產品同學，給你講講這塊業務的過去、現在、未來、願景、財年規劃，以及對技術同學的期望；
花時間讀合作方（運營、產品、研發）的週報，瞭解現在在發生什麼，是不是離目標越來越近了；
瞭解業務目標、落地策略、衡量目標的數據口徑，關注數據，關注目前做的項目是否為了達成目標而戰，如果不是，提出你的想法和建議；
多參會，建立產品 sense。收集信息最好的方式就是參加所處業務老大的 KO 會，各種 KO 會會把戰略上的拆解和背後的思考整體梳理之後宣講傳達給 BU 或部門的同學，
多交流
與服務端同學聊天，與 PM 聊天，與用戶聊天，多角度看業務，但要注意的是，針對專業型比較強的業務，需要先做功課，至少一些英文的縮寫要清楚的明白意思。
謹記數字
如果前面還需要花比較長的時間，那這一個可以現在就做起來，那就是把業務相關的數字記得越精細約好，越具體越好，越全面越多越好。這樣做有兩個好處：
所記的數字指標本身，很大程度已經涵蓋了這個業務價值方向，你便知道了這個業務重點關注的是哪個維度的東西
這些數字可以作為和業務方以及產品“平等對話”的源頭，否則連最基本的對話基礎都沒有
從日常需求入手
對於項目中的需求，我們要嘗試分析背後的目的和價值，做了之後有什麼預期的收益，為什麼這麼做就可以達到這個收益，跟總體目標是否契合，還要判斷業務方提到的點是不是有效的方案或者說成本太大的方案，看能不能給出替代方案，用現有的方案或者小成本的方式來滿足業務方。
而在項目提測上線後，還要仔細分析以及多關注上線之後的業務數據和效果，會有如下好處：
提高自己對業務的理解能力，你在關注業務數據的同時，也就會更多的從業務的角度來看到這個功能所帶來的價值是否符合預期，當出現不符合預期的時候，可以和業務方一起進行數據漏斗的分析從而找到問題所在，避免我們的勞動成果成為一次性的工作。
總結的同時可以幫助自己梳理這個項目中自己哪些地方做的不足，或者相關推進中存在什麼問題，以及後面怎麼改進，提高了下次項目中的迭代效率和質量。比如這個項目是否存在需求理解不到位存在返工，或者溝通 & 聯調低效，環境不穩定，自己設計的方案是否合理等問題，後續要怎麼解決。
也可以從數據和總結中判斷出什麼樣的需求是靠譜的 & 什麼的樣業務方是靠譜的，頻繁爭取資源上線效果又不好的業務方，下次再有需求過來則需要多增加一個心眼和思考的過程。
堅持
業務思考力，沒有個至少半年是不會見效的
助力業務
▐ 思考
儘管平時的業務很忙，但再忙，也要抽時間思考，那麼思考哪些內容呢？以下舉一些例子：
養成每天記工作內容的習慣，分析一下自己的時間到底耗在哪了
在業務開發中，有遇到讓你特別想吐槽的點嗎？想下問題背後的原因，有什麼方法可以避免下次不犯，能不能提煉為更加通用的解決方案，其他同學怎麼解決的，我可以怎麼解決？
不斷地輸入、觀察，業務的真實需求是什麼？站在業務方的角度思考，業務遇到的痛點、挑戰在哪裡？
▐ 溝通
和老闆、團隊同學、業務方對焦，確認“我想做的”是不是“大家想要的”？
你可能會提出很多意見，但一般會遭到老闆或者業務方無情的拒絕，而且問得你一臉懵逼，就比如：
當前業務背景下，為什麼要做？（有什麼業務價值？有什麼技術價值？）
- 現在必須做麼？
- 為什麼是你做？
- 怎麼做？（體系化、全鏈路、單點技術挑戰）
- 有什麼業務和技術結果？能否被複用？
- 未來規劃（能否跟BU或集團的方案聯動、共建）
而這往往是因為你提出要做的事情，有價值但不是必須做的，沒有結合目前業務需要什麼。也就是說，你想做的技術是個人和純技術角度思考的，沒有基於業務的現狀和痛點去考慮技術方案，不接地氣，投入產出比不高。
所以給技術產出先找好業務的陣地，看看有沒有可以借力的地方，不要重複造輪子。快速驗證這個方向的正確性後，再逐漸多加投入、豐滿技術設計。不要自己YY、默默地做完，這樣做出來的東西沒有業務場景埋單。
▐ 技術規劃
業務賦能其實是需要我們緊貼業務規劃，制定技術規劃和方案。在瞭解業務方今年的 KPI 重點是什麼，預計的拆解和實現路徑是什麼後，再結合自己的和團隊情況，想想自己能做哪些事情來幫助業務實現其 KPI，這裡有兩點需要注意下：
抓住本質從點及面，通盤考慮: 很多時候，我們收到的痛點和業務需求都是單點的，這時我們不能著眼於眼前的單點問題，而需要通盤來考慮，比如SEO的頁面對性能非常敏感，經常可能會收到一些業務方來反饋，說目前我們的SEO有這個地方，那個地方需要優化下，而單點解決這些問題可能對業務帶來的收益並不大，對自己的技能也沒有什麼成長。這時候如果通盤考慮這個命題，其實會發現做SEO頁面的優化，其實目的是為了提升SEO頁面的收錄和排名。而提升SEO頁面的收錄和排名其實不僅有前端性能優化這一個路徑，而是還有一些其他的路徑：比如優化關鍵詞&長尾詞，採用Google的AMP技術改造SEO頁面，優化爬蟲爬取頁面的耗時提升爬取率等等。這樣就能吧點的問題轉化為面的問題，才能制定更有效和全面的抓手來賦能業務。
既要解決眼前痛點，也要長遠謀劃: 很多時候我們不能僅滿足於眼前的KPI，還需要了解業務方長遠的想法和可以預見的規劃。就比如試點的新業務，一層規劃是保證業務項目的按時上線，考慮到未來，另一層規劃可能就是如何做到技術方案的可以複製性。
▐ 站在巨人的肩膀上
當你需要制定一個產品化的方案或者工具和框架的時候，最好先放眼集團內部和行業進行一番調研，看看業界和其他同事是怎麼解決這個問題的。儘量站在別人的肩膀上做出創新或者參與共建，避免小團隊內造出重複和質量低的輪子
技術深度
▐ 技術知識與技術能力
“技術”不能是一個籠統的詞彙，我想它至少可以分為“技術知識”和“技術能力”兩大部分。
什麼是“技術知識”？知識就是 I KNOW
- 《TypeScript 從入門到放棄》
- 《React 從入門到放棄》
- 《Webpack 從入門到放棄》
- ......
什麼是“技術能力”？能力就是 I CAN
- 我用 TypeScript 重構了一個大型系統，代碼健壯性及研發效率大幅提升。
- 我用 React Hooks 給全棧同學進行前端培訓，培訓效果大幅提升。
- 我深入研究了 Webpack，優化配置，使得系統構建速度大幅提升。
- .....
▐ 培養技術視野
關注日常業界新技術。不一定要深入瞭解，但對新技術保持好奇心，大概瞭解它是做什麼的，如果在工作中遇到匹配的落地環境，可以考慮寫個 demo 看看是不是有價值
關注集團和業界的解決方案。在業務中發現問題，做解決方案的時候，我們很容易陷入自己的設計中，一腦子地想把所有東西都自己做出來，但投入會非常大，產出的價值是否一樣大呢？不知道。大部分情況下，你想做的，在ATA能搜到，前人踩的坑，或者已有的成熟的解決方案，只要你去溝通去接觸，就可以輕鬆地接進來，為什麼要花大量的時間去造輪子呢？可以借力的地方，就去借力吧，把時間剩下來，做你的解決方案中更核心更有價值的事情。
▐ 技術深度
一聊到“技術深度”，可能很自然地會認為是在某項技術上挖得很深，或者解決了一個業界公認難度很高的技術難題，但這只是“技術深度”的其中一部分：
1、體系化 / 系統化
體系化思維是認識事物的一種方式，在面對問題的時候，能夠針對複雜的問題，列出關鍵的要素和解決方法，將散亂無序的問題，變得邏輯清晰，有章可循。
在問題的定位和解決的體現，從表象到本質，拆解出造成問題背後的原因，針對性地去解決本質的原因，而非治標不治本，有解決方案有節奏地解決。
2、全鏈路
除了前端的部分，向前向後的技術棧，還能挖多深。
3、單點技術挑戰
在某個技術挑戰上，你的思考和解決方案是怎樣的。
▐ 技術與業務共贏
真正有突破性的、帶來重大價值的業務成果必然伴隨著技術上的深入乃至創新，所以在做業務成果的時候，一定會有讓我們增加技術深度的場景。
給你更多體感
培養業務感確實是一件非常有難度的事情，他要求你以業務而非技術為第一視角，這可能違背了很多人內心的“技術堅持”，但如果一直做技術，其實是很難有非常大的突破的，在工作中，如果能實現技術與業務共贏，將會助力你到達更高的高度。
改變的確很難，但結果值得冒險。
最後，說了這麼多，是不是感覺還是沒有什麼體感，還是不知道要做些什麼? 為了讓你們有更加深刻的感受，我們淘系技術部舉辦了三場直播，覆蓋 A/B、直播、邊緣計算三大主題，讓你更加明白“業務與技術共贏”。
關注「淘系技術」微信公眾號，一個有溫度有內容的技術社區~
