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

Scott 近兩年無論是面試還是線下線上的技術(shù)分享，遇到許許多多前端同學，由于團隊原因，個人原因，職業(yè)成長，技術(shù)方向，甚至家庭等等原因，在理想國與現(xiàn)實之間，在放棄與堅守之間，搖擺不停，心酸硬抗，大家可以找我聊聊南聊聊北，對工程師的宿命有更多的了解，有更多的看見與聽見，Scott 微信： codingdream。

本系列共 15 篇，此為第一篇，大家看完轉(zhuǎn)發(fā)下朋友圈我就心滿意足了。

做規(guī)劃、管人、管資源、管優(yōu)先級，這便是一個 Tech Team Leader 的宿命。

本文 Scott 以管理者的視角，與大家分享下我自 2017 年 7 月入職小菜后，與前端同學一起是如何規(guī)劃團隊的技術(shù)棧的，這條技術(shù)棧上的技能點又是如何在不同童鞋不同業(yè)務(wù)中生長出來的。

先來看一張圖：

這張圖是 2018 年 8 月份我為團隊制定的技術(shù)棧架構(gòu)分工圖，上面基本涵蓋了 2018 ~ 2020 年團隊所需要的的技術(shù)棧能力，它也會隨著業(yè)務(wù)和團隊不斷的微調(diào)和修正，等到了 2019 年 8 月份我會重新梳理一個新版本，將來到這里分享給大家。

在帶這個團隊的一年多時間里，我對于團隊的構(gòu)想其實發(fā)生了很多次的變化，抽象的通用一點，一共會有兩個并行的過程，一個是從人和團隊視角的做好團隊規(guī)劃與管理，一個是結(jié)合業(yè)務(wù)針對團隊做具體的技術(shù)棧的演進和架構(gòu)路線調(diào)整，兩個過程會交叉實施互相影響。這些方法和結(jié)論也有它特殊的公司背景和局限性，未必適用于大家所在業(yè)務(wù)形態(tài)下的團隊，千萬不要硬搬，可以關(guān)注下這些過程中的變化，以及我的思考過程，最終我們再回到上面的這張圖上，大家就能明白一個團隊的技術(shù)棧架構(gòu)和演進背后的方法論了。

首先說團隊管理，這個是前提，沒有配套的團隊管理手段輔助，是很難單純的讓技術(shù)棧發(fā)生持續(xù)的好的變化，也很難將架構(gòu)理念推進落地的，在團隊管理這里我主要是分成四步走。

新加入到一個團隊，尤其是成為資深工程師后新帶領(lǐng)一個團隊，除了埋頭做事外，有一個很重要的事情要盡早做，那就是去了解團隊，方式有很多，比如：

主動去看團隊倉庫里的歷史代碼，了解大家的編碼水平，編程風格，工程維護的方式，架構(gòu)的成熟度

與每個同學多帶帶聊聊天，聊聊他對于一個技術(shù)的看法，對于業(yè)務(wù)上思考，對于自己和所處團隊的認知

請大家去吃吃飯，聽聽大家都聊什么，玩什么，關(guān)注什么，每個人的氣場和表達方式，在辦公桌和餐桌上有什么不同

找服務(wù)端團隊和業(yè)務(wù)團隊的同學，問問他們對于前端團隊的印象，對于合作童鞋的看法

在會議上拋出一些問題，觀察大家的參與積極性和表述觀點的深度

還可以一起去打游戲看電影，一起參加公司活動等等，這是一個比較粗的了解，我進團隊后，也是挑了上面兩三種方式對團隊成員有了一個比較粗的摸底，看到了很多好的特征也看到了不少問題。

好的方面：都很年輕很聰明，學習能力較好，可塑性都很強，沒什么城府，對技術(shù)有激情也有熱情，技術(shù)棧很新穎，每個人潛力都很大。

基于這些，可以預判這個團隊只要理清楚每個階段的重點，就可以快速成長，每個人都能不斷的突破天花板，所以大盤子的性質(zhì)不錯，資質(zhì)也不錯，再來看看問題：

問題：職場的專業(yè)度不夠，比較情緒化，對于業(yè)務(wù)多變有一定抵觸，職業(yè)規(guī)劃無感知，對于好的不好的評判標準比較狹隘比較封閉，整體工具化工程化以及基建的方向都沒有太多思考，對于整個行業(yè)的判斷比較粗淺，屬于比較原始蠻荒的階段，團隊成員的能力層次不齊，補位與大局意識比較薄弱。

具體的方法論，可以把近幾周的問題做匯總，然后給它們打標分類，比如這樣：

