你累死累活作業務，績效還不怎麼樣，我只能幫你到這了……

前言

做爲一個業務前端，完成業務需求的同時，還要處理各類線上問題，加班辛苦忙碌了一年，還要被老闆說「思考是不夠的」、「沒有業務 sence」，出去面試，被問項目，也說不出什麼有亮點或者有挑戰的東西，想作點牛逼的東西，也沒有發現什麼有價值的方向，好不容易找到一些方向，還要被老闆一頓質問，業務價值是什麼？ROI 怎樣？最終可能就只是作了一點性能優化工做，抽離了一些可複用的組件……不由讓人感嘆，業務難、前端難、作業務的前端更難！

若是你也有這樣的感覺和困境，我想告訴你，這真的是太正常了，在阿里內部的技術論壇就有多篇關於這個問題的思考，我根據根據本身理解和調研，同時參考了多位不一樣前端領域專家的總結，整理成這篇文章，但願能對你們有所幫助。

1. 業務前端的困境

1.1 業務前端「好忙」

業務前端，顧名思義，作業務的前端，直接與業務的 PD、運營接觸，對產品的用戶直接負責。在實際的工做中，業務前端常常忙於業務的各類會議、項目和答疑，即使一條業務線上有多個前端同窗支持，面對成山的需求，可能依然感到吃力，這其中的緣由可能有：

1. 用戶側產品每每須要快速上線，大部分需求都須要倒排工期，開發時間尤爲緊張
2. 對業務不熟悉，在項目需求已肯定的時候纔去參加視覺評審，沒有辦法判斷需求背後的業務邏輯跟業務大節奏是否匹配、需求自己是否可以達成業務目標、有沒有更好的實現方式，只能接下需求，而後排期
3. 維護成本高，天天還要忙於解決各類線上問題，好比這裏樣式有點問題，那裏怎麼沒有顯示……各類瑣碎問題讓你過的很是「充實」
4. 需求響應速度較慢，好比業務的技術棧較老，或者定製邏輯過多，邊寫代碼還要邊查文檔，查不到可能還要查源碼，效率大幅下降。又或者跟別的業務技術體系不一樣，難以複用和沉澱，若是要用，可能還要重寫一遍……

1.2 業務前端是「資源」?

前端崗位的特色就是有視覺稿就能夠完成工做，不須要理解業務全貌，因此在繁忙期很容易讓前端忽視了業務思考，加上以前描述的各類緣由，業務前端常常淪落爲「資源」，當你淪落爲「資源」的時候，其實就已經失去了和業務平等對話的資格，他們只會把你當成莫得感情的開發機器，跟你輸入需求，讓你吐出頁面，而你在這樣的關係中，原本寫着還算工整的代碼，爲了快速實現業務需求，也開始寫起亂糟糟的代碼，對於你所創造的產品也沒有話語權，長此以往也失去了激情和耐心。

失去激情，寫的不開心也就算了，由於你沒有作出什麼特別的東西，老闆也不會特別承認你的辛苦，還會以爲你思考不夠、沒有業務 sence，對業務沒有助力，沒有讓業務由於你的存在而有所不一樣……

1.3 業務前端想突破

好吧，那我決定作點什麼改變一下，因而跟老闆提出了一系列想法：

1. 這裏技術體系太老了，爲了進一步提高開發效率，咱們想要搞技術重構
2. 先後端聯調有點費勁，咱們想搞個聯調數據中臺，提高聯調效率
3. 那裏展示速度太慢了，咱們要搞性能優化
4. ……

老闆每每會來一系列靈魂提問：

1. 爲何要作？（有什麼業務價值？有什麼技術價值？）
2. 爲何是如今作？
3. 爲何是你作？
4. ROI（投入產出比）怎麼樣？

尚未開始，躁動的心就被老闆的一系列「質疑」澆了一盆冷水。

若是沒有回答好這些問題、說服老闆，天然也爭取不到什麼資源，只能一我的搞搞，一我的搞的每每質量不行、也沒有人用，長此以往本身也不維護了，只能又開始埋頭在需求中。

乾的不開心，也沒有成長，最後只能暗淡離職，但換了一個公司就會好嗎，極可能又是相似的過程……

這真的堪稱是業務前端的「困境」，那麼如何突破這種困境呢？首先咱們就要擺正心態，從瞭解業務開始。

