第二屆搞基建|Scott - 如何在人單力薄時立項推進基建

前端早早聊大會，前端成長的新起點，與掘金聯合舉辦。加微信 codingdreamer 進大會專屬內推羣，贏在新的起跑線。前端

第十四屆|前端成長晉升專場，8-29 即將直播，9 位講師(螞蟻金服/稅友等)，點我上車👉 (報名地址)：node

本文是第三場講師 - Scott 的講稿文字版，來聽聽他的觀點，視頻及 PPT 將來在公衆號放出。算法

你們下午好，聽完前面講師的分享，相信你們結合本身的團隊狀況，必定會發現，其實在個人團隊，也是有蠻多基建機會的，可是我天天都在作業務啊，騰不出人手作基建怎麼辦呢，特別是個人老闆也不認同我拿出業務的時間作基建怎麼辦呢，那咱們接下來就聊聊這個話題。編程

自我介紹

首先作個自我介紹，我早年在阿里巴巴作前端，當時團隊已經在作基建的事情，不管是單頁的 SPA 框架，仍是組件化的初始化與上傳工具，以後聯合創立 Moveha|CR 並擔任 CTO，這時候基建幾乎都停滯了，一切都向業務低頭，團隊同窗的成長也放緩了，以後到了宋小菜這家公司，負責大前端團隊，從 6 到 20 人搭建團隊，遇到了極大的研發壓力，爲了充分釋放生產力，咱們開始專一供應鏈大前端的跨端工具工程化，同時重視年輕工程師的潛力發掘與成長輔導，這三年下來在基建方面算是小有斬獲，這就是我這三段職業生涯的狀況。小程序

除了這三段職業歷程，其實我從 2012 年就開始接觸編程教育領域了，兼職參與加拿大編程教育平臺 UULearn 創業孵化，那時候開始用 Node.js 作頁面的批量的生成，也是在這時候發現了 Node.js 對於前端工程師提效的重要性，後面也就在 2013 年入駐慕課網，推出 10 多門 Node.js 相關的課程，觀看用戶超過 50 萬人次，從這些同窗中獲得了大量的提問，大部分都關於技術探索與成長，今年也正式成立了早早聊職業輔導社羣，接觸的前端工程師你們廣泛反映作基建的面臨的困難，這些都是從我的視角能感覺到的。後端

另外對於團隊的部分，特別是從橫向的視角看的時候，有沒有更系統化的思考和方法論呢，我以爲應該請更多講師來參與討論，因而這也致使了我發起第二屆前端早早聊大會，也就有了今天下午的場子。服務器

團隊的基建成果

小菜的前端應用，目前有 60 個上下，既有 APP，也有 H5 和 PC，還有小程序，團隊成立至今有 5 年，開始作基建到如今有 3 年，而團隊的前端從初級、到高級和資深，進而到專家，他們的能力成長也都是在這三年的基建過程當中完成的，有 3/4 的專家都是一路作基建起來的，或者說是大比重的參與了基建，不管是腳手架、報表工具、表單工具、監控全鏈路等等。微信

截至目前，咱們也沉澱了大大小小 20 個基建的工具、系統或者平臺，好比組件化就沉澱了將近 70 個，應用到 APP 和 H5 裏面，這一路走完了基建的 0 到 1，這個過程當中最難的部分每每不是具體的代碼實現，而是問題定位和立項推進，那今天就從個人視角，跟你們把基創建項這件事有哪些經驗性方法作個分享。markdown

分享大綱

今天跟你們分享主要從人和項目這兩個維度切進去，關於人和項目的關係，我一項秉持的態度是：不管當前的項目多難多糟糕，下一次項目均可以從新開始。前端工程師

咱們假設一個同窗進入了一家新公司，或者轉崗到一個新團隊，切換到一個新業務線，接手了一個新項目，這都是一次全新的開始，不管是從技術、從基建、仍是從我的的綜合成長，都是一個新起點。而按照上圖的 A ~ F 的過程當中，咱們把它想象成爲一個理想的模型，最開始你作項目是學習入門的階段，是很難具有基建的前瞻性和實力的，能夠專心作項目直到能夠熟練的編程，一直到能單挑同類型的項目，這時候就能夠獨當一面的獨立跟進項目了，基於這個基礎，對於不一樣團隊之間的配合關係，對於業務的理解，對於技術和項目關係的認知都比較深了，也就是業務上得心應手的時候，就能夠來考慮作提效降本的事情了，所謂提效降本，主要的抓手就是基建，從這個起點開始作基建是站在同類型業務和項目的視角，再日後就是站在團隊的視角，解決團隊廣泛存在的共性問題，再日後就是解決跨部門跨事業部的問題，這時候基建就上升到了公司甚至是行業的視角，經過這樣的路徑，基建的功力纔會逐年遞增。

