為什麼我們需要 Tech Lead

Aiko · November 13, 2019, 2:01am

Tech Lead
為什麼我們需要 Tech Lead？
什麼是 Tech Lead？
如何成為 Tech Lead？
Tech Lead 需要哪些能力？
Tech Lead 責任邊界
Tech Lead 能力模型
項目生命周期中的 Tech Lead
技術準備期（磨合期）
業務回補期
成長優化期
其它
Tech Lead 關注哪些內容？
Programming
自己的編碼時間：>30%。
建立規範、原則、模式
構建團隊文化（技術）
創造技術遠景
People
心流：不同時期的不同挑戰
確保團隊的多樣性
打造學習文化
贏得信任
Process
提升 Tech Lead 能力
Developer
Architecture
演進式架構
跨功能性需求
Leadership
激勵
處理衝突：談判
管理風險
干係人分析
影響（Influence）
空降 Tech Lead
Tech Lead 工具箱
Path to Production：上線可視化
C4 Model：架構可視化
ADR：架構決策記錄
技術債牆：技術債的可視化
技術雷達：保持技術的敏銳度
其它
小結
相關資料

2019 年 1 月 19 日 ~ 2019 年 1 月 20 日，蹭了一個公司的 Tech Lead 培訓—— Coach 來自 ThoughtWorks 中國區的兩個資深 Tech Lead 和 ThoughtWorks 澳大利亞聯邦區的資深 Tech Lead。兩天的培訓下來，學習到了不少的東西。內容只進不出，過些日子怕是會忘記了。於是，便有了這篇文章，一來記錄下自己學習的東西；二來，結合自己的「經驗」做一些總結。

文章較較較較較較較長長長長長長長，分為六部分的內容（PS：幸好 Phodit 編輯器（phodit.com），支持標題摺疊的功能）：

Tech Lead 定義
Tech Lead 需要哪些能力？
項目生命周期中的 Tech Lead？
Tech Lead 關注哪些內容？
提升 Tech Lead 能力
Tech Lead 工具箱

Tech Lead

為什麼我們需要 Tech Lead？

或許，你注意到了：我們說的是 Lead，而不是 Leader。因為當我們說 Leader 的時候，指的往往是領導（leader）——一個正式領導職務的人，肩負著領導（lead）團隊、組織前進的職責。而當我們說 Lead 的時候，說的則是一個帶領我們前進的人。這個人可以是領導（leader），也可以是其他/她人。也因此，Tech Lead 是一個角色，而非真實的崗位，這個角色的意義在於帶領其他/她人前進。兩者的定義如下圖所示：

那麼回想一下，在你的團隊里，你是跟著誰一起幹活？在做相關的技術工作的時候，你更願意聽誰的話，是你的領導，還是？

我們希望有人帶著我們一起幹活，比自己優秀的人一起工作，總能從他/她身上學到一些有用的東西。作為一個技術人員，我們服的是那些技術比自己好的人。同樣是一個功能，我們實現起來要一天，而他/她可能只需要一個小時——效率既高，質量又好。這樣的一個人，便相當於項目中的 Tech Lead，他/她並非真實的領導（leader）。但是在技術上，我們都聽他/她的。在他/她的幫助下，我們可以提升自己的技術，構建更好的應用。

如果你身處在金字塔關係的科層制組織中，再回憶一下，誰是你的管理者經常誇獎技術好的人？從某種意義上，他/她便相當於是項目的 Tech Lead。你的管理者會向他/她咨詢一些技術上的問題，相關的結論也往往會在你們的項目上使用。

對於 Tech Lead 來說，重要的不是管理，而是 Lead。那麼問題來了，到底什麼是 Tech Lead？

什麼是 Tech Lead？

也因此，那些自稱是「技術負責人」（Tech Lead）的人，往往不一定是真正的技術負責人。他/她們承擔項目的開發工作，只是作為一個項目或者是團隊的負責人，來管理這個項目；對這個項目進行一些技術決策——使用什麼框架、使用什麼服務、進行介面對接，不做一些編碼工作。他/她們相當於是這個項目的技術管理者（Tech Manager）。

為此，我們不得不再提及管理者這個角色。管理者分為四種類型：

