技術Leader：像李雲龍一樣打造學習型團隊
今天跟大家分享一下怎麼樣構建一個學習型的團隊。
首先對於計算機行業而言，不明而喻，我們要接受的東西真的太多了。我們接觸的資訊和變化也太多了。如果只是因循守舊，排斥新東西，那麼我們被時代淘汰只是個時間問題。
想當年我大三的時候認識了一個做VB的自有職業的朋友，那是VB開發語言還是很火爆的，我們在喝啤酒的時候，他就跟我說，小蔣，好好學，學好了VB一樣，你以後就可以吃香的喝辣的。
時過境遷，我想15年後的今天，應該幾乎沒有招聘VB的崗位了，別說吃香喝辣，連吃口飯都是問題。
與此同時，在網際網路公司裡面豐富經驗也基本上也往往是低價值的。因為很多時候經驗是被舊的產品模式，舊的業務以及舊的技術所積累和沉澱的。但當產品業務和技術發生了天差地別的時候，我們積累那些經驗可能完全是無法複用的。
相當年用HTML+CSS的網頁製作經驗，相信到現在也就是古董了。
比如還有在當前AI時代，原來的產品經驗和技術經驗可能都是被迭代替換掉的。在AI時代，我們可能就需要用全新的工作方式來面對新的挑戰，可能所有產品和技術正規化都會被重塑。
聊到這裡，大家應該明白，身處計算機行業，構建一個學習型團隊對於網際網路公司的團隊管理來說至關重要。
一方面只有整個團隊的知識是迭代是進步的，就能夠迎接更好的創新和業務機會。另外一方面，構建學習型團隊對每個同學的成長來說也是至關重要的，持續學習的團隊可以讓每個同學都有接觸新技術的機會，可以除了業務之外，能夠一個更好學習機會、交流機會，能夠迭代和重新整理自己的認知和對於技術的瞭解。
我在面試的時候，不管是校招同學還是社招同學，最後一個問題總會再諮詢一個，你平常是怎麼樣學習新技術的？
從我的經驗上面來看，但凡各方面都比較好的同學，往往會對新技術也是非常感興趣的。反之，如果對學習新技術不感興趣的同學往往對某一些比較新的技術點的時候，可能同學答的不是很好，或者深度完全不夠。這裡面體現的就是對於一個技術的興趣和追求。
那怎麼樣構建一個學習型團隊呢？我認為會有以下幾點。
首先，Leader是構建一個學習型團隊的核心和靈魂。如果一名Leader沒有把重點放在構建學習型的團隊上面，團隊的同學是沒有這個主觀能動性的。畢竟在網際網路公司最多的事情就是來支援業務上線，也就是我們常見的寫程式碼。就如在早期的時候，基本上在996或者007的這種模式裡面，根本沒有時間讓同學們自己來學習技術，唯有的一點時間就拿來寫程式碼了。
加班到晚上9點，10點再回家，已經疲憊的不可能再拿幾本書再去學習新的知識點。相比加過班的同學都深知這一點。
另外對於很多剛剛畢業的同學來說，可能在學習方面很快就會迷失方向。在一個人的思維裡面很容易進入一個資訊繭房，比如說我學JAVA的，那麼我只用JAVA來支援我的業務，在超出我業務範圍內的知識我都沒有機會去獲取，也想不到去獲取。或者我們做後端的同學往往沒有機會，沒有時間去涉及或者瞭解前端或者使用者端相關的知識。同理，做資料的同學往往沒有機會去看看後端的架構設計是怎麼搞的。而涉略跨方向跨語言甚至跨學科的知識，才能讓一位技術同學成長得更快。
我有個前同事兼校友，釘釘總監，微軟Azure Identity首席總監，前Office 365首席工程師虞雷就告訴我，程式設計師最好每半年就學習一門新的技術語言，對自己的程式設計正規化會有質的提高。
反之，時間投入無休止的迭代，會使得我們的技術視野和深度都變得越來越窄。
所以一名Leader要構建一個學習型的團隊，就要打造出這種學習成長型的文化，要給團隊營造出一個工程師文化的氛圍，Leader是團隊文化的核心靈魂。李雲龍是其打造的「獨立團嗷嗷叫的狼性文化」的核心靈魂。
首先，是技術分享。
比如我在團隊就定一個規則，兩週強制做一次技術分享，做分享的時間納入到自己的日常工作量上來。與一般的長分享不同，我要求這個技術分享是採用短分享的方式，主要是以某一個同學來起一個自己感興趣技術主題，收集關鍵的資料作為主講人，其他的同學做討論，然後每兩週更換一名同學作為主講人。
這樣既避免了讓某一個同學來主導這件事情，花費過多的精力，又能夠讓其他同學有一個深度參與感。
我之前見過原來的團隊組織這種技術分享，一個同學可能要花上一週，兩週甚至是一個月的時間來準備PPT，同時在講解的時候也會挖的特別的深，把很多不常用的長尾的概念也都分析一番，其他同學都不大可能提出具體的問題。這種分享就淪為了一種形式主義。
所以我要求同學們選的主題不要那種特別偏門的，而要求是那種比較新的，比較熱門的，比較有實際應用場景的技術主題。
比如我們近期就分享討論了三個主題，第一個主題是關於Docker的分享，因為我們系統用的就是Docker技術，所以我們在分享這個概念的時候，每個同學都有參與感，在分享期間也頻繁提問，也能夠加深我們日程釋出用到的Docker技術的理解。另外一個技術分享就是AI圖生圖的技術。這個需求背景是基於我們一個工作臺的應用圖示變化專案。我們利用AI圖生圖的方式來對原有的圖示做樣式和顏色上的重新升級。我們從這個技術裡面學習到了很多關於圖片處理的一些技術，比如Midjourny。我們還分享了一個關於地球點和點距離和排序的方式，因為我們剛剛做了一個產品功能上線，這個產品就是基於地理位置的一個話題功能，包含「附近」和「同城」，我們設計了一套演演算法來實現獲取當前使用者附近的動態內容。
我們這些分享的技術話題都特別的有趣，同時跟我們的工作也息息相關相關，同時也是一個技術前沿性熱點內容。
和我之前參與過的技術分享相比非常的枯燥，而我們的短技術分享，每個同學討論，提問，答疑都非常的熱烈。
而這一切就有賴於Leader要構建一個良好的學習型環境，要把技術分享工程師文化寫入到我們的團隊KPI裡面去。
其次，是技術方案Review。
一名技術同學的成長考核，「寫一個很好的技術方案」，就是最好的一個標準。技術方案不僅僅是一名程式設計師解決問題編碼能力的體現，更是一名程式設計師思維方式的體現，也是程式設計師「技術全域性觀」的一個投影。
計算機大牛左耳朵耗子就說過，一名程式設計師80%的精力應該放在寫技術方案上，20%才是動手寫程式碼。所以在這裡面我們可以看到寫好一個技術方案的重要性。到了高手階段，往往只要你想的清楚，你就能夠寫的清楚。而想不清楚，也不可能寫得出來。因此計算機高手程式設計師一定不是像駭客那樣，坐在螢幕前一通亂敲，反而大部分時間是類似「發呆」一樣的組織自己方案。一旦方案清晰了，直接「下筆如有神」。
高手不會像一名初級程式設計師一樣，不管碰到什麼問題，上手寫程式碼，然後寫著寫著發現漏洞百出又重推倒重來。這個就等於一名高手一樣，高手過招，是很少直接出劍的，也很少一見面就喊打喊殺，而是面對對手，先做充分縝密的計劃、摸索、試探，80%時間在做競對調研，但是一旦明白了對手底細，就會快速出招，一出就必須要見血，這是同樣的概念。
所以我要求團隊開發同學在碰到超過三個人日的業務需求上就要準備一份技術方案，技術方案不求宏篇巨論，但求精簡清晰。
準備這個技術方案也是同學在構建一個思維的過程，怎麼樣立體的解決需求。這裡面不僅要思考當前的問題，還要思考投入產出比，還要思考核心的解決的架構是什麼，裡面關鍵的難點是什麼，以及能力複用性。比如用到了什麼樣的一個技術方案選型，比如在穩定性上面有什麼考量，在降級上有怎麼考量，能否給其他業務複用，能否具備擴充套件性。
同時在組織這個技術方案Review的時候，我一般希望儘量所有同學都能夠參與，第一個是能夠讓其他同學可以瞭解這個技術方案，第二個是給這個技術方案一些自己的思考和建議。這個過程一方面是演講者自己能夠清晰的表達出自己的方案和思考過程，另外一方面也是能夠讓其他同學來學習這種設計思路或者提出批評建議。
當然這裡面還有一個核心的關注點，就是從Leader的角度來關注整個方案的架構是不是合理的，是不是可複用的。會不會踩到一些大坑，會不會使得整個業務出現一個系統性的問題。
所以通過技術Review這樣的方式能夠鍛鍊所有團隊同學對於系統方案檔案產出的一個能力，檔案表述的能力以及對於其他同學技術方案的一個理解能力。
最後，是程式碼review。
歸根結底工程師的產出就是程式碼。雖然我們更看重一名工程師在方案上面的架構設計能力，但最終落到實處的還是程式碼的能力。因此通過程式碼Review的方式來學習和提升自己的技能是最具象的。
這也是為什麼我在面試P5層級，P6層級和P7同級的同學一定要有程式碼筆試。一名工程師的動手能力強不強，通過程式碼筆試完全就能夠檢測出來。我想這個可能就是諸如谷歌，微軟這樣的大公司對所有技術職位都要求做演演算法筆試的一個原因。而且據我所知，像位元組跳動這樣的公司針對所有層級的程式設計師都要求寫演演算法程式碼，這一點我還是非常認同的。
對於程式碼Review一般採用高層級對低層級進行Review，或者同層級的相互Review。一般來說流程就是在寫完程式之後，自測通過了就會把這個程式碼提交給相關的同學來進行程式碼Review，然後反覆更改確認最後提交發布。
更高階的工程師一般會從幾個角度來看看程式碼的質量。
比如會關注程式碼基礎規範，程式碼是不是可複用，之前有沒有人寫過這段程式碼，還會關注程式碼是否優雅，是否有合理的抽象，還會關注程式碼是否具備了開關和降級能力。對於一些核心主流程的程式碼還會確認是不是會影響線上穩定的流程。
程式碼Review對於所有工程師來說來說是一次檢查，特別是高階工程師往往在寫程式碼上面經驗非常豐富，通過程式碼review就能夠把自己的經驗傳達給低階的開發工程師。對於高階工程師來說，一方面可以學習到其他工程師是怎麼樣寫程式碼的，另外一方面也能夠通過程式碼Review的方式管把控個系統的穩定性。
作為一個技術團隊，從技術分享裡面去深挖技術，去討論技術和學習寫程式碼是最為重要的一個手段。
與此同時，我也特別積極的鼓勵同學們參與整個公司的技術分享，積极參與公司舉辦的各種活動，比如近期的AI大賽。除此之外，我有鼓勵團隊們在解決日常問題的時候要充分的討論和相互溝通，比如我們經常就針對於線上發生了抖動、超時的一些根本問題進行深入的分析和探討。我們團隊就有很多同學深入挖掘了諸如大物件導致的FullGC的問題。
我相信只要一個Leader是學習型成長型的Leader，那麼整個團隊就會是學習型，成長型的團隊。
終身學習，我覺得是每一位優秀工程師追求的素養。