而到了意識層面和執行層面，我把今天分享的內容分爲 4 部分：

作不作基建，作多少基建跟團隊是什麼關係，咱們來定位下基建的價值
如何尋找基建的機會，如何識別問題和場景，來基於摸底概括問題
站在人的角度，看選什麼人來參與基建，從而提高基建氛圍
在方法論這一側，有哪些方式能夠有助於我推進基建這件事情發生

最後是答疑，經過這樣的幾部分，來打消掉你們團隊弱小時候如何作基建的疑慮。

作基建要知道的三件事

在正式分析前端與團隊的關係前，先跟你們掏心窩說下我對於基建的見解：

基建的真正價值提效降本與成長

第一個見解是：當咱們提到基建，就要想到三個詞：

提效
降本
成長

提效降本的對象能夠是人、業務、產品體驗甚至是業務，成長則是咱們全部從基建中受到的啓發。落實到技術團隊中，團隊研發實力的強弱主要跟研發模式和工程師我的能力相關，而第三個最大的因素就是歷年儲備至今的基礎設施完備程度，越強的基礎設施，就帶來越強的團隊研發實力。

基建難點皆爲現狀重點皆爲管理

第二個見解是：基建的起點雖然是技術，但他的重點都是管理，要去管理人，管理錢和優先級，那麼綜合到行業、公司、組織、團隊、小組和業務運營產品等全部內在外在的現實條件，有時候即使看到了基建價值，也未必有機會來實現，這就是基建的難，它就像一架架飛機同樣，從起飛到降落不只要知足不少條件，也要接受全程的監管。

基建再高大上也要有目標與節奏

第三個見解是：不管基建是解決開發體驗的問題、研發效率問題，產品質量和穩定性的問題，不管它是小而美仍是大而全的，項目都須要有它肯定性的目標和推動的節奏，若是缺乏這些度量單位，就很難造成共識，若是缺乏共識，就勢必會遭遇阻力。

作基建最頭疼的三大難

聽我講完前面的三件事，相信你們腦海中就感覺了基建的難，事實是這樣的，基建有不少方面的難，其中最難的這三部分：

判斷與決策難

不管是做爲前端 Leader，仍是前端同窗我的，要在表象的問題中定義價值，來決定作什麼基建，爲何作，當下要不要作，應該用什麼方式作，以及須要誰來配合作，這件事是困難的。

共識與受權難

天天加班都作不完業務，時間被佔用的滿滿的，也招不到人甚至根本不給招人，想要升級電腦配置、購買地方服務和換高性能服務器都很難實現，我想好的想法提給老闆，老闆也不認同，更不肯意受權給我，想要跟這個組織體達成共識是困難的。

實現與推廣難

團隊根本沒幾個前端，大部分剛畢業不久，天天切切頁面、調調接口、改改 Bug，沒有利害的前端大佬帶隊，找不到將來團隊基建規劃的方向，不清楚技術上如何架構實現，缺乏能夠參考甚至抄來即用的技術方案，作出一些成果卻很難推廣，這件事也難。

之因此有這麼難，有咱們主觀的緣由，也有客觀的緣由，最重要的是，咱們須要回到原點來看這些困難，從新認知它們。

1、定位 - 基建與前端團隊的關係

越是人少的團隊，也要深入認識基建的價值和能力，以及它與團隊的關係，

定義 - 什麼是基建

在你的團隊裏面，若是沉澱了幾十個 UI 的組件能夠複用，這件事是否是基建呢，顯然它是的，若是是基於組件搭建個業務模板市場呢，顯然也是的，作個腳手架也是，作一個跨平臺的小程序生成框架也是，甚至小到約定好咱們 10 個前端的工程代碼文件夾的大小寫和變量的命名方式、不一樣分支之間合併的規範和寫一份上線的自測文檔，顯然這也是技術設施和能力建設，咱們就發現如圖上的這些監控啊、插件啊、圖表啊等等都算是基建。

結合上述內容，我對基建的定義：

一切有利於研發效能提高的，直接或者間接助力於業務開展的的能力建設皆爲基建。

這就是我理解的廣義的基建，它多是一個技術方案，多是幾篇文檔，多是一場內部的項目培訓，最終都是爲了促成咱們研發實力的提高和業務上的達成，而在研發實力部分就如咱們前文提到的是研發方式、工程師能力和基礎設施完備程度的綜合體。