Expert：某一方面技術能力很強，是某個領域的專家
Manager：擅長發布任務，設定目標，保證目標的達成
Coach：具有發展他人、團隊的能力
Leader：知道如何用正確的方式達成目標，激勵人

Tech Lead 便在這四種角色之間不斷的轉換。首先 Tech Lead 是技術上的 Expert，能解決項目上的複雜技術問題。又是一個 Coach，需要幫助到項目中的成員成長。還是一個 Leader，能以身作則，告訴其他/她人怎麼做。在需要的時候，還會成為項目上的 Manager，來完成團隊的目標。

而受限於不同公司的組織結構影響，Tech Lead 往往包含了多種角色——既是項目經理，又是技術負責人，又是……。如在 ThoughtWorks，Tech Lead 可以是一個純粹的技術崗位，有的則還要充當項目經理的職責。如果只以 Tech 來看待 Lead 這個角色，那麼它是：

架構師、技術專家。與項目經理，技術管理者相比，他/她不僅僅關注于項目的技術實踐和進度，還得去解決那些最複雜的技術問題。
技術榜樣。Tech Lead 更像是一個精神「領袖」，他/她需要讓項目中的其他/她人看到前進的方向。
開發人員。他/她在項目中抽取時間來編寫程式碼，如在培訓上所定義的那樣，至少需要 30% 的時間來編寫。一來，掌握項目相關的一系列技術；二來，不斷提升技術能力，而不是成為管理者。

除了技術上的工作，他/她還需要懂業務，以此才能開發出符合業務需求的軟體。還需要能管理風險（主要是技術相關的風險），才能對應變化。

這便是 Tech Lead 的相關領域模型。

如何成為 Tech Lead？

首先，看運氣……。每個組織的坑位都是有限的——一個蘿蔔一個坑。我第一次當 Tech Lead 的時候，是在畢業一年左右的日子。項目上的 TL 和 PM 相繼離職創業去了，剩下的人里，我大概是最熟悉項目相關的業務知識和技術知識。我就這麼莫名其妙地承擔了相關的角色。不過，這並不重要，重要的是有這個坑位突然空出來給你了。

其次，展示你的氣質和技術專長。除了你自己，沒有人知道你擅長哪些東西。這樣一來，你就很可能成為項目上的 2nd Tier（第二梯隊，簡稱備胎）。一旦人們覺得你是個好苗子，那麼成為 Tech Lead 就會從 0.01% 提升到了 1%。

最後，還是看運氣……。若是你們的組織里，一直有一個人技術比你好，而且這個人一直和你在一個項目里。天曉得，你這個萬年老二，什麼時候才能翻身。你還年輕，你熬過對方的。

不過，這些也都不重要——不要靠天吃飯，還是要靠嘴吃飯。我們所要做的是，時刻準備著——提升技術，掌握 Tech Lead 技能。

Tech Lead 需要哪些能力？

In my option，a Tech Lead should have those skills:

首先，要會吹 NB。
其次，知道怎麼畫餅。
然後，還要精通 PPT。
最後，還會精通 markdown 編程。

哦，好像不太對，上述都是瞎扯。

Tech Lead 責任邊界

下圖是 Patrick Kua （前 ThoughtWorks 大不列顛及北愛爾蘭聯合王國區的 Principal Technical Consultant ）提出的 Tech Lead 的責任範圍。換句話來說，它便是 Tech Lead 所要做的工作。

圖上的內容主要分為三部分：

Developer。作為一個開發人員，我們應該掌握好編程相關的技能：面向對象編程、函數式編程，結對編程技能，熟練使用各式的工具，疊代和增量式設計，設計模式，重構，自動化測試，類設計。
Architect。作為項目中的架構師，我們要考慮的因素有：跨功能需求，演進式架構，買還是做的決策，系統設計，計劃評估，技術風險管理，科技願景和凝聚力，關注全生命周期，廣泛的工具集，基礎設施，客戶引導。
Leadership。作為一個技術上的 Lead，我們要提升這些軟技能：回饋、溝通，教練，動機，關係構建，委託，影響，風險管理，衝突管理，團隊管理。

