我是架構精進之路，點擊上方「關注」，堅持天天爲你分享技術乾貨，私信我回復「01」，送你一份程序員成長進階大禮包。程序員

相信大部分人對於團隊管理和技術管理在認知上，存在必定隔閡，無形之中會將【管理崗】和【技術崗】進行對立比較。安全

在國內一些大研發團隊，通常會同時設置兩類角色來更好地作團隊運行管理。微信

研發經理/總監，主要負責團隊價值輸出和業務目標管理；網絡
技術Leader/架構師，主要負責技術攻堅和技術架構落地。架構

本文結合本人自身一些淺薄的技術管理認知，跟你們聊一下如何成長爲優秀的技術Leader。框架

是否須要一個技術Leader？

首先，第一個問題：咱們是否須要一個技術Leader？ide

也許會有人反對這個角色，並以爲優秀的開發人員能夠本身作出決策，並作好部分技術Leader的工做。工具

即便存在以上這些完美的狀況，在團隊成員間公開談論彼此，在達成一致贊成的解決方案以前討論利弊，這些種種工做vs利益間微妙的平衡，或許須要技術Leader 這樣的一個角色。學習

我以爲不該該關注於這個角色是否應該存在，而最好將重點放在其職責可能會帶來的收益上。測試

技術Leader 與每一個領導職位同樣，糟糕的領導者會使事情變得更糟。

技術Leader 須要具有什麼能力？

能夠明確的一點是：一個合格的技術 Leader 有責任來幫助團隊的進步。

做爲該角色的人員，他應該具備很是不錯的技術視野/經驗以及良好的溝通技巧。他對項目或產品的技術方向負責（準確地說是對結果負責），並做爲跨團隊溝通的首選人。

對於大中型團隊而言，Tech Leader 主要的職責包括：

1）指導項目的技術設計及制定開發規範

例如。咱們將使用什麼技術，咱們將如何交付項目，咱們將使用哪些模式等。

2）分析風險和跨功能要求

分析風險意味着下降風險：咱們能夠選擇某種方法，仍是說有太多未知數。

在承擔必定風險時，對項目的影響是什麼？例如。介紹您在會議上看到的新技術。

3）指導/教練經驗不足的新人

極可能在你的團隊中有不一樣的經驗的同窗。一旦談到項目成本，考慮匹配技能和經驗時，它就變得頗有意義。所以，須要重視對經驗不足新人的培養。

4）關注跨團隊協助與溝通

一個項目團隊包含各個相關聯角色羣體，研發、測試、產品、運營甚至需求業務方等等，其餘角色同窗可能在技術上不如開發人員，他們將使用不一樣的語言，技術Leader 將須要關注於這一點，並作好協調與溝通。

如何作一個合格的技術Leader？

正如職位所描述的那樣，技術 Leader是一份包含技術和管理雙重責任的工做，準確地說應該是：先技術，後領導。

那在實際工做過程當中，須要注意作好哪些點呢？

1）倡導技術創新與變革

倡導技術創新與變革，創建積極的思惟模式。當一個流程緩慢或者繁瑣時，要嘗試去改變它，使其變得更好。這樣作的一種方法是使用 OODA 循環：

觀察（Observe）
定位（Orient）
決定（Decide）
行動（Act）

爲了正確觀察緩慢或繁瑣的流程細節，最好的方式就是成爲其中的一員（例如：著名的現場主義），並體驗與團隊中其餘人同樣的痛苦。

你應該採起一種不斷改善某種情況的心態。日本稱之爲「Kaizen」（改善法，其起源於豐田公司在生產、機械和商務管理中持續改進的管理法）。

在咱們的研發過程當中，但願改進的是團隊的效率和樂趣，以及軟件項目的最終交付。

2）坦然面對失敗與成功

事情有可能會失敗，不用過度擔憂失敗

技術方案落地可能失敗，項目開發建設可能失敗、部署上線可能失敗、系統重要監控點可能被遺漏、系統宕機崩潰可能會發生。

若是你已經爲失敗作好了十足的準備，那麼應該會比較容易應對。