事實上，今天的咱們能發現，基建早就無處不在了，只不過有些基建未必是咱們親手作的罷了，好比咱們作了一個可視化搭建表單頁面的平臺，它底下可能組件部分的基建，這部分多是螞蟻金服幫咱們作好的 Ant Design，或者是咱們本身動手實現的組件，而咱們本身作的組件，從初始化到測試到上線到託管，是依賴咱們的 NPM 包管理工具，這個 NPM 又是社區給咱們作好的基建，而 NPM 又是跑在 Node.js 上面的，那麼這個 Node.js 又是 NPM 所依賴的基建設施了，如此種種，咱們早已站到了整個行業大量的基建設施的肩膀上了，它多是 Babel，多是 Vue、React 多是 Webpack，不管咱們是否動手在作，咱們早就身處整個行業的基建生態之中，我想聊到這裏，你們對於什麼是基建必定有了一個更明顯的感覺，它就在咱們的身邊就在咱們的視野下，是無處不在的。

定位 - 團隊的生命週期

左邊這張圖我是改造自螞蟻金服玉伯大大的圖，出處找不到了，大意就是前端團隊會經歷的幾個重要階段，或者叫這個團隊成長的生命週期，我把它具象了一下：

人肉時代

一般是在初創早期的前端團隊，或者公司新業務線組建的團隊，人丁稀少，缺乏大牛，趁手的工具不多，協同的規範流程比較原始，以快速完成項目快速支撐業務進展爲核心目標，其餘不少事情都顧不上，代碼也是快速的攢起來，每每一些技術債都是在這個階段留下來的，這個時代的主要特徵就是不只缺少基建的工具，也缺少基建的意識，而且粗糙的研發模式致使線上的產品質量和體驗是層次不齊的，也致使人員的流動性很大，很容易帶着情緒作事。

同時處在這個階段的團隊負責人，一般是以點狀的思惟在規劃團隊成長，由於天天都在救火，沒法脫離戰場看大盤，三年前的小菜前端就是處在這個階段，那時候咱們不到 10 我的

工具時代

這個階段，團隊已經儲備了必定數量的很好用的基建設施，不管是文檔規範、組件化，仍是接口聚合，仍是腳手架，你們的配合也趨於穩定，技術棧也基本統一，雖然開發資源仍是很緊張，可是能夠較好的支持高優先級的業務，勉強支撐併發的平常，開發體驗有很多地方不夠好，但總體的研發能力還算過關。

同時處在這個階段的負責人，一般是以線狀的思惟來規劃團隊的研發節奏和資源比例，也在嘗試着工程化方面的思考。如今咱們的團隊就處在這個階段，差很少 20 個前端，20 個基建工具，支撐 60 個應用，平均一我的頂 2~3 個，有半隻腳剛剛邁進工程化的時代。

工程時代

這個階段，前端的內部影響力已經很強了，不管是從產品交互的研究和業務驅動，仍是跨部門視角的技術方案佈道推廣，甚至到業界的工程化經驗輸出，都有大量的戰利品，最重要的是造成了完整的研發體系，從規範到項目開發到部署到監控整個體系是成建制的造成，大部分團隊成員都具有了很強的業務意識和研發能力，總體的開發體驗也很不錯，業務上大部分非高複雜度的項目都能較好的支持解決。這是目前市面上咱們已知的一線互聯網大廠的部分團隊達到的階段，非一二線互聯網大廠裏面，現在達到這個階段，據我所知是少之又少，這也是咱們小菜前端將來 2 年要奮鬥的方向，今天來分享的講師，也都處在這個時代的早期或者中期，將來的路依然很長。

智能時代

這個階段，可視化搭建、智能搭建與生成都在業務中有了很深刻的應用，好比阿里雙十一的 Banner 生成工具，創意視頻生成工具、設計稿轉頁面的生成工具等等，給設計和產品帶來了巨大的生產力解放，也給公司節省了巨大的研發資源，整個工程化的土壤已經很是成熟，技術生態也很是豐富，不少方面都在作整個行業不多聽聞的探索和嘗試，據我說知，目前也只有螞蟻體驗技術部和淘系的工程化相關團隊，已經有半隻腳踏進來到這個階段，其餘的團隊還都在工程化逼近智能化的路上，這也是咱們前端行業截至目前能看到的那個最遠的地方，值得咱們全部人努力。

小菜的幾個小階段

咱們團隊發展了 5 年，從人肉時代進入到了工具時代，目前正在邁向工程化時代，中間經歷了幾回里程碑事件：

