Scott 近兩年無論是面試還是線下線上的技術分享，遇到許許多多前端同學，由於團隊原因，個人原因，職業成長，技術方向，甚至家庭等等原因，在理想國與現實之間，在放棄與堅守之間，搖擺不停，心酸硬抗，大家可以找我聊聊南聊聊北，對工程師的宿命有更多的瞭解，有更多的看見與聽見，Scott 微信： codingdream。
本系列共 15 篇，此為第一篇，大家看完轉發下朋友圈我就心滿意足了。
正文開始
做規劃、管人、管資源、管優先順序，這便是一個 Tech Team Leader 的宿命。
本文 Scott 以管理者的視角，與大家分享下我自 2017 年 7 月入職小菜後，與前端同學一起是如何規劃團隊的技術棧的，這條技術棧上的技能點又是如何在不同童鞋不同業務中生長出來的。
先來看一張圖：
這張圖是 2018 年 8 月份我為團隊制定的技術棧架構分工圖，上面基本涵蓋了 2018 ~ 2020 年團隊所需要的的技術棧能力，它也會隨著業務和團隊不斷的微調和修正，等到了 2019 年 8 月份我會重新梳理一個新版本，將來到這裡分享給大家。
在帶這個團隊的一年多時間裡，我對於團隊的構想其實發生了很多次的變化，抽象的通用一點，一共會有兩個並行的過程，一個是從人和團隊視角的做好團隊規劃與管理，一個是結合業務針對團隊做具體的技術棧的演進和架構路線調整，兩個過程會交叉實施互相影響。這些方法和結論也有它特殊的公司背景和侷限性，未必適用於大家所在業務形態下的團隊，千萬不要硬搬，可以關注下這些過程中的變化，以及我的思考過程，最終我們再回到上面的這張圖上，大家就能明白一個團隊的技術棧架構和演進背後的方法論了。
一、團隊管理
首先說團隊管理，這個是前提，沒有配套的團隊管理手段輔助，是很難單純的讓技術棧發生持續的好的變化，也很難將架構理念推進落地的，在團隊管理這裡我主要是分成四步走。
第一步 瞭解團隊的長與短
新加入到一個團隊，尤其是成為資深工程師後新帶領一個團隊，除了埋頭做事外，有一個很重要的事情要儘早做，那就是去了解團隊，方式有很多，比如：
- 主動去看團隊倉庫裡的歷史程式碼，瞭解大家的編碼水平，程式設計風格，工程維護的方式，架構的成熟度
- 與每個同學單獨聊聊天，聊聊他對於一個技術的看法，對於業務上思考，對於自己和所處團隊的認知
- 請大家去吃吃飯，聽聽大家都聊什麼，玩什麼，關注什麼，每個人的氣場和表達方式，在辦公桌和餐桌上有什麼不同
- 找服務端團隊和業務團隊的同學，問問他們對於前端團隊的印象，對於合作童鞋的看法
- 在會議上丟擲一些問題，觀察大家的參與積極性和表述觀點的深度
還可以一起去打遊戲看電影，一起參加公司活動等等，這是一個比較粗的瞭解，我進團隊後，也是挑了上面兩三種方式對團隊成員有了一個比較粗的摸底，看到了很多好的特徵也看到了不少問題。
好的方面：都很年輕很聰明，學習能力較好，可塑性都很強，沒什麼城府，對技術有激情也有熱情，技術棧很新穎，每個人潛力都很大。
基於這些，可以預判這個團隊只要理清楚每個階段的重點，就可以快速成長，每個人都能不斷的突破天花板，所以大盤子的性質不錯，資質也不錯，再來看看問題：
問題：職場的專業度不夠，比較情緒化，對於業務多變有一定牴觸，職業規劃無感知，對於好的不好的評判標準比較狹隘比較封閉，整體工具化工程化以及基建的方向都沒有太多思考，對於整個行業的判斷比較粗淺，屬於比較原始蠻荒的階段，團隊成員的能力層次不齊，補位與大局意識比較薄弱。
具體的方法論，可以把近幾周的問題做彙總，然後給它們打標分類，比如這樣：
結合業務和開發過程，來梳理問題共性，最終的問題可以總結為：
- 人心不穩定
- 技能短板多
- 職業無規劃
- 合作意識差
- 團隊無規範
- 工具基建弱
- 業務無感知
- 梯隊未搭建
基於這些，可以預判團隊需要一個不短的磨合期，在磨合期中需要先逐步建立信任，同時針對不同的問題需要學唐僧跟大家經常講多講，也就是通過灌輸讓大家先有一個正確做事的概念在腦海中，然後再針對每一個同學的特徵，以不同的方式分配任務，驅動和輔導，另外，需要有一些事情大家要一起做來形成團隊合力和凝聚力，我最終選擇了技術分享作為一個大家共同做的事情，讓團隊在這一件事情達成唯一的共識 - 技術團隊影響力的提升和個人總結能力的提高。
第二步 鞭策團隊完善內部短板
所謂內部短板，就是完全是自己的鍋的問題，比如釋出系統不完善，比如程式碼不規範，比如工具不健全這些都是甩都別想甩出去的鍋，有了第一步的總結歸納後，就可以在這些問題裡面，優先挑選跟業務有強關係的問題重點突破。
我當時選擇的是開發的上線流，也就是從開發到釋出這個開發團隊必須具備的剛需能力，從這條線劈出來各種工具和系統，童鞋們的反對聲音會相對低，而且由於系統的效率和穩定效能帶來更多的資源釋放，也能帶來參與同學的極大成長，所以通過規範和工程的方式來彌補內部短板，是一個非常可取的團隊管理手段，見下圖，是從 2017 年下半年之後到 2018 年，在開發上線流程上發生的變化：
這一路的基建過程大概陸續進行了半年多，基本團隊裡最人肉最髒最累的活兒，都由機器做掉了，雖然跟業務沒有直接關係，但它間接保障了業務的可持續性和穩定性，同時一路升級打怪，也讓參與開發的小夥伴們都有較大的程式設計和工程能力提升，成為最早的一批技術骨幹。
第三步 推動團隊邁向無主之地
如果已經解決掉了團隊的核心內部問題，接下來就可以把跟產品，運營、業務有關係的環節完善掉了，比如 App 線上上執行的異常監控這些，實際上在創業公司，一般是沒有一個部門直接對它負責的，大家都焦點在業務上，那麼這時候從前端團隊手裡出去的作品，理應由前端自己驅動自己來為它負責，這裡我把線上執行時的監控單獨作為一條線，它配合內部問題的 Mock 階段的 GPM（GraphQL 資料聚合服務層），都是跨出了前端團隊的職能，與其他團隊產生了關係，見下圖：
不僅對業務，對於其他的中臺部門比如人事、財務和行政都是一樣，只要有精力，都可以儘可能用成本最低的技術手段，來為公司內三不管的無主之地做一些協同的工具和系統，這會給團隊帶來很多正向的口碑，同時也有技術的提升，最重要的是，在內部問題和外部協同上，一旦你成為發起者和驅動者，你的角色和身份就發生了變化，你既是產品經理也是專案經理，既是需求方也是業務方，對於個人的綜合能力會有很大的提升，對於整個團隊在公司內部的影響力提升也有幫助，在工作中部門之間互相幫助也打下了一些底子，這一點對於不善表達比較木訥的工程師團隊很有意義。
第四步 鼓勵團隊技術與業務創新
從前面的三步，大家可以看出我的套路，帶團隊往前走，比較穩的方式就是從內到外，從技術到跨團隊事務到業務，最終也就是第四步，再回歸到業務和技術的結合，來利用技術創新驅動業務，利用業務可能性倒逼技術突破，這雖然不是終極態，但對於工程師團隊已經是一個非常可接受的狀態了。
差不多在 2018 年 5 月份開始，我開始 push 前端團隊把一隻腳邁進到業務中，無論是技術預研，還是業務場景挖掘，我們在做好業務支撐的同時，絞盡腦汁去思考，到底這麼多這麼酷的前端技術，怎麼跟我的業務產生關係，怎麼挖到產品經理挖不到的地方，另闢蹊徑為業務創造可能性，那麼在這一點上因為會觸及公司的核心商業機密，我接下來就舉一個早期的脫敏案例供大家感受。
在我們的移動生態都是 App 的時候，微信生態也在蓬勃生長，那麼如果產品延展到了小程式，我們將如何支撐，要知道此時全公司都沒有任何一個業務包括產品有過類似的具體規劃，但大家都有一些很虛的想法和概念丟進來，這時候工程師通過與業務方出差去使用者現場，去評估有沒有小程式落地的可能性，回來後我們開始做小程式的技術預研，通過這個過程，我們搶在業務和產品前面，做了必要的技術儲備，從而為後來快速開啟微信生態，進入小程式的新載體陣營打下了關鍵的技術基礎。如果工程師在這時候沒有主動進入業務的意識的話，也是完全不可能讓業務方有資訊甚至有意願來進入一個新的生態的，所以等到團隊裡的部分工程師都能成長出這種意識和能力的時候，我認為就是一個合適的時候，來做技術棧的長遠規劃了。
二、技術棧規劃
在我帶團隊的前面 10 個月，其實我也嘗試做過零碎的技術棧規劃，但效果並不盡如人意，一個是客觀基建基礎不滿足，很難做相對可靠可落地的規劃，一個是團隊成員的整體意識包括個人能力沒有上來，這時候做有點拔苗助長，甚至會引起組員的牴觸情緒，總結下就是必要的小的相對零碎的技術規劃一定要有，但不建議垮大週期做大而全的，可以做 1 ~ 1.5 年左右的。
ReactJS - 第一次大規模應用技術棧歸一
無論是 RN，還是 PC 端的 ReactJS，小菜前端的 React 技術棧在頭三年就實現歸一了，只是歸一而不規範，以及還有舊 App 是原生架構這樣的歷史包袱，但總體上到 2017 年下半年，React 技術棧外加 Webpack 是團隊的標配了。
這條歸一的技術棧結合後面的 NodeJS 能力，也就孵化了我們的兩個核心前端框架：
- 客戶端 RN 框架 Brick
- PC ERP 單頁框架 Highway
NodeJS - 第二次大規模技術棧鎖定歸一
我們再回到 NodeJS，也就 2017 年初是初步使用，2017 年底是深度使用，從 2017 年底開始，NodeJS 就成為了團隊的一個核心能力，通過它，我們把 RN 的基建全家桶一條龍全部實現了，比如腳手架，元件化，程式碼校驗，機器打包，支援白名單的熱更新發布，包安裝成功失敗與跟蹤，端使用者訪問行為資料視覺化，端執行異常監控與指派等等，這一條龍讓我們有信心來把所有的 App 全部重構為固定的 RN 版本最新的路由，
除了支撐客戶端基建，NodeJS 還為我們開啟了內部系統開發的一扇門 - 服務端能力，這扇門對於前端對於公司都是有極大好處的，從前端的角度，可以掌握更多技能可以支撐更多業務可以把技術玩的更 6，從公司的角度，在不大規模動用前後後端產品和運營的資源下，前端工程師可以獨立完成跟業務相對不那麼強耦合的業務，又省錢又省時間，是非常划算的投入產出比。
那麼在 NodeJS 這個技術棧上，我們長出了很多能力，為業務提供了大量幫助，對於團隊而言，沉澱了一個核心的服務端框架：
- Node 服務端（基於 Egg）框架 Cross
之所以研發 Cross， 是因為我們一路用 ExpressJS/KoaJS/ThinkJS 過來，框架的定製升級和整合我們想要複用的功能都不夠規範，也不夠嚴謹，直到我們使用 EggJS，基於它的強約定和外掛機制可以方便的整合過來，來定製我們自己的框架，我們再 2018 年下半年開始啟動這個框架的定製直到年底出爐。
GraphQL - 第三次小規模的技術棧嘗試
GraphQL 一定會成為 2019 年相對高頻的詞彙出現在大家的視線裡，我們是從 2017 年開始使用，同時在 2018 年 4 月份直接研發了聚合資料服務系統，整合到了我們的閘道器下面，為各個 App 端提供定製資料的能力，我們嚐到了很多甜頭，也遇到了不少阻力和調整，在 2019 年我們會持續的耕耘它，至少在特定的領域內大規模使用。
還有一些資料蒐集、加工計算和視覺化的一些組裝層我們是交給了 Python 和 C#，甚至是 Rust 的嘗試，這些都可以看做是技術預研，還不能稱為我們的核心能力，所以暫時不作為核心技術棧的演進目標。
MPVue/Vue - 第四次大規模的小程式技術棧歸一
如果說 GraphQL 是我們遇到的一個驚喜的彩蛋，那麼 Vue 則是一個讓我們驚訝的彩蛋，我們原本的演進路線裡並不包含它，但限於我們業務的複雜度，和當時市面上可選擇的侷限性，我們最終選擇了 MPVue 作為我們的小程式框架載體，那麼也自然沒有考慮京東的 Taro，那時候 Taro 還太青澀無法在生產環境用，雖然使用 MPVue 給我們帶來了很多可能性和效率，它也為我們帶來了困擾，那就是技術棧在團隊內出現了一定程度的割裂，畢竟它跟 React 的語法和生態不同，到目前為止，基於小程式的生態，我們把 MPVue 作為核心的小程式技術棧，基於這樣的一個端領域實現了歸一。
那麼總體全篇下來，會發現我們的技術棧演進，是會隨著團隊人員能力基建成熟度，也就是一定的團隊管理和成長而變化的，同時也會跟我們的業務及生態有強關聯性，除此之外，技術棧規劃確實是一個看著很客觀但實際上也比較主管的工作，它裡面雜糅了很多的因素，這些因素在不同時期的權重還不同，當團隊能力強的時候，可以規劃的長遠一些硬核一些，團隊能力弱的時候就要靈活一些。
於是從 2018 年下半年開始，我開始做相對硬核的技術棧和架構規劃，也就是有開篇的這張圖：
一共是這十二個課題和方向：
- Node 服務，支撐工具、業務系統、運維、監控等
- 前端基礎框架，支撐未來幾十個甚至上百個 PC/H5 ERP/Saas 工具系統
- 前後端協同方案，支撐特定業務領域的資料聚合，降低開發成本
- 端行為資料監控，為業務/產品/運營提供產品設計及業務調整決策
- 端效能監控跟蹤，為端可靠性穩定性提供保障
- 端資料計算中心，為視覺化、圖形影象及視訊多媒體提供高效能運算服務
- 構建部署，為多端提供整體開發、測試、打包、釋出部署提供運維能力
- 客戶端逆向，為社群/CRM/人與人新的連結關係提供必要的技術底層方案
- 安全防控，為全端提供安全監測、警報、攔截等護航保障
- 平臺元件化，為跨端提供低成本可複用的 UI 元件及未來的智慧化拼裝
- 互動研究，為互動體驗、ABTest、使用者行為價值、設計表達輸出工具與方法論
- 端/資料包表透視與視覺化，為全公司提供友好的可快速產出與維護的報表視覺化方案
這些課題向下，再延展出各個技術棧的方向規劃，就是當前團隊內我們開始並持續關注的事項了，接下來的技術棧也會順著這些課題方向而不斷的演進升級。
最後，業務支撐、技術價值、個人成長、組織升級這幾者之間的確很難達到理想中的平衡的，但基於創造更多的業務價值這一核心立論，不斷去尋找場景尋找突破點的這樣的 action 是我們作為管理者和技術骨幹所要堅持到底，無論何時，這都是優秀的工程師和技術決策者的責任和宿命 - 為人負責，併為結果負責，借事修人，借人成事。
最最後，本文作為預熱篇，旨在針對如下話題為大家輸出：
- 把團隊蠻荒到自動化運維的從 0 到 1
- 成長曆程總結輸出給社群，幫助更多的小團隊少走彎路
- 以一種可被量化的方式匯聚小菜前端的困惑、沉澱與方法路徑，給團隊帶來更多創作成就感
- 從更多視角側切進入團隊管理/技術演進/個人成長的過程中，探討工程師團隊的價值最大化
如果大家感興趣，我們小菜前端團隊，會集體智慧共同凝聚，一起撰寫並推出一本偏前端職業生涯、技術成長和團隊成長的小冊，回饋給大家，大家在文後記得留言評論和提需求哦。