當事情失敗時，不要尋找責怪的人！你是技術 Leader，有承擔的責任和義務。

花費你的精力來解決手頭的問題並從中吸收教訓。固然，不要在一個坑裏摔倒兩次，若是你須要經歷兩次相同的失敗來解決同一個錯誤，那麼你應該是作出了錯誤的決定。

從失敗中汲取教訓，將塑造您的方向，並在將來作出更好的決策。

學會爲成功喝彩

當團隊有成就感時，成員們會感覺到快樂，同時積極的情緒會讓後面的工做盡量作到最好。慶祝階段的小成就很是重要，例如成功地衝刺或完成的功能。

當有人想出一個新想法時，也許是他們在會議上看到的一種方法或框架，若是這個想法得以實現，重要的是任何帶有新想法的人都應該被承認。這是很是有益的，將帶來更多的合做，創造力和開箱即用的思惟。

形式也許沒那麼重要，一頓小午飯，也許是一個團隊建設都是一個很好的想法，一樣能夠凝聚一個快樂和積極的團隊。

3）保持技術

技術主管有不少非編碼職責，但不要忽視實踐技術活動是很是重要的：

編寫代碼，進行概念驗證，定義接口等，根據團隊的成熟程度，您的參與會有所不一樣。
進行代碼CR，並審覈您的代碼。當新人蔘與項目時，我傾向於進行大部分代碼審查，並且我會很是嚴格：我會編寫致使 NullPointerExceptions 的測試，我會要求他們遵照慣例，使用單一責任原則，當心包裝和命名等。我還將詳細說明這些評論的推理和所作出的選擇。這可能會挑戰現有的工做方式並提升代碼庫的成熟度。他們必須作的更改（審覈後）將很快變得更少。
確保技術願景存在，並由團隊共享。這一願景須要符合客戶的需求。客戶需求將致使重要的限制，例如。關於重用（一個一次性的營銷項目與多年的企業努力……但要注意這種類型的約束也可能會改變）。分享您與團隊實現這一願景的方式，將會對其採用產生巨大影響。嘗試讓團隊參與到技術願景中。並確保他們知道他們如何爲實現這一願景作出貢獻。
密切關注代碼的演變：一段時間後，您所作的實際編碼量可能會更低，但您須要及時瞭解代碼的演變。您須要瞭解系統及其技術限制。

大多數（若是不是所有）開發人員將樂於定義框架，提倡某些方法等。可是，一些非功能性需求（也稱爲質量屬性）（如網絡，安全性，部署和一致性）常常被忽視。

4）良好的時間管理

做爲技術Leader，您應始終爲您的團隊服務；提問、支持、指導或作出決定。

技術設計 爲團隊（包括您）準備工做。確保清楚須要實施什麼以及如何實施。這一般會考慮不少質量屬性，如網絡，安全性等。
業務：與客戶交談，查看他們的需求和目標，並將這些與項目的技術願景相匹配。
項目管理：定義用戶故事，估算，跟進。
代碼：編寫代碼，進行代碼審查等。

對於每一個人和每一個項目，分配的百分比顯然會有所不一樣。查看實際狀況也很重要，由於這些能夠幫助您瞭解所花費的時間。

5）成爲團隊導師

調解員：技術主管應該是調解員，便於討論。當人們有不一樣的意見時，你應該接受這一點。由於這意味着他們足夠關心某些事情來討論它。最後，咱們朝着同一個目標努力。每一個人均可以從別人的意見中學習。得到團隊的意見並嘗試達成共識。若是達成共識真的不可能而且須要作出決定，那就作出決定。不決定老是會引起更多的討論。
導師：技術主管應該是開發人員的導師，當老師。當您查看代碼或解釋某些約定時，請務必清楚地解釋您爲什麼以特定方式執行某些操做的緣由。
有效的受權：一段時間後，您的團隊將採用某些最佳實踐，而且須要較少（嚴格）的審覈或更多人將進行審覈。在這一點上，您還能夠向更多開發人員提供用戶故事的全部權。經過將全部權轉讓給開發人員，他們將很是積極地作好工做。技術主管不該該試圖承擔全部責任。技術主管須要確保某人承擔責任。
匹配目標：將開發人員的我的目標與項目和組織的更大目標相匹配。這是專門針對性的動態指導。動態，由於目標能夠改變。在匹配目標時，溝通很是重要：它會讓人感到受到重視。
針對小組進行優化：團隊中的我的很是重要，可是當難以找到共識時，您應該關注的是團隊。合做良好的團隊將表現得更好，表現良好的團隊成員是快樂的成員。

