阿里四年技術 TL 的得失總結：如何作好技術 Team Leader

做者 | 許曉斌  《Maven 實戰》做者
來源|阿里巴巴雲原生公衆號

子曰：吾日三省吾身，反思是人類進化出來的一項異常寶貴的能力。我在阿里帶團隊也有四年多的時間，有必要總結一下此間得失；另外，前幾天和一個剛開始帶團隊的同窗聊天，他以爲角色轉變對於他有不小的挑戰，所以我想作一點不算成熟的總結並分享出來。固然，此文第一不表明我本人必然是一個多麼成熟的管理者；第二不表明個人總結放之四海而皆準（事實上不少人的管理方式和我推崇的方法是反的，可是若是從晉升角度評價，這些人更成功）；第三我並沒有雄心壯志解答全部問題。總結僅僅是指望經過反思，幫助本身成爲更好的管理者，而分享是但願可以多多少少幫助到其餘的管理者。

本文會重點講述我我的對招聘、目標管理、團隊溝通和工程文化的理解。挑選這幾個主題講述，主要是由於在帶團隊的這一段時間內，我認爲這幾個要素是團隊長期發揮戰鬥力和創新能力的核心。獲得這個認識對我來講並不容易，市面上有紛繁複雜的書籍（機場書店尤爲多）嘗試告訴你什麼叫領導力，公司也有相關的培訓介紹，周圍也有不少 TL 用每日的言行告訴你他們是怎麼作的。可是我認爲這些來自周圍的知識，不少是無效的，有更可能是錯誤的。例若有 TL 天天在辦公室坐到半夜下班，給團隊巨大的加班壓力，表面看起來是奮鬥，實際上會讓你們趨向於更多關注工做時長，從而下降對了對工做價值的思考；又有一些例子是，當團隊同窗犯錯後，把故障和績效強關聯，在我看來這不只無助於你們深刻思考系統健壯性，更是鼓勵推責，扼殺創新；更常見的例子多是 TL 積極向上彙報，承諾超出團隊負責的交付能力，致使團隊徹底無視工程師文化，長此以往優秀的人才逐漸流失，團隊總體研發能力實則愈來愈弱。

不少事情是知易行難的，技術 TL 實踐更是這樣，以後不斷學習，執行，反思，才能慢慢作得更好。若是我團隊的同窗在離開這個團隊五年或者十年後，回想起這段時間，會感慨：「咱們當時的團隊多好啊，你們一塊兒作了不少有意思的事情。」 那我這個技術 TL 的工做，就算作的出色了。

招聘

招聘的第一原則是寧缺毋濫。這麼說出來你們都會認同，可是實際執行每每會由於短時間壓力而變形，尤爲是招聘愈來愈難，好不容易面到一個看起來差很少的同窗，不免會心裏有點小傾斜，算了，先招進來了。這實際上是很是危險的，由於一旦招聘了錯誤的人，對於 TL 須要耗費的管理時間會成倍增長，這些時間原本能夠用來作更重要的時間。更危險的是，錯誤的人可能會對團隊總體產生負面的影響，例如須要其餘人不斷地補位，或者和人不斷爭吵，消耗你們的精力。

所以招聘必定是要嚴格要求的，如何面試我就不詳細講了，一般我會關注如下一些方面，基本上是缺一不可：

• coding 能力

• 對技術的熱情

• 能簡明扼要地溝通

• 積極樂觀

• 對團隊目標的認同

招聘是個長期的事情，若是僅僅是在有 HC 的窗口去找人，一般是很是困難的。遇到合適的人，我會長期和他保持溝通，瞭解對方工做的狀態，這其實也是一個不斷創建信任的關係。當機會合適的時候，對方確定會優先考慮你。

當候選人選擇機會的時候，團隊的 TL 是個怎樣的人確定是他重點考慮的因素之一。所以 TL 必定要作技術發聲，不管是開源項目的參與，撰寫技術文章，仍是在技術大會作演講，都是充分體現 TL 我的技術能力，技術思考，以及我的特質的重要機會。

目標

團隊之因此爲團隊，是由於這些人有共同的目標，若是沒有共同目標，這些人就是散兵遊勇，不可能相互協同，沒法成就巨大價值。而團隊的目標，主要仍是由 TL 去負責定義和明確的。

近期比較流行談 OKR，我認爲這就是一種協同團隊聚焦目標的方法。定方向 O（Objective），定數字目標 KR（Key Result），就是指望團隊可以凝聚在一塊兒，朝共同的方向努力，相互理解和支持。量化的指標（KR）用來指導方向，暴露問題。我比較反對用 KR 或者其餘量化指標來簡單粗暴地考覈工程師，數字指標若是用來考覈，很容易致使你們捨本逐末。例若有人 KR 完成了 200%，卻挖了一堆坑；而有人 KR 完成 50%，但的確解決了棘手問題，代碼紮紮實實。我必然會把好的績效給後者，差的績效給前者。

