△點擊上方“Python貓”關(guān)注，回復“2”加入交流群

劇照：小謝爾頓

作者：架構(gòu)精進之路

來源：架構(gòu)精進之路

相信大部分人對于團隊管理和技術(shù)管理在認知上，存在一定隔閡，無形之中會將【管理崗】和【技術(shù)崗】進行對立比較。

在國內(nèi)一些大研發(fā)團隊，一般會同時設(shè)置兩類角色來更好地做團隊運行管理。

研發(fā)經(jīng)理/總監(jiān)，主要負責團隊價值輸出和業(yè)務目標管理；
技術(shù)Leader/架構(gòu)師，主要負責技術(shù)攻堅和技術(shù)架構(gòu)落地。

本文結(jié)合本人自身一些淺薄的技術(shù)管理認知，跟大家聊一下如何成長為優(yōu)秀的技術(shù)Leader。

是否需要一個技術(shù)Leader？

首先，第一個問題：我們是否需要一個技術(shù)Leader？

也許會有人反對這個角色，并覺得優(yōu)秀的開發(fā)人員可以自己做出決策，并做好部分技術(shù)Leader的工作。

即使存在以上這些完美的情況，在團隊成員間公開談論彼此，在達成一致同意的解決方案之前討論利弊，這些種種工作vs利益間微妙的平衡，或許需要技術(shù)Leader 這樣的一個角色。

我覺得不應該關(guān)注于這個角色是否應該存在，而最好將重點放在其職責可能會帶來的收益上。

技術(shù)Leader 與每個領(lǐng)導職位一樣，糟糕的領(lǐng)導者會使事情變得更糟。

技術(shù)Leader 需要具備什么能力？

可以明確的一點是：一個合格的技術(shù) Leader 有責任來幫助團隊的進步。

作為該角色的人員，他應該具有非常不錯的技術(shù)視野/經(jīng)驗以及良好的溝通技巧。他對項目或產(chǎn)品的技術(shù)方向負責（準確地說是對結(jié)果負責），并作為跨團隊溝通的首選人。

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

1）指導項目的技術(shù)設(shè)計及制定開發(fā)規(guī)范

例如。我們將使用什么技術(shù)，我們將如何交付項目，我們將使用哪些模式等。

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

分析風險意味著降低風險：我們可以選擇某種方法，還是說有太多未知數(shù)。

在承擔一定風險時，對項目的影響是什么？例如。介紹您在會議上看到的新技術(shù)。

3）指導/教練經(jīng)驗不足的新人

很可能在你的團隊中有不同的經(jīng)驗的同學。一旦談到項目成本，考慮匹配技能和經(jīng)驗時，它就變得很有意義。因此，需要重視對經(jīng)驗不足新人的培養(yǎng)。

4）關(guān)注跨團隊協(xié)助與溝通

一個項目團隊包含各個相關(guān)聯(lián)角色群體，研發(fā)、測試、產(chǎn)品、運營甚至需求業(yè)務方等等，其他角色同學可能在技術(shù)上不如開發(fā)人員，他們將使用不同的語言，技術(shù)Leader 將需要關(guān)注于這一點，并做好協(xié)調(diào)與溝通。

如何做一個合格的技術(shù)Leader？

正如職位所描述的那樣，技術(shù) Leader是一份包含技術(shù)和管理雙重責任的工作，準確地說應該是：先技術(shù)，后領(lǐng)導。

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

1）倡導技術(shù)創(chuàng)新與變革

倡導技術(shù)創(chuàng)新與變革，建立積極的思維模式。當一個流程緩慢或者繁瑣時，要嘗試去改變它，使其變得更好。這樣做的一種方法是使用 OODA 循環(huán)：

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

為了正確觀察緩慢或繁瑣的流程細節(jié)，最好的方式就是成為其中的一員（例如：著名的現(xiàn)場主義），并體驗與團隊中其他人一樣的痛苦。

