技術路線：前端開發已進入深水區
對於普通人，最大潛水深度一般不超過水下 30 米，極限為水下 40 米，超過 40 米就進入到技術潛水的範疇，就會面臨各種複雜的危險狀況，需要各種裝備的集成和系統化的訓練才能保證一定的安全性。
為什麼技術晉陞越來越難了
為什麼高薪資的崗位 Offer 越來越難拿了
為什麼公司總是說做技術也要懂業務
為什麼很多團隊主管總把價值掛在嘴邊
為什麼 What/How/Why 必須要搞清楚
為什麼單純技術硬很難向前突破了
為什麼前端開發往上走比之前更難了
為什麼我想發力卻總是懶於動手
為什麼我趴鍵盤上看不到明天看不到希望
…
紅利已逝，今非昔比。對比 2010 年，整個前端生態已經翻新了好幾遍，直到近幾年的 Node BFF、IDE Cloud，抑或是客戶端 AI，還是 Serverless 的建設，前端想要深度參與的話，單純依靠原來的 HTML/CSS/JS 三件套技能也遠遠不夠了，再拋開技術，整個互聯網創業生態也重構了好幾遍，生意的本質沒變，但做生意的理念和方法論以及輔助的工具都發生了巨大的變化。
新的商業環境下就有新的公司組織架構形態，以及新的產品研發流程和合作模式，這些也對今日的前端開發工程師提出更新更高的要求，無論是技術層面還是意識層面，如今的前端開發已經進入深水區，要在深水區中生存以及捕撈獵物，就需要有深水區所需要的系統化的技能體系以及配套的軟硬體能力，以及從淺水區進往深水區所需要的進階方法論，本文試圖向大家傳達這樣一種觀點，希望帶給大家一些啟示，無論是新人老人都要居安思危，提前做出儲備，以應對新的職場挑戰，更靈活的延展自己的職業路線。
本文是小菜前端 TL 內訓課程中， 《上手技術管理的初級套路》 這一節裡面，關於前端已迎來深水區這個觀點的展開陳述，文中會截取幾頁 PPT 來輔助敘述幫大家理解:
淺水區需要哪些技能
站在 2019 年，通常一個工程師履歷中體現的是跳槽歷史、參與項目的難度、React/Vue/Angular 等框架底層熟悉度、編程方法論的掌握程度以及職位的變遷等，而在工作中的確與編程強相關的技能有很多（該圖是我多年前整理修改而來，有同學知道出處可以告知我）：
拋開 BATMD 這種大體量的公司，放在市面上任意一個 50 人規模以下技術團隊的公司裡面，大概率掌握最好的是 IDE/框架/API 這一層，至於代碼實現的足夠優雅很難保障，更不要提程序設計的嫻熟套路、項目背後沉澱的方法論等等，單純在這張圖上打怪升級花個 5 年 10 年絲毫不為怪，而對於前端工程師，這張圖的技能點花個 7 年 10 年全部打滿打透，此時也差不多三十而立了，而立之年也就是摸到了技術路線的第一個天花板，這個天花板就是技術專家，即便如此，用 10 年時間碰到這個天花板的人依然是極少數，大部分人需要花費更久甚至一直到不了這個高度，這張圖上我把它定義成淺水區技能，是肉眼可見的，是可以量化的，是最容易產生共鳴而形成學習動力的，但是放在如今的新商業環境中就顯得很單薄了。
為什麼單薄呢？我們把圖上的能力和知識體系打碎重組，提煉後就是三個關鍵字：架構、編程、運維，一個是意識和邏輯層面，一個是過程實現層面，一個是環境保障層面，這些能力依然是落純技術體系內，並沒有跟外部的商業和職場環境發生多少交集。
深水區需要哪些技能
在深水區，腦海中如果只有編程二字是不夠的，就算帶一些溝通合作也還是遠遠不夠，但是不是一定需要深水區技能才能把工作做好，答案也並不是，深水區技能是更長期性更深刻的，從長期看具備這些特質可以更快更好的跨過技術專家的這個天花板，走到更高的一個 Level，但不具備這些特質也未必會嚴重影響淺水區的表現。不過當更多同齡人具備深水區能力的時候，只具備淺水區能力的你慢慢就變成了裸泳，而更多更多的新人跳入到淺水區和你一起競爭，此時你跟深水區已經是隔絕的兩個世界，看到的和收穫也截然不同了。
我把深水區的技能，更口語化的總結為：技術創新、流程優化、團隊合作、影響大盤、驅動業務、商業決策和團隊管理，如下圖：
每一個能力的解釋我也標註在了圖上，再通俗的解釋一下：
技術創新，從技術面、業務和產品面出發，以技術作為突破點，取得技術上的突破，比如兼容多端的框架研發、客戶端淺層次 AI 的實現
流程優化，更多是從產品研發流程上發力，藉助向上向下的管理，推動流程變得更高效，比如前後端的介面聯調方式、比如產品 PRD 到測試流程的介入更敏捷的迭代方式，可能是規範可能是工具層面
團隊合作，這個最好理解也最難做好，同樣是從管理和業務的視角切過去，促成團隊成員之間有更高層面的共識達成，有更信任的紐帶關係，以及有更匹配的使命目標驅動，比如與業務同學一起出差拜訪客戶，並在過程中發現更多共鳴點，從而驅動彼此更快調整協作方式，最終為客戶解決問題
影響大盤，所謂大盤就是公司或者部門的業務大盤，這個一定需要對業務的前景有較為客觀深刻的認識，並且形成自己的獨立判斷和決策，去發現業務缺失哪些核心的因素點，並去補全這個遺漏甚至是發現一個機會點，去發掘實現一個新的業務可能性，比如公司的內容生產是一個核心業務，去發現它未來規模化生產會遇到人力瓶頸，有沒有可能通過產品化背後的技術能力提供生產力，讓業務看到一個新的可能性從而修正整個內容的規劃方向
驅動業務，與影響大盤不同，驅動業務更多是有實質性的推進而不僅僅是想法，比如通過配套的埋點監控工具，來捕捉用戶一些有意義的行為，從而不斷從中發現問題並推動業務去優化解決，或者發現有價值的方向，從而開放這些價值點背後的技術能力給到業務和產品，賦能他們更好的迭代業務流程
商業決策，這一點更多是從數據價值層面，比如可視化很多時候是從前端來主導研發和推進，從各種展現模型中為業務提供更好的決策視角，但在它之前一定是對業務和產品有足夠深的理解才會形成有效的決策路徑和模型
團隊管理，這個則是一個很大的話題了，站在組織的視角把團隊從弱帶到強，從小帶到大，從層次不齊帶到規矩有章法能沖能創，成為公司具備核心影響力的團隊
經過我們再次簡單分析後，可以發現這些技能背後，是四個核心能力，分別是：技術、產品、業務和管理能力，把它們再拆到每個能力上，按照影響的權重，是這樣的對應關係：
大部分僅僅是靠技術都不可能去推進了，甚至技術都未必是它的重要影響權重，比如團隊合作、影響大盤、商業決策等，統統這些能力的集合就是一個足夠資深的工程師，他能在深水區存活，並且靠此打出一片天所需要的軟實力了。
怎麼修鍊深水區能力
聊清楚深水區對於工程師的 What 和 Why 以後，我們來聊一聊 How。開始之前我們必須認識到這些能力不是一蹴而就的，無論是你已經具備了部分能力，還是絲毫不具備，我們都要認識到它的習得需要一個過程，這個過程通常就分為這三個階段：初級練習階段、漸變嫻熟的階段、質變內化為能力的階段，在初級練習階段沒有足夠的沉澱前，直接跳往後兩個階段都是不切實際的。
首先是初級階段怎麼練習，我把 PDCA 修改後形成這一個做事套路，大家可以參考：
工作中的每一項具體的任務，都可以按照這個路子走一遍，一開始的時候會不適應，甚至有點僵硬的硬套模仿，多來幾次慢慢就會成為一種習慣，舉個例子：
團隊里有很多表單開發的場景，大家的效率都很低，開發很痛苦，我看到這個問題後，就想要做一個複雜表單組件，我首先就是研究各種市面方案，研究公司的業務場景，研究已有的端產品上業務表達的交互表達方式，團隊有沒有人研究過表單的方案，我去收集相關的信息，並且我也弄明白為什麼要開發這個表單組件，它能為業務帶來實際的價值么，這個表單應該承載什麼核心功能呢，做完能推動落地么，我本人能推得動么…. 這個環節就是形成判斷決策的時候，也就是捉摸。
捉摸明白後，我開始制定目標，這個要符合 SMART 法則，盡量的可量化，比如：我要用 2 周時間開發一個表單組件，這個組件要可以被兼容替換到 AB 兩個業務的 DEF 三個產品的 10 個頁面的交互中，然後開始制定具體的開發計劃，哪個時間點找老闆徵得同意，開始定出分幾個版本來迭代，每個版本的周期是幾天，每個版本完成的具體功能是什麼，在這個過程中需要哪些資源，比如架構組同學的支持，業務組同學的反饋，交互組同學的設計配合，產品經理同學的理解和認同，然後把整個開發過程以可被感知的方式量化出來，透明化出來，這就是規劃的階段。
規劃後開始進行技術方案的設計，模塊的設計，三方庫等等直到編碼完成，開始推動組件在匹配的業務線和產品中使用，推動並幫助其他同學使用該組件，跟蹤組件使用的效果並及時的修理 Bug 優化交互等，這個就是執行階段。
在業務線用了一段時間後，組織一個小小復盤，針對實際應用中的問題做個收集整理，並且把過程中自己的不足也做一個檢視，比如經常忘記跟老闆同步進度，經常疏忽其他同學的吐槽建議等等，另外根據復盤和反饋來確保這個組件的確有提效的價值。
最後是沉澱開發組件的方法論，相應的技術文檔（這個往往在開發過程中就沉澱下來了），以及組件化立項開發的套路，自己個人能力有什麼成長，這種能力如何快速複製給其他新手同學…也就是沉澱 Share 的階段。
實際工作中的問題，往往比一個組件要複雜的多的多，這就需要我們更加謹慎的對待每個階段，把它們靈活應用並保障每次都比上一次拿到更好的結果，個人每次都比上一次方法論用的更純熟。
上面拋磚引玉介紹了單純實現層面可以訓練的方法論，這種方法論同樣適用了任何能力的練習，但方法論畢竟是方法論，真正決定它們訓練結果其實還有一個前置條件，就是你的做事驅動力，也就是能力和意願的情況。
能力意願是前置條件
我們先講了方法論，讓大家更明確的感受到一些可執行的套路，然後再來看能力和意願的重要性，所謂能力就是你判定問題和分析解決問題的能力，所謂意願就是你面對任何一個突入飛來的難題或者任務，內心是抵觸、認同還是興奮這樣的一種情緒。
首先，我們分析下一個員工的做事動機，通常有這幾類：
不知道不關心，對這個任務不清楚 what/how/why，也不關心它做不做的價值有多大
這麼做是因為必須這麼做，依然不理解它的價值，但知道這樣做是因為我是前端工程師，這是我分內事
不這麼做會有罪疚感，老闆對我有信任，我如果不做好會覺得不好意思，心理過不去
這麼做對我很重要，我認同這件事交給我做的原因和意義，這件事對我的成長及未來晉陞都有意義，我很重視
喜歡並專註去做，這件事是我一直以來期待的機會，我很喜歡很想去實現它，我很理解它做好的意義
所以一個同學有可能做不同的項目會有不同的動機，即便做同一個項目的不同階段也會有不同的動機，這是一個完全主觀的事情，但是它很重要，因為不同的動機會帶來三個結果：老闆及周圍同事通過你做這件事所看出的你的做事態度，這件事你做完達成的結果，以及你由此而獲得的成就感或者成長，當然所有的團隊都希望你無論喜歡與否，都至少是理解並執行這個任務：
最怕的是理解不執行和不理解和不執行，最終反映在能力和意願上，在一個團隊的分布中，你就有了不同的象限，是能力好意願度高的，還是能力高意願度低的，只有意願高能力高的人才能獲得最大程度的授權和自由空間，反之不僅獲得授權會縮水，甚至必須聽從具體的拆解後的任務去做執行的角色，所以如何讓自己無論能力高低，先讓自己具備一個高意願度都是一個明智的選項。
那麼存不存在一些事情是無意義的，做了也是白做呢，一定存在，現在這樣高節奏的創業環境中，試錯始終是一種常態，做一件事而拿不到結果也是常有的事，但是不是因此就否定了組織的動機，從而把自己束縛的越來越緊，正面看過去好像自己不再虧什麼了，反過來看自己卻失去了進入深水區而該有的歷練，這個歷練中一定有汗水也有委屈。
面對深水壓力不需緊張
其實何止前端開發，整個技術行業都已步入深水區，只是前端工程師的感知來的晚一些而已。只要把眼光投向深水區，問題就會一個接一個的浮上來，當越來越多問題浮起來的時候，就是你慢慢沉向深水區的時候，這時候不需要太過緊張，此時的發生正在見證者你的成長，歡迎大家文後提問更多問題，我們可以再換一期來針對性討論，本文主要幫大家引導到深水區已然到來，在它之上需要儲備技能的必要性和重要性，目的就達到了。
作者：Scott
https://juejin.im/post/5d2457f06fb9a07ef5625c07
TAG:JavaScript |