第一次是 2016 年，把原生語言的 APP 開發所有轉向 RN 開發，雖然損失了一部分的性能和體驗，但直接解鎖了前端的開發效率，讓咱們能夠用極低的人力成本，同時支撐好幾款 APP 的並行開發，只不過當時爲了快也形成了大量的團隊問題，不管是人的仍是事兒的
第二次是 2017 年擁抱 Node.js，鼓勵大部分同窗大面積的使用 Node.js 造輪子，特別是打包推包部署熱更新等一條龍的建設，極大的下降了發版的出錯率也極大的提升了上線發佈的效率，讓前端的能力從前端打到了後端，也就是具有了最基礎的全棧能力
第三次是 2018 年瘋狂的嘗試造各類提效的輪子，不管是 APP 研發一條龍，仍是 PC/H5 的部署，仍是工程框架和報表可視化，幾乎全面開發，整個重塑了小菜前端的研發生態，咱們也是從這一年纔開始走出來分享的
第四次是 2019 年把全部端上的技術棧統一，APP 用一套固定版本的工程框架，PC/H5/小程序都是，包括 Node.js，也放棄了從前裸寫的 Koa/Thinkjs 和 Express，全面轉向基於 Eggjs 封裝的企業內部服務框架，同時也把全部的端作了收斂統一，這個目前還在開發中，尚未完成，至於 2020 年，咱們也充滿期待，但願天下一統後，就走向更豐富生態的工程化階段。

這個話題我用了比較大的篇幅，主要是讓你們感覺到基建對於前端團隊往前面大踏步迭代的重要性，沒有基建，團隊是不可能向前躍遷的，也讓你們感知到基建能夠助力團隊成長的程度，前面是星辰大海等着咱們。

定位 - 基建與團隊的關係

我把上面提到的四個階段，以及基建跟咱們團隊結合後所發酵的結果，提煉出來這三個觀點，來形容基建和團隊的關係：

基建是團隊前進的車輪要穩

前端喜歡造輪子，其實輪子就是我理解的基建，好的輪子必定會讓咱們更快，但還有一個很重要的考量實際上是到底穩不穩，若是裝了 4 個不一樣尺寸不一樣材質的輪子，項目中既有 Vue，又有 jQuery，又有 React，這就會讓咱們運行項目中，遇到更多的不肯定性，因此咱們會有監控系統，會有測試工具。

基建是團隊助力的引擎要快

快是研發實力最直觀的一個體現，咱們作基建就是爲了讓項目開發的更快，因此有自動化構建工具，會有頁面搭建工具，越是到關鍵項目的時候，越是考驗咱們基建能力強弱的時候。

基建是人才的練兵場讓脫困更強

都說工程師是公司最寶貴也是最昂貴的資產，那麼既然如此就要人盡其用，發揮最大的主觀能動性，就應該有儘量多的利於工程師成長的機會被創造出來，而後經過工程師我的實力的加強，來帶動整個團隊研發實力的加強，因此咱們會有培訓，會有文檔的傳承，會有幫帶，也會有作基礎架構的同窗。

固然用一臺賽車來形容基建仍是不夠嚴謹的，咱們用武裝二字或許更爲合適，經過對團隊的武裝和再造來達到所謂又快又穩又強的目標。

2、摸底 - 問題與場景的識別方法

當咱們瞭解到基建對於團隊的必要性和重要性，以及基建對於團隊不一樣發展階段所能發酵出來的力量，咱們就要面臨下一個問題，如何在團隊中找到基建的機會呢，有什麼方法能夠把這種基建機會定位出來呢。

從問題點歸類出發

這張截圖是我剛帶小菜團隊的頭幾個月，所彙總的問題，有不少問題都是極爲嚴重的線上故障，甚至對業務形成了很大的傷害的，好比業務方在一線焦急等待咱們功能上線後，他們好開始作促銷，結果咱們整下午成天的打不出 APP 的安裝包，緣由是這個同窗的電腦環境不當心作了調整，而後再換一我的的電腦打包，再打不出來，再換一我的，結果打出的包代碼竟然有了問題，就這樣一而再再而三的把時間給耗費過去了，關鍵是相似的問題層出不窮，隔兩天來一次隔兩天來一次，團隊全部人的頭都很大，業務方也炸了，當時面對這種問題，個人辦法就是圖上這種，在解決問題的時候，把問題都記錄下來，而且對他們歸來，主要按照技能、合做、工具、規範、職業性、團隊穩定性、業務理解等維度，跑了一段時間後，基本上問題也都經歷一遍了，這個表格也就沉澱出來了，再結合當時的開發流程，就會有初步的判斷：這些雖然看上去都是單點問題，但背後的緣由都是有多方關聯的，並非單點，這時候必須放棄掉不少問題，挑重點問題解決。

摸底 - 問題現場的還原