你應該采取一種不斷改善某種狀況的心態(tài)。日本稱之為“Kaizen”（改善法，其起源于豐田公司在生產(chǎn)、機械和商務管理中持續(xù)改進的管理法）。

在我們的研發(fā)過程中，希望改進的是團隊的效率和樂趣，以及軟件項目的最終交付。

2）坦然面對失敗與成功

事情有可能會失敗，不用過分擔心失敗

技術(shù)方案落地可能失敗，項目開發(fā)建設(shè)可能失敗、部署上線可能失敗、系統(tǒng)重要監(jiān)控點可能被遺漏、系統(tǒng)宕機崩潰可能會發(fā)生。

如果你已經(jīng)為失敗做好了十足的準備，那么應該會比較容易應對。

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

花費你的精力來解決手頭的問題并從中吸取教訓。當然，不要在一個坑里摔倒兩次，如果你需要經(jīng)歷兩次相同的失敗來解決同一個錯誤，那么你應該是做出了錯誤的決定。

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

學會為成功喝彩

當團隊有成就感時，成員們會感受到快樂，同時積極的情緒會讓后面的工作盡可能做到最好。慶祝階段的小成就非常重要，例如成功地沖刺或完成的功能。

當有人想出一個新想法時，也許是他們在會議上看到的一種方法或框架，如果這個想法得以實現(xiàn)，重要的是任何帶有新想法的人都應該被認可。這是非常有益的，將帶來更多的合作，創(chuàng)造力和開箱即用的思維。

形式也許沒那么重要，一頓小午餐，也許是一個團隊建設(shè)都是一個很好的想法，同樣可以凝聚一個快樂和積極的團隊。

3）保持技術(shù)

技術(shù)主管有很多非編碼職責，但不要忽視實踐技術(shù)活動是非常重要的：

編寫代碼，進行概念驗證，定義接口等，根據(jù)團隊的成熟程度，您的參與會有所不同。
進行代碼CR，并審核您的代碼。當新人參與項目時，我傾向于進行大部分代碼審查，而且我會非常嚴格：我會編寫導致 NullPointerExceptions 的測試，我會要求他們遵守慣例，使用單一責任原則，小心包裝和命名等。我還將詳細說明這些評論的推理和所做出的選擇。這可能會挑戰(zhàn)現(xiàn)有的工作方式并提高代碼庫的成熟度。他們必須做的更改（審核后）將很快變得更少。
確保技術(shù)愿景存在，并由團隊共享。這一愿景需要符合客戶的需求?？蛻粜枨髮е轮匾南拗疲?。關(guān)于重用（一個一次性的營銷項目與多年的企業(yè)努力……但要注意這種類型的約束也可能會改變）。分享您與團隊實現(xiàn)這一愿景的方式，將會對其采用產(chǎn)生巨大影響。嘗試讓團隊參與到技術(shù)愿景中。并確保他們知道他們?nèi)绾螢閷崿F(xiàn)這一愿景做出貢獻。
密切關(guān)注代碼的演變：一段時間后，您所做的實際編碼量可能會更低，但您需要及時了解代碼的演變。您需要了解系統(tǒng)及其技術(shù)限制。

大多數(shù)（如果不是全部）開發(fā)人員將樂于定義框架，提倡某些方法等。但是，一些非功能性需求（也稱為質(zhì)量屬性）（如網(wǎng)絡(luò)，安全性，部署和一致性）經(jīng)常被忽視。

4）良好的時間管理

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

技術(shù)設(shè)計 為團隊（包括您）準備工作。確保清楚需要實施什么以及如何實施。這通常會考慮很多質(zhì)量屬性，如網(wǎng)絡(luò)，安全性等。
業(yè)務：與客戶交談，查看他們的需求和目標，并將這些與項目的技術(shù)愿景相匹配。
項目管理：定義用戶故事，估算，跟進。
代碼：編寫代碼，進行代碼審查等。

對于每個人和每個項目，分配的百分比顯然會有所不同。查看實際情況也很重要，因為這些可以幫助您了解所花費的時間。