好吧，我承認要學習的東西太多了，尤其是對於一個目標是 Tech Lead 的程序員來說。即要成為一個優秀的開發人員，還要成長為一個架構師，最後還要在領導上有所提升。首先，我們可以成為那個技術最 NB 的人（best technical person），然後我們才能成為 Tech Lead。至少領導力什麼的，在技術準備充分之前，適當地花時間注意練習即可。

Tech Lead 能力模型

對應於此，我們也就有了自己的（ThoughtWorks）的 Tead Lead 自測模型。從下圖可以看出，它是在上圖的基礎上整理出來的：

（PS：歡迎基於開發你們的 Tech Lead 模型。自測工具使用：1. 從 1 ~ 5 為自己的相關能力打分，再一一連接對應的點數。 2. 在自己想提高的分數上畫點，再繪製成圈 2。）

相比之下，我們的 Tech Lead 模型倒是相對比較簡單——事項比較少：

Leadership。關注于情緒智力、持續影響、積極地發展他/她人、提升效率、積極地打造團隊、積極的風險管理、開放溝通
Developer。關注於好的編碼技能、全棧開發的經驗、模式意識、熟悉程式碼庫、持續提升、明確出問題、關注業務價值、溝通橋樑。
Architect。關注于架構遠景、聚焦于原則，系統、而非軟體，支持跨職能需求，未來思考。

但是呢，從技術上來看，每個的維度卻遠比上述的責任邊界要重。從 Leadership 來看，則更有所側重——側重於，以技術為主的軟技能。

這樣一看，確實說了很多的東西，但是過於抽象，反而顯得沒有一點實際的價值。我們還是對 Tech Lead 要做的事情，還是缺少一個宏觀的認識。在那之前，還是讓我們回到項目上，來看看項目上的 Tech Lead 的日常

項目生命周期中的 Tech Lead

在大部分的組織里，一個 Tech Lead 做的事情，每個人在日常中，到底還是看得一清二楚。可是呢，項目上的每一個人，並非都是從一開始就在這個項目中的。有一些是一開始加入的，一些是早期加入的，還有的則是中途加入的。

也因此呢，我便根據 Tech Lead 要做的一些事情，再按照之前定義的項目三步曲，繪製了一個在項目不同時間的 TODO Lists。

需要注意的是：這裡僅列出筆者覺得重要的部分（PS：由於是第一個版本，所以也可能缺少一些要點）。對於某些並非那麼重要的職責，可以在上述的 Tech Lead 模型中查看到。

技術準備期（磨合期）

在 ThoughtWorks 開啟一個項目的時候，會有這麼兩個時期：Inception、疊代 0。它們全程都需要一個資深的程序員、架構師參與。他/她的主要職責是設計出符合項目需要的架構。所謂的項目需要，並不一定是最合適於這個項目的技術方案。它可能受到利益相關者、組織架構等各種因素的影響，而導致最適合的方案無法採用。如最大的領導，喜歡的是 A 方案，而不是最佳的 B 方案。

Inception，主要用於驗證技術、業務、運營、設計、產品的可行性。過程中需要一個 Tech Lead 作為一個架構師，設計出符合項目需要的軟體架構。按照我的理解，相關的過程大概如下所示：

過程中，要與項目相關的利益相關者進行溝通，與開發人員一起探討……，最後妥協出一個能勉勉強強滿足各方需求的架構。我們還會從相關的討論中，梳理出項目相關的技術風險。

Interation 0。疊代 0，便是在正式開始開發人員，我們所要做的技術工作。它包含的內容有：

PoC 架構驗證。驗證系統的架構是否真正可靠，並做一些細微的調整。
搭建 CI/CD
編寫模式示範程式碼。以符合系統架構風格和模式的方式，結合業務功能編寫示例程式碼，作為其它人的參考。

除此，在技術準備期，我們還需要：

對項目成員進行技術培訓
設計、實施測試策略
部署設計及實踐

這是一個相當漫長的時期。

除此，在這個時間我們還要做的一件非常重要的是：隔離其他/她技術人員與業務人員的直接需求對話。

對於團隊的其他/她成員來說，任何的功能和需求的來源，只應該是來自於業務人員（源自業務需求），又或者是團隊中的技術負責人（技術需求）。而不應該由業務人員直接與其他/她開發人員溝通。哪怕是 Tech Lead 和業務人員不在的時候，也需要減少此類事情的發生。