2. 瞭解業務

2.1 業務和需求

在瞭解業務以前，首先咱們要知道，業務跟需求是不同的。理解需求並不等於理解業務，需求是業務通過產品消化後的產物，可能已經通過演繹或者拆解，所以需求並非業務自己，固然瞭解的需求越多，對業務的全貌也會更加了解。

那麼什麼是業務呢？業界對"業務"有多種定義，可是其主要思想基本不變，業務就是一系列人經過一系列活動完成某一任務的過程，所以，業務可大可小，能夠無限拆分。

咱們本文涉及的業務泛指商業業務，就是與該 BU 或者公司商業模式直接關聯的業務或其組成部分。

2.2 前端爲何要學習業務

前端即便不學習業務，其實也不影響作需求，畢竟你只要告訴我交互是什麼樣的，前端就能夠幫你實現，並且已經有產品經理的角色了，你們各司其職不就行了，爲何一個作技術的，要狗拿耗子、或者是越俎代庖呢？這就要說到：

1. 只有瞭解業務，才能從技術的角度想到業務方未曾想到的地方；不瞭解業務，你可能聽不懂業務方要什麼，甚至連需求的業務邏輯都搞不清，這種狀況的合做模式只有一種，需求下來了，你接住，而後給排期。也許，這個需求的設計不合理，你不知道；這個需求有更好的實現方案，你不知道；這個需求能夠經過現成的關聯產品方案解決，省時省人力，你也不知道。
2. 只有瞭解到業務背後的緣由，才能從全局的視角去規劃技術的將來。不瞭解業務，會讓你離用戶的真實需求很遠，你越難發現其中的一些痛點和挑戰，無法真正提出你的思考和解決方案，去解決用戶的難題。
3. 做爲一名產品研發工程師，天然是但願親手打磨一款解決用戶問題、體驗友好的產品，若是產品能獲得用戶承認，產生影響力、天然會特別有成就感。
4. 阿里做爲一家商業科技公司，對技術人的要求就是技術與業務相結合，在知足業務需求的基礎上，成爲技術與業務的橋樑，主動走進業務，思考如何經過技術手段幫助業務作贏、知足市場和用戶需求，先一步技術規劃、人才儲備、技術架構和技術預研。

2.3 你瞭解業務嗎？

那麼目前你瞭解你對接的業務嗎？不妨嘗試回答下如下問題：

1. 業務作的是什麼？產品大圖有嗎？
2. 業務的核心指標是什麼？KPI目標是什麼，這些數字背後的含義是什麼？要達成這些目標，業務策略是什麼？
3. 業務的用戶是誰？流量怎麼分層？佔比多少？分別在業務中是怎樣的定位？
4. 業務的商業模式？靠什麼吸引流量，盈利模式是怎樣的？
5. 咱們作的頁面是什麼東西？爲業務帶來什麼價值？要創造更多的價值，咱們能夠作什麼？

2.4 如何學習業務?

2.4.1 業務領域知識的閱讀

找到該領域相關的評分較好的書籍集中閱讀，快速造成知識框架。

2.4.2 瞭解業務背景和規劃

1. 剛剛接手新的業務，能夠邀請業務方老闆或者資深的運營/產品同窗，給你講講這塊業務的過去、如今、將來、願景、財年規劃，以及對技術同窗的指望；
2. 花時間讀合做方（運營、產品、研發）的週報，瞭解如今在發生什麼，是否是離目標愈來愈近了；
3. 瞭解業務目標、落地策略、衡量目標的數據口徑，關注數據，關注目前作的項目是否爲了達成目標而戰，若是不是，提出你的想法和建議；
4. 多參會，創建產品 sense。收集信息最好的方式就是參加所處業務老大的 KO 會，各類 KO 會會把戰略上的拆解和背後的思考總體梳理以後宣講傳達給 BU 或部門的同窗，

2.4.3 多交流

與服務端同窗聊天，與 PM 聊天，與用戶聊天，多角度看業務，但要注意的是，針對專業型比較強的業務，須要先作功課，至少一些英文的縮寫要清楚的明白意思。

2.4.4 謹記數字

若是前面還須要花比較長的時間，那這一個能夠如今就作起來，那就是把業務相關的數字記得越精細約好，越具體越好，越全面越多越好。這樣作有兩個好處：