結(jié)合業(yè)務(wù)和開發(fā)過程，來梳理問題共性，最終的問題可以總結(jié)為：

人心不穩(wěn)定

技能短板多

職業(yè)無規(guī)劃

合作意識差

團隊無規(guī)范

工具基建弱

業(yè)務(wù)無感知

梯隊未搭建

基于這些，可以預判團隊需要一個不短的磨合期，在磨合期中需要先逐步建立信任，同時針對不同的問題需要學唐僧跟大家經(jīng)常講多講，也就是通過灌輸讓大家先有一個正確做事的概念在腦海中，然后再針對每一個同學的特征，以不同的方式分配任務(wù)，驅(qū)動和輔導，另外，需要有一些事情大家要一起做來形成團隊合力和凝聚力，我最終選擇了技術(shù)分享作為一個大家共同做的事情，讓團隊在這一件事情達成唯一的共識 - 技術(shù)團隊影響力的提升和個人總結(jié)能力的提高。

所謂內(nèi)部短板，就是完全是自己的鍋的問題，比如發(fā)布系統(tǒng)不完善，比如代碼不規(guī)范，比如工具不健全這些都是甩都別想甩出去的鍋，有了第一步的總結(jié)歸納后，就可以在這些問題里面，優(yōu)先挑選跟業(yè)務(wù)有強關(guān)系的問題重點突破。

我當時選擇的是開發(fā)的上線流，也就是從開發(fā)到發(fā)布這個開發(fā)團隊必須具備的剛需能力，從這條線劈出來各種工具和系統(tǒng)，童鞋們的反對聲音會相對低，而且由于系統(tǒng)的效率和穩(wěn)定性能帶來更多的資源釋放，也能帶來參與同學的極大成長，所以通過規(guī)范和工程的方式來彌補內(nèi)部短板，是一個非?？扇〉膱F隊管理手段，見下圖，是從 2017 年下半年之后到 2018 年，在開發(fā)上線流程上發(fā)生的變化：

這一路的基建過程大概陸續(xù)進行了半年多，基本團隊里最人肉最臟最累的活兒，都由機器做掉了，雖然跟業(yè)務(wù)沒有直接關(guān)系，但它間接保障了業(yè)務(wù)的可持續(xù)性和穩(wěn)定性，同時一路升級打怪，也讓參與開發(fā)的小伙伴們都有較大的編程和工程能力提升，成為最早的一批技術(shù)骨干。

如果已經(jīng)解決掉了團隊的核心內(nèi)部問題，接下來就可以把跟產(chǎn)品，運營、業(yè)務(wù)有關(guān)系的環(huán)節(jié)完善掉了，比如 App 在線上運行的異常監(jiān)控這些，實際上在創(chuàng)業(yè)公司，一般是沒有一個部門直接對它負責的，大家都焦點在業(yè)務(wù)上，那么這時候從前端團隊手里出去的作品，理應由前端自己驅(qū)動自己來為它負責，這里我把線上運行時的監(jiān)控多帶帶作為一條線，它配合內(nèi)部問題的 Mock 階段的 GPM（GraphQL 數(shù)據(jù)聚合服務(wù)層），都是跨出了前端團隊的職能，與其他團隊產(chǎn)生了關(guān)系，見下圖：

不僅對業(yè)務(wù)，對于其他的中臺部門比如人事、財務(wù)和行政都是一樣，只要有精力，都可以盡可能用成本最低的技術(shù)手段，來為公司內(nèi)三不管的無主之地做一些協(xié)同的工具和系統(tǒng)，這會給團隊帶來很多正向的口碑，同時也有技術(shù)的提升，最重要的是，在內(nèi)部問題和外部協(xié)同上，一旦你成為發(fā)起者和驅(qū)動者，你的角色和身份就發(fā)生了變化，你既是產(chǎn)品經(jīng)理也是項目經(jīng)理，既是需求方也是業(yè)務(wù)方，對于個人的綜合能力會有很大的提升，對于整個團隊在公司內(nèi)部的影響力提升也有幫助，在工作中部門之間互相幫助也打下了一些底子，這一點對于不善表達比較木訥的工程師團隊很有意義。

從前面的三步，大家可以看出我的套路，帶團隊往前走，比較穩(wěn)的方式就是從內(nèi)到外，從技術(shù)到跨團隊事務(wù)到業(yè)務(wù)，最終也就是第四步，再回歸到業(yè)務(wù)和技術(shù)的結(jié)合，來利用技術(shù)創(chuàng)新驅(qū)動業(yè)務(wù)，利用業(yè)務(wù)可能性倒逼技術(shù)突破，這雖然不是終極態(tài)，但對于工程師團隊已經(jīng)是一個非?？山邮艿臓顟B(tài)了。