要造成主要問題的判斷，就必須回到當時的現場，回到現場的方式就是對問題作覆盤，在覆盤中總結規律，好比咱們爲何打包出問題呢，就把這個流程整理出來，好比宋小福這個內部 CRM APP 要打一個 iOS 的連接測試環境的，不進行熱更新功能的帶 Debug 功能的安裝包，若是這個包是 B 同窗打出來的，那麼它可能就是一個獨一無二的包，又由於每一個同窗本地的 Node 版本和 NPM 版本不一樣，會致使包所依賴的語義化的其它包版本會有出入，好比有的是 Yarn，有的是舊的 NPM，有的是新的 NPM，那麼在工程的 node_modules 中，代碼就有了差別性，這再疊加上 XCode/Gradle/本地證書/配置文件/熱更新開關等諸多變量，加上倉庫分支的合併甚至是人肉上傳包的方式等可能出錯的環節，會致使用戶所收到的安裝包都是獨一無二的。

若是再把平臺、環境、熱更新都考慮起來，就這一個宋小福 APP 就能打出 8 個不一樣的包，若是帶上 Debug 開關，那就是 16 個包，若是加上每一個同窗本身本地環境的差別性，就變成了 64 個包，若是把 5 個 APP 都算是，那就是超過 300 個包要管理，固然實際狀況並不會真打出來這麼多包，只是這麼多的可能性就指數倍的放大了打包發包出錯的機率，因此還原了這個場景，問題的嚴重性就出來了，這就是當下咱們首先要解決的問題，而且必定不是靠人肉解決，由於三令五申的人肉約束已經證明沒有效果。

路徑 - 從現場回到方案終局

定位到了問題，還原了現場，就要有一個理想的終局方案，這個圖是咱們當初所達成的共識，針對不一樣類型的 APP 制定不一樣的發佈策略，這是咱們理想中的方案，或者叫作是咱們腦子中的想法，它能不能實現，還要有一個很重要的東西保障，那就是制度面，或者叫作流程面和權限面，也就是具體到人。

路徑 - 從方案回到人頭流程

有了問題、緣由和指望的終局，咱們就要把人這個因素加進去，來在流程上作一些節點的把控，經過動做隔離，不管它是物理的仍是軟件系統的仍是口頭流程的，來造成權限的收斂和責任到人的指派，這樣整個團隊全部人都在這一層達成了共識，未來權限放開不放開是另一回事，當下咱們就要有這樣的流程來解決問題，從而達到咱們腦子中想要的那個方案終局，具體到打包這件事，就是有了分支拉包、推包、初審、二審、駁回、發佈和安裝同步等關鍵的節點切割，同時也把這件事收斂到了惟一的一臺公共服務器上去作，再也不有任何致使環境變化的人爲因素切入，全部人都在這個中心化的系統上協做，這個問題就獲得了極大的解決。

路徑 - 從流程到團隊基本面

雖然咱們作了一個打包、推包和發包的系統，問題都獲得瞭解決，但這只是線狀的把問題解決了，還有更多其餘的問題要考慮進來，好比開發階段的組件化、代碼規範和倉庫規範，好比運維階段的異常收集、分析、指派和產品使用數據的看板，而這裏看上去是問題，偏偏也是基建能夠發力的機會。

摸底：點線面到體系化診斷

剛纔咱們從打包問題一路引伸到了團隊這個層面，是想給你們引出這句話：從點狀的問題，摸到線狀的流程，再來到團隊的基本問題面，最終給出你的更立體的診斷結果，到了這一步，咱們就能發現團隊中隱藏的諸多問題，這些諸多問題就意味着諸多機會，這些機會或許就能夠用基建的手段來解決，因此咱們回到剛纔提出的問題：如何在團隊中找到基建的機會呢？這就是我推薦使用的方法，當你表述問題的時候，其實你也能表述出來更有高度的決策因子，而有時候打動別人的都是這些相關因素，是由於讓別人從這樣的思考方式上就對你創建了信任感，至少是相信。

這張圖是當時團隊診斷出來的基本面問題，其中在團隊規範和工具基建這兩個方向上是最制約團隊的根本病竈，那就從這兩個地方下手，其餘地方也在選擇時機用不一樣力度來下手。

基於點線面體來定奪作事節奏

下手的方式就是有節奏的解決問題，這個節奏就是基於這個點線面體的方法而頂多出來的，好比職業宣導是長期的一直在作的，架構調整和打包則是花大把時間重點作的，同時還給業務方作了一些提效工具給他們當點心，得到他們的好感和認同感，這張圖也是 3 年前的截圖，是當時的真實寫照，若是換到今天，我依然會用這種方式來作，只不過內容上可能會再微調罷了，若是把如何找機會作基建翻譯一下，其實就是如何在團隊中找痛點，找到痛點後，一路拔高最後識別哪些領域值得投入。

3、選人 - 如何提高團隊基建氛圍

剛纔把團隊問題的識別回顧後，相信你們腦海中已經記住了基建是邁面向的問題的，而問題是有不一樣的思考視角的，這個方法套到個人團隊中，能成立麼，咱們首先要回答這樣一個問題，我團隊中有這樣的人或者這樣的氣氛麼，若是這個想法對業務沒幫助對成長沒幫助，那跟不作又有什麼區別呢，因此咱們得先聊下你的團隊中，若是沒有適合作基建的氛圍，該怎麼作呢？