業務回補期

無論是上一個時期，還是這一個時期，我們不得不妥協于業務開發的進度，而忽視一些技術上的追求。這也就導致了，我們在技術實踐上缺乏一些更好的實施。

也因此，作為一個 Tech Lead，我們需要建立一系列的規範：

著手建立技術債的白板。開始一步步償還一些技術債，諸如測試覆蓋率不足的問題。
創建團隊的技術文化。知識分享、知識傳遞等。
關注于團隊成員的成長。

過程中，不斷發布新版本的應用，也因此穩定了系統的部署架構。

成長優化期

到了這個階段，作為一個 Tech Lead，我們所要關注的內容，主要有兩部分：

架構演進。系統已經偏向于穩定，只是我們可以探索新的方式，來幫助我們解決當前的問題。
人員的培養和成長。團隊的大部分成員在這個時期，已經處於「無聊」階段，需要一些新的元素來幫助他/她成長。

這並不代表其他/她的幾個方面是穩定的。仍然會出現一些變化，只是這些變化的影響範圍並沒有那麼大。比如，一些關鍵的利益相關者更換了，那麼還需要重新的摩擦一斷時間。

其它

最後不得不提及的一點是：受多種因素的影響，項目的開發速率會先從落後于標準速率開始，而後追平，最後隨著平均水平的提高，便超過平均速率。

所以在這個過程中，需要 Tech Lead 在合適的時期，採用合適的策略。

Tech Lead 關注哪些內容？

作為一個 Tech Lead，我們在項目上主要關注于三個部分：

Programming
People
Process

同樣的，在不同的項目時期，也會執行不同的工作——部分內容我們在三步曲中已經介紹過。

Programming

編程，是 Tech Lead 的基本功。不論我們多忙，我們總需要深入程式碼庫，了解程式碼中的問題。

自己的編碼時間：>30%。

作為一個 Tech Lead，要想提升項目的程式碼質量，保證項目的可維護性；又要能解決項目中的複雜問題，那麼你一定是要加入到項目的開發中。離開一線的時間一遠，那麼便缺少程式碼相關的上下文，也難以成為 Tech Lead，轉而變成一個 Tech blabla。升職是一件好事，但是編程依然很重要。

依我們的培訓結論來看，寫程式碼的時間應該是 >30%。我並不知道這個值的來源，但是差不多是 1/3 的數值，所以你懂的。

建立規範、原則、模式

關於哪門語言是最好的？ 2 個空格還是 4 個空格？它們有太多的爭議。作為一個 Tech Lead，我們需要在磨合的過程中，保證出程式碼庫的一致性，盡可能在這方面減少多樣化。當然了，還要適當保留一定的多樣化，如允許 Vim/Emacs 的存在，編輯器和 IDE 的論戰是有益的一件事。

它們值得我們花時間去討論，而不是擱置爭議。

構建團隊文化（技術）

作為一個 Tech Lead，我們有理由保持一種好的團隊技術文化。試著去回答這些問題：

How long does the build stay broken?
Do people avoid conflict?
Do people offer new ideas?
Do people feel okay to admit being wrong?
Do people flag when they need help?

再去想想問題出在哪裡。

創造技術遠景

我們需要一個好的技術遠景，領先於業界，又或者是保持一流的水平。

People

People，是一個項目的重要因素。

心流：不同時期的不同挑戰

在項目的不同時間里，對於不同的人來說，他/她們都有不同的感受。這便是心流：

項目的初期，對於大部分的人來說，屬於挑戰水平高，技術水平一般（對項目不熟悉）的水平。而在項目的中後期，對於大部分的人來說，則項目處於無聊或者無感的狀態。在焦慮期，指導新人；在無聊期，創建一些技術挑戰……。

作為 Tech Lead 則需要在不同地時期，幫助其他/她人成長。從 Interests、Skills、Strengths、Goals 等不同的維度考慮，了解每個人的不同階段，幫助他/她們成長。

從某種意義上來看，我們需要了解每一個團隊人員的當前位置，而後幫他/也成長。而在項目啟動的時候，也可以一起進行頭腦風暴，了解每個人在這個項目上的四種訴求。