定義團隊目標其實是個很是困難的事情，由於這個目標的定義要求你回答：

• 是否和你的用戶/客戶作了充分溝通，是否理解他們真正須要什麼，你能給他們解決什麼問題，他們的工做由於有了你團隊會發生怎樣的改變。

• 和上下游協做方可以作好協同，要兌現你給客戶承諾的價值，你會依賴於誰作什麼事情？須要誰和你一塊兒參與？這些依賴和協做方，是否定同你的目標？

• 你定義的目標和價值，和你本身的的 TL 的目標，或者本身部門的目標，是不是一致的？

• 在技術團隊，你的目標定義中有沒有考慮技術競爭力？持續建設技術競爭力不只能幫助團隊長期發展得更好，也能幫助吸引更多優秀的人才。

固然，若是這個目標有那麼點理想主義，那就更好了。工程師骨子都有那麼點容易被理想主義吸引。有了清晰的團隊目標後，就是要和團隊不斷的溝通了，讓每一個人都清晰地理解目標，不要怕重複，不要怕囉嗦。

下一步是把團隊目標分解爲每一個人的目標，這件事本質上是產品架構或者技術架構。爲何這麼說呢？在作軟件設計的時候，咱們都會說高內聚，低耦合；會說面向契約設計。人與人協做的時候，咱們也但願每一個人的目標足夠清晰（對比軟件交付功能的定義，或者非功能性指標的度量），以及人和人之間的協做邊界清晰（對比軟件系統之間的契約）。所以咱們要不斷去思考團隊負責產品的架構，和團隊同窗不斷討論細化，直至架構及目標足夠清晰。固然還有一些橫向的目標，或者項目管理的工做目標，須要有同窗去承擔，這沒什麼問題，但我很是不建議在研發團隊中，讓一個同窗有超過一半的時間在作橫向，由於技術沒有深度是談不上廣度的。

溝通

若是團隊同窗找你，那就要儘量當即響應。當即響應的意思是，若是你當下有時間，就馬上和他溝通；若是你白天時間排滿了，那就晚上和他溝通；若是你實在晚上的時間也被佔了，那就馬上安排明天一個時間，發出會議邀約。同窗若是沒有他認爲重要的事情，通常是不會主動找主管溝通的，當即響應是和同窗創建信任的重要方式。若是同窗找你一次兩次都沒獲得響應，或者響應比較慢（給人不重視的感受），那慢慢的不少事情就不會找你了。最差的狀況，同窗下次找你的時候多是提轉崗了。

要儘可能和同窗作 1-on-1，國外專職作管理崗位的，把 1-on-1 做爲一個很是正經的平常工做在作，頻率也很高，例如兩週一次。在阿里巴巴，技術 TL 一般沒有這麼多的時間，由於身上承擔的職責除了管理外，還要帶技術，帶項目等等。但仍是應該作好平常的 1-on-1 溝通，而不只僅是績效季。比較理想的頻率是一個月一次。在 1-on-1 的時候，一方面要給到很是具體的反饋，例如：

• 你作的 x 方案，在設計上很是好，考慮到了和隔壁團隊的協做。

• 你近期的代碼，在 UT 覆蓋上作的不夠。

• 我看到你推動的 y 項目，進展不及理想，是遇到了什麼問題嗎？須要我提供什麼幫助？

除了反饋 1-on-1 更重要的是傾聽，同窗在表述本身工做的時候，狀態好很差？在什麼地方遇到了問題，做爲 TL 能提供什麼幫助？_其實不少時候，即便你暫時幫不了什麼，可是用認真的態度去聽一下同窗的心情，無所這個心情是充滿熱情，仍是沮喪，仍是迷茫，對於同窗來講都是很是重要的。_我在作 1-on-1 的時候，都會作個簡單的記錄，留着下次 1-on-1 的時候 review，作好追蹤。

工程文化

要建設一支有戰鬥力的團隊，優秀的工程文化是必不可少的。什麼是優秀的工程文化？那就是對本身寫代碼，寫的測試，寫的設計，作的產品，全部這些工程師的產出物，對其質量和細節有足夠的尊重。爲何說，優秀的工程師文化必不可少，我經過如下幾點解釋下：

• 從團隊產品的長期發展來看，只有保證優秀的質量，才能保證產品能夠長期，高效率的，持續的迭代。若是設計凌亂，代碼質量差，無測試覆蓋，那麼漸漸全部人的精力都會被消耗在各類」安全生產「問題上。漸漸的，一個需求的上線實現，從數小時演變成了數天，甚至數週。

• 只有擁有優秀工程文化的團隊，才能吸引優秀的工程師。優秀的工程師，真心把編程看成一門手藝，以本身的手藝爲傲。若是團隊 TL 不認爲這是一門應當引覺得傲的手藝，你們漸漸的你們都把事情當作和搬磚無異的性質，區別只是工資高低。這樣的氛圍下，團隊的人才構成必然是二流甚至是三流的。