提高基建氛圍的方法

並非每個工程師都充滿基建熱情的，也有同窗長期作業務並擅長作業務，反而會造就對基建缺乏熱情，這種時候如何改善團隊中的基建氛圍呢，說是技術氛圍也是合適的，我總結下來，最簡單有效的就這三個：

第一種，是以周爲維度的代碼 Review，相對高頻，有三個原則、最長最多和最小，最長的 Review 間隔不能超過 1 周，不要長時間中止這件事，最多則是鼓勵儘量多的人蔘與，讓你們在代碼這個層面，從規範、設計和實現側有更多的輸入，儘量多的達成共識，至於最小，則是 Review 的對象顆粒度保持最小原則，能夠是一個一個函數接口入參的設計，能夠是一個列表優化的小算法，能夠是一個已發生的代碼 Bug，細化到點，儘量的聚焦。

第二種，是以月爲維度的技術分享，相對中頻，每月都要發生一次技術分享的行爲，內容沒必要侷限，但必定要有關於基建部分的共創和分享，這裏除了達成你們的充分共識，也是極好的技術佈道的機會和技術學習交流的機會，也是體現基建價值的機會，有沒有價值，也要讓真正的用戶也就是你的隊友來評判，避免成爲本身 YY 的做品。

第三種，是以季度爲維度的職責調整，相對低頻，每一個季度內要對作業務的同窗，作基建的同窗，不管是人員安排，仍是手上業務/技術基建的比例關係上，都作一些微調，讓技術成長慢的同窗能夠多參與一些基建工做，讓基建方面作好久的同窗來一線再體驗體驗業務，帶回去業務上新的思考，甚至能夠成立虛擬的基建小組，來設定負責人和參與人，以項目的形式來推進，而如何把最值得重度培養的同窗放到關鍵位置上，必定要有選拔標準，這個選拔標準就是能力和意願，再具體點，就是技術潛力、興趣度和作事的執行力。

選拔基建的合適人選

前文提到的代碼 RV、技術分享和職責調整，背後都是一個個同窗的參與，而有難度有價值部分的基建工做交給誰來作，這是一個很值得思考的問題，並非全部同窗都適合來作基建的，適得其反的方式也可能大大打擊同窗自信心，甚至也根本作不出一個被團隊承認的基建工具的，到底誰是最符合的，在咱們團隊，選拔的門檻有這三個，缺一不可：

第一個，技術嗅覺靈敏，對行業技術有感知，對技術對業務的價值有感知，而且在特定領域有必定的造詣
第二個，有較強的問題解決能力和創新能力，最關鍵的是執行力是爆棚的，是團隊中最拼最能拿結果的人
第三個，責任心和胸懷，能站在團隊視角思考問題，對其餘工程師有同理心，除了自我提高還能他人提高

基於這樣的前提，咱們跑了一段時間後，也就專門成立了基建小組，對基建小組作了以下這些職責的定義，能夠給你們參考一下：

首先，基建小組就是團隊的救火隊長，別人搞不定的問題，到了基建小組這裏，都要能補位和攻堅
其次，基建小組就是團隊的排雷先鋒，不管多超前的技術棧，他們能夠最快的消化掉核心的理念，並在小領域嘗試後，把經驗和能力輸出給團隊，形式不限，多是閒聊溝通，多是技術分享，多是一份文檔或者一段代碼
再次，基建小組就是團隊的兵工科長，要爲團隊的整個基礎設施的大頭負責，每一季度每年，都能不斷的升級裝備，並武裝到團隊
最後，基建小組也是團隊的佈道使徒，這一點看似簡單實則很難，目前小菜咱們作的也不是特別好，不少同窗比較謙虛和靦腆，不太好意思上臺來說，因此你們看到社區裏面，反而是我出來的次數多，這種狀態是不太健康的

有了這樣的選拔標準和職責劃分，作業務的同窗也能理解作基建的同窗他的價值，反過來亦然，再加上高頻的代碼 Review 和穩定的技術分享，以及團隊主管對人員的動態調整，整個團隊的基建氛圍就能逐步逐步起來了。

4、推進 - 基建到底如何立項開發

前面咱們把基建的價值弄清楚了，團隊痛點和基建機會點尋找的方法也瞭解，以及整個團隊的基建氛圍改善方式咱們也瞭解了，那就剩下最後一個問題了，若是具體到某個基建項目上，如何促成這件事在團隊中正式立項開發呢，有什麼簡單的規律，能夠幫助我說服老闆，說服產品業務，包括我身邊的同窗，來認同個人想法最終劃出來專門的人力，哪怕是加班加點，至少是有一個機會來實踐開發呢？那我把前年和去年我本身嘗試過的方法論，分享給你們。

