如何做好技術 Team Leader？

作者 | 曉斌

來源 | 阿裡技術公衆号

曾子曰：吾日三省吾身，反思是人類進化出來的一項異常寶貴的能力。我在阿裡帶團隊也有四年多的時間，有必要總結一下此間得失；另外，前幾天和一個剛開始帶團隊的同學聊天，他覺得角色轉變對于他有不小的挑戰，是以我想做一點不算成熟的總結并分享出來。當然，此文第一不代表我必然是一個多麼成熟的管理者；第二不代表我的總結放之四海而皆準（事實上很多人的管理方式和我推崇的方法是反的，但是如果從某些角度評價，這些人更成功）；第三我并無雄心壯志解答所有問題。總結僅僅是期望通過反思，幫助自己成為更好的管理者，而分享是希望能夠多多少少幫助到其他的管理者。

本文會重點講述我對招聘、目标管理、團隊溝通和工程文化的了解。挑選這幾個主題講述，主要是因為在帶團隊的這一段時間内，我認為這幾個要素是團隊長期發揮戰鬥力和創新能力的核心。得到這個認識對我來說并不容易，市面上有紛繁複雜的書籍（機場書店尤其多）嘗試告訴你什麼叫上司力，公司也有相關的教育訓練介紹，周圍也有很多 TL 用每日的言行告訴你他們是怎麼做的。但是我認為這些來自周圍的知識，很多是無效的，有更多是錯誤的。例如有 TL 每天在辦公室坐到半夜下班，給團隊巨大的加班壓力，表面看起來是奮鬥，實際上會讓大家趨向于更多關注工作時長，進而降低對了對工作價值的思考；又有一些例子是，當團隊同學犯錯後，把故障和績效強關聯，在我看來這不僅無助于大家深入思考系統健壯性，更是鼓勵推責，扼殺創新；更常見的例子可能是 TL 積極向上彙報，承諾超出團隊負責的傳遞能力，導緻團隊完全無視工程師文化，久而久之優秀的人才逐漸流失，團隊整體研發能力實則越來越弱。

很多事情是知易行難的，技術 TL 實踐更是這樣，之後不斷學習，執行，反思，才能慢慢做得更好。如果我團隊的同學在離開這個團隊五年或者十年後，回想起這段時間，會感慨：“我們當時的團隊多好啊，大家一起做了很多有意思的事情。” 那我這個技術 TL 的工作，就算做的出色了。

一 招聘

招聘的第一原則是甯缺毋濫。這麼說出來大家都會認同，但是實際執行往往會因為短期壓力而變形，尤其是招聘越來越難，好不容易面到一個看起來差不多的同學，難免會内心有點小傾斜，算了，先招進來了。這其實是非常危險的，因為一旦招聘了錯誤的人，對于 TL 需要耗費的管理時間會成倍增加，這些時間本來可以用來做更重要的時間。更危險的是，錯誤的人可能會對團隊整體産生負面的影響，例如需要其他人不斷地補位，或者和人不斷争吵，消耗大家的精力。

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

1. coding 能力
2. 對技術的熱情
3. 能簡明扼要地溝通
4. 積極樂觀
5. 對團隊目标的認同

招聘是個長期的事情，如果僅僅是在有名額的視窗去找人，通常是非常困難的。遇到合适的人，我會長期和他保持溝通，了解對方工作的狀态，這其實也是一個不斷建立信任的關系。當機會合适的時候，對方肯定會優先考慮你。

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

二 目标

團隊之是以為團隊，是因為這些人有共同的目标，如果沒有共同目标，這些人就是散兵遊勇，不可能互相協同，無法成就巨大價值。而團隊的目标，主要還是由 TL 去負責定義和明确的。

近期比較流行談 OKR（Objectives and Key Results，目标與關鍵成果法），我認為這就是一種協同團隊聚焦目标的方法。定方向 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，做知識分享。這些事情聽起來很容易，難的是，如何在項目壓力很大的時候，依舊堅持住。另外，就是要承認技術債的存在，産品上線一段時間後，必然會有很多“臨時方案”存在，作為 TL 要給團隊創造空間，鼓勵他們花時間去償還技術債。

工程文化是技術團隊的根基，可以讓所有人有一個正确的參照，什麼是對的，什麼是應該學習的，什麼是需要遵守的。我們可以看到很多丢失了工程文化的團隊，演變成一個什麼樣的狀态，寫看起來都差不多的 PPT，天天拉會推動這個推動那個，遇到問題自己不去查根究底弄清楚原理，而是拉群，組會，溝通…… 漸漸的這樣的團隊的技術人才會逐漸流失，剩下的人繼續用他們擅長的非技術技能生存。

五 TL 對自己說

除了對外，我還經常對自己說：

• 做真實的自己
• Don’t Panic！
• 耐心點

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

Don’t Panic！TL 會面臨各種各樣的壓力，目标變化，目标難以達成，績效考核，人和人之間的沖突，團隊很團隊之間的沖突，這個時候大家都在看着你怎麼處理。在這麼多壓力下，人的自然反應就是焦慮，甚至驚慌失措。我們知道，在運動的時候，演講的時候，過度的焦慮會導緻動作變形，乃至連自己的正常水準都無法發揮。而 TL 在這種狀态下，更容易做出錯誤的判斷，而且嚴重焦慮的情緒很容易傳導給整個團隊。越是這種時刻，越好穩住自己，在有限的條件下，努力做出最合理的判斷，我們必須要承認自己再怎麼聰明勤奮，也隻是普通人而已，并不是漫威中的超級英雄。

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

六 延伸閱讀

楊绛有一句話我非常喜歡，她在一封回複青年學生的時候，寫了這麼一句話：

你的問題主要在于讀書不多而想得太多。

在我看來今天在工作中看到的很多人的，所謂創新，所謂 idea，都是屬于讀書不多而想的太多的瞎折騰。做技術上司者也一樣，體驗、思考是必要的，但是如果僅僅靠自己思考和體驗，往往會走很多彎路，甚至南轅北轍。是以我建議大家閱讀一些相關的書籍。以下是我讀過的一些，推薦給大家：

《赢》

《如何定義公司》

人才至關重要。

《驅動力》

除了使用金錢之外，如何激勵人。

《門後的秘密》

為什麼 1-on-1 溝通如此重要，以及如何做好 1-on-1。

《非暴力溝通》

說話大家都會，但是好好說話很多人就不會，擅于傾聽的人更是少見。