1. 所記的數字指標自己，很大程度已經涵蓋了這個業務價值方向，你便知道了這個業務重點關注的是哪一個維度的東西
2. 這些數字能夠做爲和業務方以及產品「平等對話」的源頭，不然連最基本的對話基礎都沒有

2.4.5 從平常需求入手

對於項目中的需求，咱們要嘗試分析背後的目的和價值，作了以後有什麼預期的收益，爲何這麼作就能夠達到這個收益，跟整體目標是否契合，還要判斷業務方提到的點是否是有效的方案或者說成本太大的方案，看能不能給出替代方案，用現有的方案或者小成本的方式來知足業務方。

而在項目提測上線後，還要仔細分析以及多關注上線以後的業務數據和效果，會有以下好處：

1. 提升本身對業務的理解能力，你在關注業務數據的同時，也就會更多的從業務的角度來看到這個功能所帶來的價值是否符合預期，當出現不符合預期的時候，能夠和業務方一塊兒進行數據漏斗的分析從而找到問題所在，避免咱們的勞動成果成爲一次性的工做。
2. 總結的同時能夠幫助本身梳理這個項目中本身哪些地方作的不足，或者相關推動中存在什麼問題，以及後面怎麼改進，提升了下次項目中的迭代效率和質量。好比這個項目是否存在需求理解不到位存在返工，或者溝通 & 聯調低效，環境不穩定，本身設計的方案是否合理等問題，後續要怎麼解決。
3. 也能夠從數據和總結中判斷出什麼樣的需求是靠譜的 & 什麼的樣業務方是靠譜的，頻繁爭取資源上線效果又很差的業務方，下次再有需求過來則須要多增長一個心眼和思考的過程。

2.4.6 堅持

業務思考力，沒有個至少半年是不會見效的

3. 助力業務

3.1 思考

儘管平時的業務很忙，但再忙，也要抽時間思考，那麼思考哪些內容呢？如下舉一些例子：

1. 養成天天記工做內容的習慣，分析一下本身的時間到底耗在哪了
2. 在業務開發中，有遇到讓你特別想吐槽的點嗎？想下問題背後的緣由，有什麼方法能夠避免下次不犯，能不能提煉爲更加通用的解決方案，其餘同窗怎麼解決的，我能夠怎麼解決？
3. 不斷地輸入、觀察，業務的真實需求是什麼？站在業務方的角度思考，業務遇到的痛點、挑戰在哪裏？

3.2 溝通

和老闆、團隊同窗、業務方對焦，確認「我想作的」是否是「你們想要的」？

你可能會提出不少意見，但通常會遭到老闆或者業務方無情的拒絕，並且問得你一臉懵逼，就好比：

1. 當前業務背景下，爲何要作？（有什麼業務價值？有什麼技術價值？）
2. 如今必須作麼？
3. 爲何是你作？
4. 怎麼作？（體系化、全鏈路、單點技術挑戰）
5. 有什麼業務和技術結果？可否被複用？
6. 將來規劃（可否跟BU或集團的方案聯動、共建）

而這每每是由於你提出要作的事情，有價值但不是必須作的，沒有結合目前業務須要什麼。也就是說，你想作的技術是我的和純技術角度思考的，沒有基於業務的現狀和痛點去考慮技術方案，不接地氣，投入產出比不高。

因此給技術產出先找好業務的陣地，看看有沒有能夠借力的地方，不要重複造輪子。快速驗證這個方向的正確性後，再逐漸多加投入、豐滿技術設計。不要本身YY、默默地作完，這樣作出來的東西沒有業務場景埋單。

3.3 技術規劃

業務賦能實際上是須要咱們緊貼業務規劃，制定技術規劃和方案。在瞭解業務方今年的 KPI 重點是什麼，預計的拆解和實現路徑是什麼後，再結合本身的和團隊狀況，想一想本身能作哪些事情來幫助業務實現其 KPI，這裏有兩點須要注意下：

