這不是一篇討喜的文章，至少不會是你常常看到的例如《成為優秀 Tech Lead 的六個建議》令人歡欣鼓舞的那一類。今天我們聊聊 Tech Lead 所面臨的不那麼輕鬆的現實問題
程式設計師一定會有類似的體驗：學習技術的過程中首先會經歷蜜月期，例如總有新的知識點有待你挖掘，你會覺得它無所不能；也逃不過挫折期，即你會發現技術的邊界在哪裡，有些業務場景終究是它不擅長的，此時你需要尋找新的解決方案。這未必是壞事，技術邊界是一個客觀事實，你能夠找到它側面印證了你對舊技術趨於精通，對新技術的征途即將開始。
這幾年做 Tech Leader 同樣經歷了這幾個階段：你會有一個快速的上升期，就像我在上一篇文章《去年我是怎麼解決團隊問題》裡說的那樣，不停的遇到問題然後樂此不疲的解決問題——整個過程你會收穫頗多，同樣是因為對個人來說是這是全新的領域；可後一階段不盡相同，無力感帶來的更多是思考而非答案
我想起了書《看板方法：科技企業漸進變革成功之道》（Kanban: Successful Evolutionary Change for Your Technology Business）裡的一個真實故事。
2004年10月，微軟公司的程式經理扎格斯•杜米特（Dragos Dumitriu）剛剛接管一個部門的工作，團隊的主要成員來自印度一家供應商。在微軟公司內部，該團隊在客戶服務上的口碑是最差的，例如他們的變更請求前置時間長達5個月。在經過扎格斯和本書作者對團隊工作流程進行一系列優化之後， 團隊已經將前置時間減少到平均14天的水平，25天內準時交付的達成率高達98%，處理完成的請求項提升3倍多。
類似的故事在各類書籍、培訓中比比皆是，它在暗示如果你能掌握它們傳授給你的技能，你就能擁有同樣化險為夷的能力——這是對於新人來說最常見的陷阱。
繼續回到故事本身，扎格斯能夠讓團隊效率有如此大的提升是非常了不起的事情（即使不是在短時間內）。注意我所說的了不起並非從結果出發，而是指在一個大公司內從設計到執行一系列流程變革。
如果你未曾成為過 Tech Lead，或者未曾有過大廠的工作經歷，可能不太能想象的出上述工作的難度。讓我簡單列舉出其中的部分，有些是書中直接給出和推測出的，有的來源於我的經驗：
也就是說當我們想推動改善工作時，難點不在於改善方案本身，而在於如何在團隊、文化、利益的約束中將方案落地。在越是分工細緻的大公司裡，上述任務的難度就越高。
你的腦海中肯定早早的有一棵 Tech Lead 所需的技能樹，上面掛滿了諸如架構、質量、干係人等有待點亮的技能點，但我猜解決上述問題所需的技能多半不在其中。的確這些問題離「交付」、「迭代」甚遠，在其他行業同樣存在。甚至如果你問我是否贊成把它們放入 Tech Lead 培訓中，我的答案也會是否定的，因為一方面很難將這類內容標準化，同一類問題在面對不同的人和團隊時解法會不一樣；另一方面也無法把它們歸納為純粹的單項技能予以培養，溝通、情商、經驗都包含其中。
但這些瑣碎的、無聊的、和程式碼無關的任務就是 Tech Lead 日常工作的一部分。你以為成為 Tech Lead 之後就可以大展拳腳，例如帶著團隊挖坑、造輪子、披荊斬棘；殊不知實際上每天等待你的是波瀾不驚的程式碼、無盡會議、還有隔三差五和隔壁團隊對線。話說回來，這類工作雖然「基層」卻並不可恥。不妨回想一下任意一條在你簡歷或者述職報告裡濃墨重彩的一筆，背後有多少工作仰仗的是非你不可的高精尖技術？大多數是沒有難度的苦力活對不對；如果繼續拆解，實際投入在編碼的精力也不會可觀。我們絕大多數人遇到的絕大多數問題，都可以在前人的分享中找到答案。這些答案，好比最後給病人服下的藥，而 Tech Lead 的職責是設法讓病人把藥服下
說白了 Tech Lead 不是甩手掌櫃的命，他需要根植一線。同時意味著你要小心那些對系統缺少敬畏之心的人，在他們眼裡萬物都可以用「不就是XXX」來總結。不用在乎他們真的有兩把刷子，還是在嘴上跑火車，幾個月後看他們幹成了什麼就好。
此時此刻無論你是開啟《哈佛商業評論》網站還是《Coaching for Leaders》播客節目，看到的是琳琅滿目的 Tech Lead 工具箱，小到會前如何會前準備 PPT，大到如何引領變革應有盡有，以至於它們很難不讓你感受到勝券在握。但你我都知道這是錯覺，畢竟專業技能是依靠練習而不是背書習得的。
知識點和現實脫節的原因在於它們並未被轉化可執行方案並且固化在你的腦袋中。例如在遇到團隊組建初期成員間爭鋒相對的情況時，也許你並不意外，因為在 Tech Lead 培訓中講師強調過，新團隊必定會經過一個震盪期；也許你也意識到應該開始採用某些解決衝突策略介入其中；也許所有的問題統統來自於團隊中某一個「壞蘋果」——但震盪期的應對措施是什麼，那些策略又是什麼，我相信此時你的腦海裡一片空白。資深的 Tech Lead 同樣無法回答這些問題，但我們必須承認在處理團隊衝突問題上他們更遊刃有餘。如果標準答案真的存在並且有機會回顧資深 Tech Lead 解決這類問題的方式，會發現兩者多半是相似的。
之所以「信手拈來」重要，是因為問題總是會以教科書之外的形態不規律的出現在你面前。對於大部分不是在開會就是在開會路上的 Tech Lead 而言，在收到訊息的當下，不會留有時間允許你小心翼翼的衡量利弊之後再做決策。
「標準答案」的另一個副作用是它難免讓你懷疑直覺，當你的一個想法在材料從未被提及，或者與材料中觀點相左時，你應該相信你自己嗎？我傾向如此。我們必須承認的一件事是，並不是所有解決方案的正確性都可以通過科學來檢驗。舉一個簡單的例子，我認為給團隊工作留出一定的空閒時間很重要。這裡的空閒時間並不是指因為擔心無法任務而將交付日期有意延長的多餘時間，而是指程式設計師可以在上班階段徹底「不用幹活」的時間。之所以打引號是因為我發現即使你有意讓程式設計師慢下節奏來，他們總能給自己「沒事找事」，比如做些小工具，比如對程式碼做一些重構，或者嘗試一些新技術，放心這些都是圍繞當前工作展開的。即使不存在貢獻改進的個體群體也依然可以受益，例如輕鬆的工作下程式碼的質量也會比高壓情況下的更好。
以上結論完全來自於我的工作經驗，其中的道理再簡單不過了，所有讓軟體變得更好的實踐都是需要成本的，而且成本中的相當部分一定是時間。我相信即使我沒法用科學對它做出證明，你的開發體驗多半也會讓你在感性上同意我的觀點
並不是說理論知識就不重要了，只不過它們成為不了你成長路上的單點依賴。在我看來它們的重要性體現在它們是標準答案，但是是極具理想主義的標準答案：在天時地利人和的簇擁下，方案得以順利實施並且得以解決。可如果條件並不存在，或者只有部分存在，那麼你則需要有的放矢的對標準答案進行調整，結果也不至於太壞。同時如果有機會將你曾經解決問題的辦法與之進行對比，你能夠從中體會的也會更多
我想起了近期上映電影《奧本海默》裡的一段臺詞：They won't fear it until they understand it. And they won't understand it until they've used it——是的，知識在你實際運用它之前，它對你一文不值，你還對它一無所知。
人類毫無疑問是樂觀的，我欣賞這種樂觀。但當下樂觀似乎演變成了一類政治正確：問題必然存在答案；你務必要積極向上。於是我們讀到的文字也無不透露著這類氣息：所有的問題都不應成為問題；或者問題之所以成為問題，那是因為你的問題（這便是新自由主義）。
去年我寫過一篇有關團隊管理的文章《幫助團隊成長是唯一的出路》，這不是什麼譁眾取寵的漂亮話，而是我真心相信如此。我至今依然認為這是 Tech Lead 的主要職責，並且是改善交付的手段之一，但當下我不會認為它是最佳或者說唯一的方式了。因為我們似乎從來沒有正面回答過一個問題：如果它的方法不奏效怎麼辦？或者客氣點說，至少對你不奏效怎麼辦？我們應該如何理解這件事？
一方面我們需要理解所有的這些文字都經過了適度包裝，或是讓你相信它的權威，或是讓你相信自己的潛能，最為重要的是要給予你追隨它的理由，比如解決問題的希望；另一方面想當然世界上不存在一勞永逸解決問題的方法，方案總是幫隨著必要的前置條件，也許其中的部分在你所遇到的問題裡並不成立。
回到本文開頭所說的諸如《成為優秀 Tech Lead 的六個建議》這類文章（抱歉這個文章標題是我瞎編的，如有雷同實屬巧合），它以一種積極向上的口吻在暗示你：你是問題的瓶頸，你可以做的更好。但事實上，有些問題源自歷史包袱，有的是來自於在大環境和行業壓力之下，很多問題不是個體可以解決的。作為 TL 你需要知道你權力和能力的邊界在哪；你需要區分哪些是 must have，哪些是 nice to have，更重要的是哪些是 will not to have，這樣你才能把有限的精力投入到亟需被解決的問題中。在保證交付的目標之下，我越來越意識到不是所有的問題都需要被解決，或是被完美的解決。
例如考慮到不同人的背景、天賦，雖然我們每個人都在儘可能避免評判他人，也不希望被他人評判，但抱歉這無法避免。在具體的工作內容面前，TL 必須要做出選擇應該選用哪些人、哪些具有什麼樣能力的人加入團隊才能保證交付的順利完成。也許對於有的人來說，去填補他與對他期望之間的 gap 只不過是時間上的問題，但有時候我們必須考慮，這裡的時間是不是專案能夠承受的起的。
抱歉這些話表達的非常不近人情——現實一點，我想說的僅此而已
猜你喜歡