5）成為團隊導師

調(diào)解員：技術(shù)主管應該是調(diào)解員，便于討論。當人們有不同的意見時，你應該接受這一點。因為這意味著他們足夠關(guān)心某些事情來討論它。最后，我們朝著同一個目標努力。每個人都可以從別人的意見中學習。獲得團隊的意見并嘗試達成共識。如果達成共識真的不可能并且需要做出決定，那就做出決定。不決定總是會引發(fā)更多的討論。
導師：技術(shù)主管應該是開發(fā)人員的導師，當老師。當您查看代碼或解釋某些約定時，請務必清楚地解釋您為何以特定方式執(zhí)行某些操作的原因。
有效的授權(quán)：一段時間后，您的團隊將采用某些最佳實踐，并且需要較少（嚴格）的審核或更多人將進行審核。在這一點上，您還可以向更多開發(fā)人員提供用戶故事的所有權(quán)。通過將所有權(quán)轉(zhuǎn)讓給開發(fā)人員，他們將非常積極地做好工作。技術(shù)主管不應該試圖承擔所有責任。技術(shù)主管需要確保某人承擔責任。
匹配目標：將開發(fā)人員的個人目標與項目和組織的更大目標相匹配。這是專門針對性的動態(tài)指導。動態(tài)，因為目標可以改變。在匹配目標時，溝通非常重要：它會讓人感到受到重視。
針對小組進行優(yōu)化：團隊中的個人非常重要，但是當難以找到共識時，您應該關(guān)注的是團隊。合作良好的團隊將表現(xiàn)得更好，表現(xiàn)良好的團隊成員是快樂的成員。

一個好的技術(shù) Leader：

知道什么時候給予輸入
知道何時做出決定
知道什么時候退后一步，讓團隊獲得更多的所有權(quán)。

分擔責任，給予所有權(quán)，但同時要保持負責。

6）學會做評估

霍夫施塔特定律：即使考慮到霍夫施塔特定律，它也總是比你預期的要長?！狣ouglas Hofstadter

項目工時評估很難，如果你經(jīng)常這樣做，你會變得更好，但你仍然會有可能犯錯。

作為 Tech Leader，可能需要在團隊實際需求開發(fā)之前進行預估。更便于了解實現(xiàn)成本及優(yōu)先級的安排調(diào)整。

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

（O + 4BG + P）÷ 6 //得到加權(quán)平均值

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

掌握評估是一生的旅程，它會讓你與眾不同。合作方會將你與專業(yè)、穩(wěn)定和高質(zhì)量的工作聯(lián)系起來。

7）擅長與外部溝通對接

非技術(shù)利益相關(guān)者使用的語言可能與開發(fā)團隊的語言是不同的。技術(shù) Leader 必須找到一種以非技術(shù)人員可以理解的方式交流思想的方法。

這在 DDD （領(lǐng)域驅(qū)動設(shè)計）世界中，這意味著建立一種連接上下文通用語言。

與客戶密切合作，嘗試從他們那里檢測需求，并不斷地將他們的需求與正在進行的實施相關(guān)聯(lián)。

作為技術(shù) Leader，在外部溝通合作中作為關(guān)鍵聯(lián)系人，與其他技術(shù)Leader 的溝通協(xié)作同樣也不可或缺。

有很多理由將自己與其他技術(shù)Leader 聯(lián)系在一起。

在個人層面上，它提供了向同行學習的機會：他們?nèi)绾螢閳F隊提供意見，以及他們?nèi)绾卧诮巧牟煌氊熤g分配時間。
在組織層面，應該考慮到是否有明確理解的總體目標。跟進技術(shù)架構(gòu)設(shè)計的落地非常重要，以確保您的產(chǎn)品能夠很好地與其他組件一起使用，并確保更大的系統(tǒng)保持一致。有可能依賴于其他團隊的產(chǎn)品或其他團隊的成員，要確保在編制項目排期時考慮到這些因素。

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