摘要：本文以管理者的視角，與大家分享下我自年月入職小菜后，與前端同學一起是如何規劃團隊的技術棧的，這條技術棧上的技能點又是如何在不同童鞋不同業務中生長出來的。

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 年左右的。

無論是 RN，還是 PC 端的 ReactJS，小菜前端的 React 技術棧在頭三年就實現歸一了，只是歸一而不規范，以及還有舊 App 是原生架構這樣的歷史包袱，但總體上到 2017 年下半年，React 技術棧外加 Webpack 是團隊的標配了。

這條歸一的技術棧結合后面的 NodeJS 能力，也就孵化了我們的兩個核心前端框架：

客戶端 RN 框架 Brick

PC ERP 單頁框架 Highway

我們再回到 NodeJS，也就 2017 年初是初步使用，2017 年底是深度使用，從 2017 年底開始，NodeJS 就成為了團隊的一個核心能力，通過它，我們把 RN 的基建全家桶一條龍全部實現了，比如腳手架，組件化，代碼校驗，機器打包，支持白名單的熱更新發布，包安裝成功失敗與跟蹤，端用戶訪問行為數據可視化，端運行異常監控與指派等等，這一條龍讓我們有信心來把所有的 App 全部重構為固定的 RN 版本最新的路由，

除了支撐客戶端基建，NodeJS 還為我們打開了內部系統開發的一扇門 - 服務端能力，這扇門對于前端對于公司都是有極大好處的，從前端的角度，可以掌握更多技能可以支撐更多業務可以把技術玩的更 6，從公司的角度，在不大規模動用前后后端產品和運營的資源下，前端工程師可以獨立完成跟業務相對不那么強耦合的業務，又省錢又省時間，是非常劃算的投入產出比。

那么在 NodeJS 這個技術棧上，我們長出了很多能力，為業務提供了大量幫助，對于團隊而言，沉淀了一個核心的服務端框架：

Node 服務端（基于 Egg）框架 Cross

之所以研發 Cross， 是因為我們一路用 ExpressJS/KoaJS/ThinkJS 過來，框架的定制升級和集成我們想要復用的功能都不夠規范，也不夠嚴謹，直到我們使用 EggJS，基于它的強約定和插件機制可以方便的集成過來，來定制我們自己的框架，我們再 2018 年下半年開始啟動這個框架的定制直到年底出爐。

GraphQL 一定會成為 2019 年相對高頻的詞匯出現在大家的視線里，我們是從 2017 年開始使用，同時在 2018 年 4 月份直接研發了聚合數據服務系統，集成到了我們的網關下面，為各個 App 端提供定制數據的能力，我們嘗到了很多甜頭，也遇到了不少阻力和調整，在 2019 年我們會持續的耕耘它，至少在特定的領域內大規模使用。

還有一些數據搜集、加工計算和可視化的一些組裝層我們是交給了 Python 和 C#，甚至是 Rust 的嘗試，這些都可以看做是技術預研，還不能稱為我們的核心能力，所以暫時不作為核心技術棧的演進目標。

如果說 GraphQL 是我們遇到的一個驚喜的彩蛋，那么 Vue 則是一個讓我們驚訝的彩蛋，我們原本的演進路線里并不包含它，但限于我們業務的復雜度，和當時市面上可選擇的局限性，我們最終選擇了 MPVue 作為我們的小程序框架載體，那么也自然沒有考慮京東的 Taro，那時候 Taro 還太青澀無法在生產環境用，雖然使用 MPVue 給我們帶來了很多可能性和效率，它也為我們帶來了困擾，那就是技術棧在團隊內出現了一定程度的割裂，畢竟它跟 React 的語法和生態不同，到目前為止，基于小程序的生態，我們把 MPVue 作為核心的小程序技術棧，基于這樣的一個端領域實現了歸一。

那么總體全篇下來，會發現我們的技術棧演進，是會隨著團隊人員能力基建成熟度，也就是一定的團隊管理和成長而變化的，同時也會跟我們的業務及生態有強關聯性，除此之外，技術棧規劃確實是一個看著很客觀但實際上也比較主管的工作，它里面雜糅了很多的因素，這些因素在不同時期的權重還不同，當團隊能力強的時候，可以規劃的長遠一些硬核一些，團隊能力弱的時候就要靈活一些。

于是從 2018 年下半年開始，我開始做相對硬核的技術棧和架構規劃，也就是有開篇的這張圖：

一共是這十二個課題和方向：

Node 服務，支撐工具、業務系統、運維、監控等

前端基礎框架，支撐未來幾十個甚至上百個 PC/H5 ERP/Saas 工具系統

前后端協同方案，支撐特定業務領域的數據聚合，降低開發成本

端行為數據監控，為業務/產品/運營提供產品設計及業務調整決策

端性能監控跟蹤，為端可靠性穩定性提供保障

端數據計算中心，為可視化、圖形圖像及視頻多媒體提供高性能計算服務

構建部署，為多端提供整體開發、測試、打包、發布部署提供運維能力

客戶端逆向，為社群/CRM/人與人新的鏈接關系提供必要的技術底層方案

安全防控，為全端提供安全監測、警報、攔截等護航保障

平臺組件化，為跨端提供低成本可復用的 UI 組件及未來的智能化拼裝

交互研究，為交互體驗、ABTest、用戶行為價值、設計表達輸出工具與方法論

端/數據報表透視與可視化，為全公司提供友好的可快速產出與維護的報表可視化方案

這些課題向下，再延展出各個技術棧的方向規劃，就是當前團隊內我們開始并持續關注的事項了，接下來的技術棧也會順著這些課題方向而不斷的演進升級。

最后，業務支撐、技術價值、個人成長、組織升級這幾者之間的確很難達到理想中的平衡的，但基于創造更多的業務價值這一核心立論，不斷去尋找場景尋找突破點的這樣的 action 是我們作為管理者和技術骨干所要堅持到底，無論何時，這都是優秀的工程師和技術決策者的責任和宿命 - 為人負責，并為結果負責，借事修人，借人成事。

最最后，本文作為預熱篇，旨在針對如下話題為大家輸出：

把團隊蠻荒到自動化運維的從 0 到 1

成長歷程總結輸出給社區，幫助更多的小團隊少走彎路

以一種可被量化的方式匯聚小菜前端的困惑、沉淀與方法路徑，給團隊帶來更多創作成就感

從更多視角側切進入團隊管理/技術演進/個人成長的過程中，探討工程師團隊的價值最大化

如果大家感興趣，我們小菜前端團隊，會集體智慧共同凝聚，一起撰寫并推出一本偏前端職業生涯、技術成長和團隊成長的小冊，回饋給大家，大家在文后記得留言評論和提需求哦。