為什麼我們需要 Tech Lead

flutter

#1

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% 的時間來編寫。一來,掌握項目相關的一系列技術;二來,不斷提升技術能力,而不是成為管理者。

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

Technical Lead 模型 1

這便是 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):

  1. 盡量擴大總體利益(追求雙⽅背後的共同目標和利益)
  2. 善於營造公開、公平、公正的競爭局面(以共贏為⽬標)
  3. 明確目標,善於妥協(認識並善⽤⾃己的相對實⼒力)
  4. 講究信用
  5. 求同存異(制定讓步和選擇空間的戰略)
  6. 使用客觀標準(努⼒理解對方,換位思考)
  7. 運用事實
  8. 人、事有別(對事不對人;溝通得當)

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

管理風險

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

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

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

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

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

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

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

干係人分析

項目干係人包括項目當事人、其行為能影響項目的計劃與實施,以及其利益受該項目影響(受益或受損)的個人和組織;也可以把他們稱作項目的利害關係者。

從他/她的支持程度和讚同程度來看,我們可以在坐標軸上,標出他/她的位置:

Stakeholder Mapping

對應的,則需要採取不同的溝通策略。

影響(Influence)

在團隊對話的時候,需要注意一些對話相關的風格。如下是四種不同的對話風格:

可以嘗試用羅伯特·西奧迪尼《影響力》(Influence: Science and Practice)一書中,介紹的影響力的六大原則來構建相關的影響力,即:

  1. 互惠互利。
  2. 承諾一致。
  3. 社會認同。
  4. 好感。
  5. 權威。
  6. 稀缺。

每個人都有自己擅長的部分,從自己擅長的部分出發。

空降 Tech Lead

當我們空降到一個新的團隊,成為一個 Tech Lead,要讓其他/她人信服,並不是一件容易的事。為此,我們可以嘗試這麼去做:

  1. Foreign -> Inclusion:優秀的自我介紹,快速熟悉項目的訊息,理解、並傾聽當前項目的問題,快速熟悉團隊,展示你的能力和承諾
  2. Inclusion -> Influence:了解相關的技術細節,明確表明行動,主動,同理心,以身作則,從小的成功開始
  3. Influence -> Openness:收集憂慮,要求/給回饋,聊八卦,顯示我們的弱點,承認錯誤,促進會議/分享,一起做個飯,社交活動

這些都只是一些方法論,首先去 證明你自己的價值,然後拉近和其他/她人的關係。

Tech Lead 工具箱

接下來,我們將介紹一些工具來幫助我們更好的開展 Tech Lead 相關的工作。值得注意的是,它們都需要不斷扡維護。

Path to Production:上線可視化

Path to Production 是以可視化的方式,來展示應用是如何上線的。如下圖所示:

(PS:相關的可視化工具見:)

在過程中,我們關注于 Process、People、Tooling、Artifacts 四個部分,來了解一個項目需要哪些流程、人、工具和產物。

除了用於展示的目的,發現每個流程的持續時間(Duration),我們還可以找到項目的痛點( Pain)。

它需要持續不斷地更新

C4 Model:架構可視化

C4 Model 是一個非常不錯的架構可視化工具,它從系統 System、容器 Container、組件 Component 和程式碼 Code 四個層次,由頂至底來介紹系統的架構:

它們的關係類似於:

它需要持續不斷地更新

ADR:架構決策記錄

ADR 架構決策記錄,是一個類似於亞歷山大模式(即:設計模式)的短文本文件。(雖然決策本身不一定是模式,但它們分享著力量的特徵平衡。)每個記錄都描述了一組力量和一個響應這些力量的決策。

(PS:相關的工具有 adr-tools 和適用於中文語言的 )

它需要持續不斷地更新

技術債牆:技術債的可視化

技術債,是你欠下的東西,需要去還。如果只記在心裡,那麼可能早晚會忘記,所以要可視化出來:

而如圖所示,並不是所有的技術債都值得立馬去修。成本高,而收益低的工作,可以以後再做嘛(很久很久以後,直到所有的人都忘記了)。

技術雷達:保持技術的敏銳度

技術雷達是一個非常不錯的季度技術總結。我們可以從中獲取,技術專家們對於技術趨勢的一些判斷,一些可能採用的新技術。而不是自己將時間花費在大量地、不同的技術上,轉而可以關注自己需要的那一部分:

當然了,也可以建立自己內部的技術雷達。如我在很久以前的項目里,就嘗試過:

時間太久了,這個審美和今天的差別有點大。

其它

你呢,還有什麼工具推薦?

  • Risk-storming(風險風暴)
  • 六頂思考帽

小結

萬能的坐標軸法,只要能設計各個維度,就可以進行相關的分析了。