差不多在 2018 年 5 月份開始，我開始 push 前端團隊把一只腳邁進到業(yè)務(wù)中，無論是技術(shù)預研，還是業(yè)務(wù)場景挖掘，我們在做好業(yè)務(wù)支撐的同時，絞盡腦汁去思考，到底這么多這么酷的前端技術(shù)，怎么跟我的業(yè)務(wù)產(chǎn)生關(guān)系，怎么挖到產(chǎn)品經(jīng)理挖不到的地方，另辟蹊徑為業(yè)務(wù)創(chuàng)造可能性，那么在這一點上因為會觸及公司的核心商業(yè)機密，我接下來就舉一個早期的脫敏案例供大家感受。

在我們的移動生態(tài)都是 App 的時候，微信生態(tài)也在蓬勃生長，那么如果產(chǎn)品延展到了小程序，我們將如何支撐，要知道此時全公司都沒有任何一個業(yè)務(wù)包括產(chǎn)品有過類似的具體規(guī)劃，但大家都有一些很虛的想法和概念丟進來，這時候工程師通過與業(yè)務(wù)方出差去用戶現(xiàn)場，去評估有沒有小程序落地的可能性，回來后我們開始做小程序的技術(shù)預研，通過這個過程，我們搶在業(yè)務(wù)和產(chǎn)品前面，做了必要的技術(shù)儲備，從而為后來快速打開微信生態(tài)，進入小程序的新載體陣營打下了關(guān)鍵的技術(shù)基礎(chǔ)。如果工程師在這時候沒有主動進入業(yè)務(wù)的意識的話，也是完全不可能讓業(yè)務(wù)方有信息甚至有意愿來進入一個新的生態(tài)的，所以等到團隊里的部分工程師都能成長出這種意識和能力的時候，我認為就是一個合適的時候，來做技術(shù)棧的長遠規(guī)劃了。

在我?guī)F隊的前面 10 個月，其實我也嘗試做過零碎的技術(shù)棧規(guī)劃，但效果并不盡如人意，一個是客觀基建基礎(chǔ)不滿足，很難做相對可靠可落地的規(guī)劃，一個是團隊成員的整體意識包括個人能力沒有上來，這時候做有點拔苗助長，甚至會引起組員的抵觸情緒，總結(jié)下就是必要的小的相對零碎的技術(shù)規(guī)劃一定要有，但不建議垮大周期做大而全的，可以做 1 ~ 1.5 年左右的。

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

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

客戶端 RN 框架 Brick

PC ERP 單頁框架 Highway

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

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

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

Node 服務(wù)端（基于 Egg）框架 Cross

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

GraphQL 一定會成為 2019 年相對高頻的詞匯出現(xiàn)在大家的視線里，我們是從 2017 年開始使用，同時在 2018 年 4 月份直接研發(fā)了聚合數(shù)據(jù)服務(wù)系統(tǒng)，集成到了我們的網(wǎng)關(guān)下面，為各個 App 端提供定制數(shù)據(jù)的能力，我們嘗到了很多甜頭，也遇到了不少阻力和調(diào)整，在 2019 年我們會持續(xù)的耕耘它，至少在特定的領(lǐng)域內(nèi)大規(guī)模使用。

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

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

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

于是從 2018 年下半年開始，我開始做相對硬核的技術(shù)棧和架構(gòu)規(guī)劃，也就是有開篇的這張圖：

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

Node 服務(wù)，支撐工具、業(yè)務(wù)系統(tǒng)、運維、監(jiān)控等

前端基礎(chǔ)框架，支撐未來幾十個甚至上百個 PC/H5 ERP/Saas 工具系統(tǒng)

前后端協(xié)同方案，支撐特定業(yè)務(wù)領(lǐng)域的數(shù)據(jù)聚合，降低開發(fā)成本

端行為數(shù)據(jù)監(jiān)控，為業(yè)務(wù)/產(chǎn)品/運營提供產(chǎn)品設(shè)計及業(yè)務(wù)調(diào)整決策

端性能監(jiān)控跟蹤，為端可靠性穩(wěn)定性提供保障

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

構(gòu)建部署，為多端提供整體開發(fā)、測試、打包、發(fā)布部署提供運維能力

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

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

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

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

端/數(shù)據(jù)報表透視與可視化，為全公司提供友好的可快速產(chǎn)出與維護的報表可視化方案

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

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

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

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

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

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

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

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