有效的判斷是受權的前提

其實當你跟老闆說，咱們的腳手架很舊了須要升級，咱們的 APP 版本很老了須要重構，雖然你提供瞭解決方案，但這些聽到老闆的耳朵裏，都是想法，而不是可執行的方案，由於處在不一樣的團隊層級，所看到問題的象限和影響點是有很大不一樣的，若是要啓動好比一個 APP 的重構優化，那這裏有一些準備工做要作的：

首先，團隊這幾年下來的技術現狀你要摸底清楚，整個團隊有多少厲害的人，總體你們負責了哪些項目，這些項目中有哪些是技術債沒還的，若是對某方向某領域招人，難度高不高，會不會要作某件個基建，發現連續半年都招不到合適的人
其次，是要摸底這個行業中同類型公司團隊和技術棧，別人的實踐經驗，走過哪些彎路，有沒有能夠花錢買過來或者半自研拎過來的方案先用起來，有沒有這方面的成功案例能夠吸收經驗，避免本身從 0 摸索造輪子
再次，是根據我前面分享的問題識別方法，列出來完整的問題清單概括總結，看到底對團隊當下和將來一段時間，最痛的痛點是什麼，制約了咱們哪些方面，對業務是否有影響
最後，要對團隊的組織架構，分工方式，考覈制度都有一個理解，公司眼下是生死存亡之刻，仍是全面規模化的時刻，是已盈利仍是在當心的燒錢，有沒有可能讓咱們具有基建的業務土壤、窗口期包括物質條件

基於這 4 個摸底，咱們再來作這個基建價值和作事節奏，所謂判斷與規劃，判斷在當下的現狀中，當前的場景中，重構這個 APP 的性價比高不高，最終誰是最大受益者，受益多大，能不能經過數字反應出來，或者不重構帶來的問題有哪些，影響有多大，爲何會影響，有沒有數字和案例能夠反應出來，若是認爲這件事費作不可了，那麼就要有一個規劃，作這件事何時啓動，如何啓動，須要誰配合作，分幾期來作，每一期可量化的結果是什麼，所謂作事章法。

只有這些判斷你這裏都想透了，當你在跟你老闆說的時候，纔不會僅僅是一個想法，這些都是基本的儲備工做，能夠寫到 PPT 上，能夠存到腦子裏。

到底有哪些參考的立項指標

就算是心中有輪廓了，但仍是沒有信心說服老闆對不對，仍是得有一些更具體的看獲得的東西出來，跟你們分享 7 個我認爲有效的立項指標，這幾個你不要遺漏，通通作一遍，我相信老闆是很難否定掉你的方案了，除非是有其餘關鍵因素，特別是不可抗力因素的影響，這幾個立項指標你認真作的話，其實不難作的，作這個基建要有這七個，分別是數字、分析、優先級、里程碑、對比、大盤和到人頭的職責，也是也就是你們所熟悉的 Smart 原則的擴展版。

數字 - 基建規劃的靈魂

首先咱們要有數字，不管是你拿一個業務的結果，或者線上異常量的結果，仍是調研 5 個前端後的調查分析結果，裏面必定要有數字，這是我在 1 年前作的一次反應用戶轉化率變低緣由的分析，想要啓動一個用戶登陸過程的基建工做，來先後端配合下降用戶訪問小程序的時長，並最大程度讓用戶完成註冊動做，能夠看到我把每一週數據背後，產品上技術上有什麼發佈也都標註上來了，有了這個數字指標，全部人都能意識到這裏出問題了。

分析 - 基建規劃的內核

規劃成立不成立，要看背後的邏輯是否是成立的，這是我針對剛纔的問題，所提出的解決方案，裏面有技術的，有交互的也有基建的，好比首頁數據靜態化的服務，在這個裏面，要把問題再拆分紅點，每個點都要有它徹底成立的推導邏輯和解決後的目標，經過這個，全部人都能理解爲何要作這些些事情，這些事情背後的意義是什麼。

優先級 - 基建規劃的緊迫性

一般一個團隊的問題，都是兩位數以上的，要從這裏面識別出最有價值的痛點，每每是管理者的決策視角，而做爲團隊成員，要說服老闆承認你提出的一個新的建議，你就要設身處地的來跟老闆溝通，商定出一個衡量優先級的決策標準，有些事要作，但每每不是當下來作，根據這個決策標準來決定每個基建的緊迫程度，至於特殊的案例就特殊處理，若是每個案例都是特殊的，那這個團隊的研發模式必定是出了重大的危機。

我這裏把衡量基建緊迫程度分紅兩種權重：