建設工程文化，就是要鼓勵你們作 Code Review，寫 UT，作好 CI，作知識分享。這些事情聽起來很容易，難的是，如何在項目壓力很大的時候，依舊堅持住。另外，就是要認可 technical debt 的存在，產品上線一段時間後，必然會有不少「臨時方案」存在，做爲 TL 要給團隊創造空間，鼓勵他們花時間去償還 technical debt。

工程文化是技術團隊的根基，可讓全部人有一個正確的參照，什麼是對的，什麼是應該學習的，什麼是須要遵照的。咱們能夠看到不少丟失了工程文化的團隊，演變成一個什麼樣的狀態，寫看起來都差很少的 ppt，每天拉會推進這個推進那個，遇到問題本身不去查根究底弄清楚原理，而是拉羣，組會，溝通…… 漸漸的這樣的團隊的技術人才會逐漸流失，剩下的人繼續用他們擅長的非技術技能生存。

TL 對本身說

除了對外，我還常常對本身說：

• 作真實的本身

• Don’t Panic！

• 耐心點

作真實的本身。每一個人都有本身的性格特質，雖然由於人生經歷，人的個性會發生變化，但在短期內一我的最本質的東西是不會變化的。或溫文儒雅，或狹義豪情，或積極勤奮…… 「真實不裝」是阿里價值觀中我最喜歡的一條。假裝一時是很容易作到了，常年累月把本身假裝成一種人設，一來本身會很是累，二來團隊同窗也不是傻子，遲早會看出這其中虛僞的一面。而一旦一個 TL 讓人感到虛僞，那就無從談起信任的創建了。固然，對自我分析，認識本身也並非一件簡單的事情，心理學分析的書浩如煙海，我喜歡夜深人靜的時候讀一些。

Don’t Panic！TL 會面臨各類各樣的壓力，目標變化，目標難以達成，績效考覈，人和人之間的衝突，團隊很團隊之間的衝突，這個時候你們都在看着你怎麼處理。在這麼多壓力下，人的天然反應就是焦慮，甚至惶恐不安。咱們知道，在運動的時候，演講的時候，過分的焦慮會致使動做變形，乃至連本身的正常水平都沒法發揮。而 TL 在這種狀態下，更容易作出錯誤的判斷，並且嚴重焦慮的情緒很容易傳導給整個團隊。越是這種時刻，越好穩住本身，在有限的條件下，努力作出最合理的判斷，咱們必需要認可本身再怎麼聰明勤奮，也只是普通人而已，並非漫威中的超級英雄。

耐心點。程序員多是最沒耐心的一批人，代碼寫下去，首先指望機器必然給反饋，其次指望機器馬上給出反饋，對了，仍是出錯了，一切都要清清楚楚，明明白白。可當程序員的角色轉變成管理者的時候，一切就發生了巨大的變化。你給團隊宣導的目標，可能有人記住了，有人沒記住；你給同窗指出的問題，可能他幾個月半年都改不了，或者他根本不想改；你想在團隊創建的工程文化，好像進展很是慢，和預期相差太遠。其實這一切都很正常，人腦接受和轉化信息，除非是性命攸關的信息，不然效率都是很低的，一我的自身積累幾十年的行爲模式，哪怕作出細微的變化，也須要很長的時間。所以，重要的信息，不要嫌麻煩，能夠說三遍甚至更多；而當你好心給同窗指出問題，也不要指望對方馬上接受並改變，不少時候他不作任何改變也是很正常的。但這也不是咱們不作正確事情的理由，若是十個同窗中有一兩個由於你的指導，在職業生涯上突破了本身的一些瓶頸，那已經做爲 TL 能實現的巨大成就了。

延伸閱讀

楊絳有一句話我很是喜歡，她在一封回覆青年學生的時候，寫了這麼一句話：

你的問題主要在於讀書很少而想得太多。

在我看來今天在工做中看到的不少人的，所謂創新，所謂 idea，都是屬於讀書很少而想的太多的瞎折騰。作技術領導者也同樣，體驗、思考是必要的，可是若是僅僅靠本身思考和體驗，每每會走不少彎路，甚至南轅北轍。所以我建議你們閱讀一些相關的書籍。如下是我讀過的一些，推薦給你們。

• 傑克韋爾奇的《贏》：阿里巴巴的 361 強制末位淘汰多是從這裏學來的

• 谷歌的《如何定義公司》：人才相當重要。

• 《驅動力》：除了使用金錢以外，如何激勵人。

• 《門後的祕密》：爲何 1-on-1 溝通如此重要，以及如何作好 1-on-1。

• 《非暴力溝通》：說話你們都會，可是好好說話不少人就不會，擅於傾聽的人更是少見。

做者簡介

許曉斌  《Maven 實戰》做者，在阿里負責微服務架構、Serverless、雲原生應用平臺等相關工做。