一個好的技術 Leader：

知道何時給予輸入
知道什麼時候作出決定
知道何時退後一步，讓團隊得到更多的全部權。

分擔責任，給予全部權，但同時要保持負責。

6）學會作評估

霍夫施塔特定律：即便考慮到霍夫施塔特定律，它也老是比你預期的要長。——Douglas Hofstadter

項目工時評估很難，若是你常常這樣作，你會變得更好，但你仍然會有可能犯錯。

做爲 Tech Leader，可能須要在團隊實際需求開發以前進行預估。更便於瞭解實現成本及優先級的安排調整。

爲了達到這個目的，我建議使用三點估計，作一個樂觀的（Optimism 簡稱：O），一個最好的猜想（Best Guess 簡稱：BG）和一個悲觀的估計（Pessimism 簡稱：P），並使用這個公式：

（O + 4BG + P）÷ 6 //獲得加權平均值

估計表明了團隊執行的能力；不是你本身實施的能力。還要確保，你知道你的可交付成果。這可能不止包括代碼和部署工具，例如：代碼CR，接口文檔等等

掌握評估是一輩子的旅程，它會讓你不同凡響。合做方會將你與專業、穩定和高質量的工做聯繫起來。

7）擅長與外部溝通對接

非技術利益相關者使用的語言可能與開發團隊的語言是不一樣的。技術 Leader 必須找到一種以非技術人員能夠理解的方式交流思想的方法。

這在 DDD （領域驅動設計）世界中，這意味着創建一種鏈接上下文通用語言。

與客戶密切合做，嘗試從他們那裏檢測需求，並不斷地將他們的需求與正在進行的實施相關聯。

做爲技術 Leader，在外部溝通合做中做爲關鍵聯繫人，與其餘技術Leader 的溝通協做一樣也不可或缺。

有不少理由將本身與其餘技術Leader 聯繫在一塊兒。

在我的層面上，它提供了向同行學習的機會：他們如何爲團隊提供意見，以及他們如何在角色的不一樣職責之間分配時間。
在組織層面，應該考慮到是否有明確理解的整體目標。跟進技術架構設計的落地很是重要，以確保您的產品可以很好地與其餘組件一塊兒使用，並確保更大的系統保持一致。有可能依賴於其餘團隊的產品或其餘團隊的成員，要確保在編制項目排期時考慮到這些因素。

這種協調在較大型的組織或客戶時是一個真正的問題。投入一些時間是必要的，以免超出您的控制範圍的意外。

總結

做爲技術Leader，也許除了以上列舉的幾項內容以外，還存在其餘不少軟性的素質能力。

欲求木之長者必固其本，欲求流之遠者必浚其源：

業務感知的背後，是對商業社會的理解，是對需求的洞察；
人員培養激勵的背後，是對人的理解，是對人性的洞察。

擁抱文化差別，多樣性很是寶貴。全部人都不一樣，過着不一樣的生活。

總結就是：每一個人都是團隊的一員，應該重視每一個人的意見。

由於你團隊的力量不是單個成員的才能，而是他們的合做，堅韌和相互尊重的總體效能的體現。

- END -

做者：架構精進之路，專一軟件架構研究，技術學習與我的成長，關注並私信我回復「01」，送你一份程序員成長進階大禮包。

往期熱文推薦：

「技術架構精進」專一架構研究，技術分享

Thanks for reading!

本文分享自微信公衆號 - 架構精進之路（jiagou_jingjin）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。

如何成爲一名優秀的技術Leader？