確保團隊的多樣性

不得不提及的一句話：

群體能力=平均個人能力+多樣性

若是團隊里沒有反對的聲音，取而代之的是沉默，那麼團隊就是有問題的。所以，要允許反對的聲音。哪怕是錯的，也需要等他/她說完。

打造學習文化

作為一個 Geek，我們總會想著努力不斷地提升自己的技術，想和那些優秀的人一起工作。可往往由於多種因素的限制，優秀的人總會到新的項目上。也只能自己成為一個優秀的人，並帶領其他/她人成為優秀的人，便可以與優秀的人一起工作。

為此，我們需要引入相關的知識分享文化技術寫作、讀書分享、結對編程、程式碼檢視、技術回顧會議等。

贏得信任

Tech Lead 保證技術實施的一個關鍵是，大家都信任你。一旦大家都不信任你的時候，又或者是你不信任自己的時候，那麼這個項目就會出現問題。它需要我們一步步地去構建出信任感。

除此，當你空降到一個新的團隊時，你作為 Tech Lead，便面臨著不少的挑戰。陌生的程式碼庫，試探你能力的成員……。

Process

不同的項目都有各種的流程，都有自己所處的時期。這裡就需要用到 Bruce Tuckman 的團隊發展階段模型（Tuckman Stages of Team Development Model）：

即：

組建期。（Forming）項目小組啟蒙階段。
激蕩期。（Storming）形成各種觀念，激烈競爭、碰撞的局面。
規範期。（Norming）規則，價值，行為，方法，工具均已建立。
執行期。（Performing）人際結構成為執行任務活動的工具，團隊角色更為靈活和功能化，團隊能量積聚于一體。
休整期。（Adjourning）任務完成，團隊解散。

它可以幫助我們對團隊有清晰的認識，隨後採取相應的行動，來幫助團隊成員明確目標。

而針對於不同的人來說，我們還需要即情境領導模式：

對應于不同的人，也就需要不同的方式，來帶領他/她們完成任務：

指導式（Directing）、告知式，對成員的角色和目標給予詳盡的指導，並密切監督員工的工作成效，以便對工作成果給予經常的回饋。
教練式（Coaching），向團隊成員解釋工作內容以及工作方法，同時繼續指導成員如何完成任務。
參與式（Participating），和團隊成員共同面對問題，制定解決方案，並給予鼓勵和支持；
委託式（Delegating），提供適當的資源，完全相信成員的能力，將工作任務交由員工全權負責、獨立作業。

事實上，這都是一些方法的總結，在我們日常在也都各自用到了。

隨後，我們還需要掌握好，如何進行有效的表達：

定：定方向，明確溝通的目的以及重要性，為什麼會有這次溝通談話
理：理情況，理清當前的事實，有哪些問題、疑慮，相互交換訊息
想：想方案，針對當前的問題有哪些解決方案，需要什麼樣的支持，需要哪些資源等等
明：明做法，制定出行動計劃，如何進行後續的追蹤，發生變化如何應對
做：做總結，總結這次溝通的要點，給予信心/鼓勵

方法論真是太多，太多了~。

提升 Tech Lead 能力

既然我們設定了 Tech Lead 的三個維度，那麼相應的提升也就放在三個維度的提升上。

Developer

對於 Developer 來說：面向對象編程、函數式編程，結對編程技能，熟練使用各式的工具，疊代和增量式設計，設計模式，重構，自動化測試，類設計……，一個都不能少。

所以，此處省略一萬個字……。

Architecture

關於架構相關的部分，我們已經在上面的部分里，劃定了要學習的一些重點。這裡就強調一下演進式架構和跨功能性需求。

演進式架構

演進式架構是一種支持將增量式、指導式的變更作為跨多個維度中的第一原則的架構。

大概，這是我司強調的重要架構吧~。

跨功能性需求

跨功能性需求，又可以稱為非功能性需求，是指依一些條件判斷系統運作情形或其特性，而不是針對系統特定行為的需求。它們一般以「xx性」結尾，即英文都是以「ility」結尾，如穩定性（stability，可移植性（portability）。維基百科上，有一份相關的列表：List of system quality attributes。這些需求又可以分為兩類 1：