最高優先級的是跟業務相關，不管是傷害、制約仍是影響業務，這些事情背後的基建工做都是優先級較高的，好比 APP 中框架依賴的包版本不一致會致使 APP 白屏閃退，那麼這種就是直接傷害到業務，它的背後必定要儘快啓動基建解決
較高優先級則是關乎開發效率、體驗、工程師的成長和維護成本等，越日後權重越低，同時命中的影響點越多，那麼這個基建的緊迫性也越高

不少時候，就是由於這樣的決策依據不一樣，致使同一件事，在你的眼中刻不容緩，在老闆的眼中是有價值的但它是能見度更低更小一些的刻不容緩，最終沒有讓你動手去作。

里程碑 - 基建規劃的皮囊

當你要啓動一個基建的時候，寥寥幾句是很難讓別人感知到你究竟是要作個什麼東西出來，到底要作多久，到底要用到多少開發資源，到底解決的最大痛點是什麼，那麼這裏面有個很重要的指標，就是里程碑，當有了里程碑，這個基建就有了階段，有了階段就有了能看見的成果距離：當下有多遠，咱們等不等得起？這也是咱們平常工做中最熟悉的部分了，由於基建也是項目，你們要用項目的視角來看。

對比 - 基建規劃合理性的校驗

人自然對於對比有着更強的感知力，不管當前是規劃前、規劃中仍是規劃後，針對這個基建方案，均可以對比組，能夠是業界的方案，能夠是其餘部門前端的方案，能夠是本身團隊從前的方案，經過對比來彰顯當前這個基建規劃的合理性和更量化的指標，就算這個指標不是足夠嚴謹，至少它帶來的價值是可感知的，這張圖是我在 2018 年述職時給老闆看的對比 2017 年，在基建鏈路上建設所拿到的結果，也正是這張圖，讓我進入這家公司的第一年就得到了晉升的門票。

除了對比可讓價值凸顯外，更重要的是經過對比，你有一個很好的證據在手，這是你下一次啓動新的基建的新起點，這個成功過的經驗能夠進一步削減你將來作基建的阻力。

人頭 - 基建規劃的保障

這張圖我把人的名字拿掉了，能夠把它看作是一個挑戰排行榜，全部參與基建的同窗，都身挑不一樣的挑戰，不一樣的挑戰背後有不一樣的價值和難度，有了這樣的價值和挑戰對應關係，每一個人都有了更具體的目標，包括跟你配合作這件事的人，必定要落實到人頭。

大盤 - 基建規劃的格局

這是你們從一開始工做就能夠訓練的能力，所謂更有高度的技術視野，這是我去年作過的一張圖，用來描述在 80 人的技術團隊中，20 個前端本身的業務是什麼，20 號人除了對業務負責，還對什麼負責，經過整理這樣的基建大盤，全部同窗都放到了一盤棋中，每個領域內的每個建設都有它的進度，每一個進度背後都有特定的同窗在負責，這時候整個團隊的基建就是有活力，若是你能夠造成這樣的大盤意識，不須要這麼詳細，你去說服老闆、合做方和同事的阻力都將會大幅的下降了。

總結 - 基建要從長考量

到這裏個人分享就告一段落了，不知道剛纔所分享的案例、方法、視角對你們幫助有多大，是否是可讓你們在基建三難，也就是判斷決策、共識受權、實現推廣這裏感受到其實並無那麼難了，只是缺乏這樣可參考的經驗而已，最後再跟一個小小的總結和建議：基建每每是長週期的事情，是無止境的，任什麼時候候要動做作以前，都要充分考慮成本和受益，要有很強的成本意識，同時要把基建的終極目標落實在兩件事情上，一個是對業務的幫助，到底能解決多少業務痛點，能帶來多少協同上的效率提高，另外一個就是對團隊有提高，能跟團隊同窗打成多大程度的共識，能促成團隊多少比例同窗參與交流分享，業務和團隊就是作基建的定海神針，全部人都會從中受益。

好的，個人分享就結束了，也但願你們能夠從個人分享中受益。

你們有問題能夠在微信羣中提問，我會選擇 2 個問題進行解答，也能夠加個人微信給我留言。

近兩年 Scott 觀察到前端行業已經徹底進入競爭的深水區，各大小公司的前端 TL 剛剛上任，初帶團隊，針對前端工程師這個羣體，應該怎麼管人理事，搭臺拿結果，幫帶有成長，就成立了這個前端技術主管學習交流羣，在人的選用育留上互相學習成長，入羣的門檻是你有實線或者虛線在帶團隊，請加 Scott 微信: codingdreamer 邀請入羣，同時將來的前端早早聊大會行程動態、資料下載請掃碼下方的公衆號跟進：

看完如有啓發，就請點贊評論轉發三連吧