抓住本質從點及面，通盤考慮: 不少時候，咱們收到的痛點和業務需求都是單點的，這時咱們不能着眼於眼前的單點問題，而須要通盤來考慮，好比SEO的頁面對性能很是敏感，常常可能會收到一些業務方來反饋，說目前咱們的SEO有這個地方，那個地方須要優化下，而單點解決這些問題可能對業務帶來的收益並不大，對本身的技能也沒有什麼成長。這時候若是通盤考慮這個命題，其實會發現作SEO頁面的優化，其實目的是爲了提高SEO頁面的收錄和排名。而提高SEO頁面的收錄和排名其實不只有前端性能優化這一個路徑，而是還有一些其餘的路徑：好比優化關鍵詞&長尾詞，採用Google的AMP技術改造SEO頁面，優化爬蟲爬取頁面的耗時提高爬取率等等。這樣就能吧點的問題轉化爲面的問題，才能制定更有效和全面的抓手來賦能業務。

既要解決眼前痛點，也要長遠謀劃: 不少時候咱們不能僅知足於眼前的KPI，還須要瞭解業務方長遠的想法和能夠預見的規劃。就好比試點的新業務，一層規劃是保證業務項目的按時上線，考慮到將來，另外一層規劃可能就是如何作到技術方案的能夠複製性。

3.4 站在巨人的肩膀上

當你須要制定一個產品化的方案或者工具和框架的時候，最好先放眼集團內部和行業進行一番調研，看看業界和其餘同事是怎麼解決這個問題的。儘可能站在別人的肩膀上作出創新或者參與共建，避免小團隊內造出重複和質量低的輪子

4. 技術深度

4.1 技術知識與技術能力

「技術」不能是一個籠統的詞彙，我想它至少能夠分爲「技術知識」和「技術能力」兩大部分。

什麼是「技術知識」？知識就是 I KNOW

• 《TypeScript 從入門到放棄》
• 《React 從入門到放棄》
• 《Webpack 從入門到放棄》
• ......

什麼是「技術能力」？能力就是 I CAN

• 我用 TypeScript 重構了一個大型系統，代碼健壯性及研發效率大幅提高。
• 我用 React Hooks 給全棧同窗進行前端培訓，培訓效果大幅提高。
• 我深刻研究了 Webpack，優化配置，使得系統構建速度大幅提高。
• .....

4.2 培養技術視野

1. 關注平常業界新技術。不必定要深刻了解，但對新技術保持好奇心，大概瞭解它是作什麼的，若是在工做中遇到匹配的落地環境，能夠考慮寫個 demo 看看是否是有價值
2. 關注集團和業界的解決方案。在業務中發現問題，作解決方案的時候，咱們很容易陷入本身的設計中，一腦子地想把全部東西都本身作出來，但投入會很是大，產出的價值是否同樣大呢？不知道。大部分狀況下，你想作的，在ATA能搜到，前人踩的坑，或者已有的成熟的解決方案，只要你去溝通去接觸，就能夠輕鬆地接進來，爲何要花大量的時間去造輪子呢？能夠借力的地方，就去借力吧，把時間剩下來，作你的解決方案中更核心更有價值的事情。

4.3 技術深度

一聊到「技術深度」，可能很天然地會認爲是在某項技術上挖得很深，或者解決了一個業界公認難度很高的技術難題，但這只是「技術深度」的其中一部分：

1. 體系化 / 系統化
   體系化思惟是認識事物的一種方式，在面對問題的時候，可以針對複雜的問題，列出關鍵的要素和解決方法，將散亂無序的問題，變得邏輯清晰，有章可循。
   在問題的定位和解決的體現，從表象到本質，拆解出形成問題背後的緣由，針對性地去解決本質的緣由，而非治標不治本，有解決方案有節奏地解決。
2. 全鏈路
   除了前端的部分，向前向後的技術棧，還能挖多深。
3. 單點技術挑戰
   在某個技術挑戰上，你的思考和解決方案是怎樣的。

4.4 技術與業務雙贏

真正有突破性的、帶來重大價值的業務成果必然伴隨着技術上的深刻乃至創新，因此在作業務成果的時候，必定會有讓咱們增長技術深度的場景。

5. 給你更多體感

培養業務感確實是一件很是有難度的事情，他要求你以業務而非技術爲第一視角，這可能違背了不少人心裏的「技術堅持」，但若是一直作技術，實際上是很難有很是大的突破的，在工做中，若是能實現技術與業務雙贏，將會助力你到達更高的高度。

改變的確很難，但結果值得冒險。