運行質量（Execution qualities），可以在系統運作時觀察到的質量，例如保安性及易用性等。
發展質量（Evolution qualities），和軟體系統結構及開發過程有關的質量，例如軟體可測試性、可維護性、可擴展性、可伸縮性（scalability）等

這些跨功能需求，是我們在啟動項目（Inception）的時候，需要不斷咨詢干係人才能得到想要的內容。如向客戶，尋問他/她們當前的用戶數，以計算支持的併發數。了解客戶對於網站的可用性要求，即一年時間內網站允許的宕機時間：

描述通俗叫法可用性級別年度宕機時間基本可用性2 個 999%87.6 小時較高可用性3 個 999.9%8.8小時具有故障自動恢復能力的可用性4 個 999.99%53 分鐘極高可用性5 個 999.999%5分鐘更高的可用性，意味著更高的投入成本，才能降低伺服器的宕機時長。

推薦書單

《架構整潔之道》

Leadership

顯然，對於一個 Geek 來說，軟技能才是最大的考驗。

激勵

為了正確的激勵自己和他/她人，就需要識別出真正能影響內在驅動力因素。在《管理 3.0》一書中提到的 CHAMPFROGS Model，即 10 個內在動機：

好奇心（Curiosity）：我有很多事情需要調查研究和思考。
榮譽感（Honor）：我個人的價值體現在團隊中，這大大提高了我的忠誠度。
接受度（Acceptance）：我周圍的人能夠證明我做了什麼，我是誰。
精通（Mastery）：我的工作對我的能力是一種挑戰，但這種挑戰依然在我能力範圍之內。
能量（Power）：我有足夠的空間去影響我周圍發生的事情。
自由度（Freedom）：我與其他的人相互獨立，我有自己的工作和責任。
關聯性（Relatedness）：我與我周圍的人有良好的社會關係。
有序（Order）：有足夠的規則和政策能夠構建一個穩定的環境。
目標（Goal）：我生活的目標體現在我所做的工作中。
狀態（Status）：我的位置很好，得到了同事的認可。

每個人按自己的動機進行排序，而後有針對性地幫助他/她們：

處理衝突：談判

在項目中，難免會遇到各式各樣的衝突，諸如業務人員之間的衝突。它依賴於我們採用一定的模式來解決這些衝突。

這個時候，我們就需要 Thomas-Kilmann 衝突理論（TKI）：

再採取相應的策略：

談判分為軟式談判、硬式談判、原則式談判。對於原則式談判（Principled Negotiation）：

盡量擴大總體利益（追求雙⽅背後的共同目標和利益）
善於營造公開、公平、公正的競爭局面（以共贏為⽬標）
明確目標，善於妥協（認識並善⽤⾃己的相對實⼒力）
講究信用
求同存異（制定讓步和選擇空間的戰略）
使用客觀標準（努⼒理解對方，換位思考）
運用事實
人、事有別（對事不對人；溝通得當）

為此在談判之前，要做好一系列的準備工作。

管理風險

不作準備，就是在準備失敗。

從初始階段起，項目便充滿著各種的風險，也包含了很多的技術風險。作為一個 Tech Lead，管理這些風險也是我們的職責所在。其中的某些不確定性，會隨著項目的進行，不斷地減少。即不確定性之錐，描述了項目中不確定性量的演變過程，即不確定性不僅隨著時間的流逝而減少，而且也隨風險管理，特別是決策的確立而減小。如下圖所示：

隨著更多的研究和開發，有關項目的更多訊息被學習，然後不確定性趨於減少，當所有剩餘風險被終止或轉移時達到 0 ％。

為此，我們需要評估一下如何去應對這樣的風險，對應的有四個維度的展示方式：

避免：描述不接受時，它會給你帶來什麼好處
牽制：估計可能性
緩和：描述你將採取什麼步驟
規避：描述風險成為問題時的全部成本

對應的以下是各自的影響：

成本大體時間預期結果︎避免未來受益未來:arrow_down: 可能性牽制機會成本現在，未來:arrow_down: 影響緩和時間，精力，資源現在:arrow_down: 可能性影響規避0–相關資料，文章《「不確定性之錐」告訴你項目難度為何有 16 倍的差距》：https://zhuanlan.zhihu.com/p/32033094