溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
本篇內容主要講解“怎么成為一名優秀的技術Leader”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“怎么成為一名優秀的技術Leader”吧!
首先，第一個問題：我們是否需要一個技術Leader？
也許會有人反對這個角色，并覺得優秀的開發人員可以自己做出決策，并做好部分技術Leader的工作。
即使存在以上這些完美的情況，在團隊成員間公開談論彼此，在達成一致同意的解決方案之前討論利弊，這些種種工作vs利益間微妙的平衡，或許需要技術Leader 這樣的一個角色。
我覺得不應該關注于這個角色是否應該存在，而最好將重點放在其職責可能會帶來的收益上。
技術Leader 與每個領導職位一樣，糟糕的領導者會使事情變得更糟。
可以明確的一點是： 一個合格的技術 Leader 有責任來幫助團隊的進步 。
作為該角色的人員，他應該具有非常不錯的技術視野/經驗以及良好的溝通技巧。他對項目或產品的技術方向負責（準確地說是對結果負責），并作為跨團隊溝通的首選人。
對于大中型團隊而言，Tech Leader 主要的職責包括：
1）指導項目的技術設計及制定開發規范
例如。我們將使用什么技術，我們將如何交付項目，我們將使用哪些模式等。
2）分析風險和跨功能要求
分析風險意味著降低風險：我們可以選擇某種方法，還是說有太多未知數。
在承擔一定風險時，對項目的影響是什么？例如。介紹您在會議上看到的新技術。
3）指導/教練經驗不足的新人
很可能在你的團隊中有不同的經驗的同學。一旦談到項目成本，考慮匹配技能和經驗時，它就變得很有意義。因此，需要重視對經驗不足新人的培養。
4）關注跨團隊協助與溝通
一個項目團隊包含各個相關聯角色群體，研發、測試、產品、運營甚至需求業務方等等，其他角色同學可能在技術上不如開發人員，他們將使用不同的語言，技術Leader 將需要關注于這一點，并做好協調與溝通。
正如職位所描述的那樣，技術 Leader是一份包含技術和管理雙重責任的工作，準確地說應該是：先技術，后領導。
那在實際工作過程中，需要注意做好哪些點呢？
倡導技術創新與變革，建立積極的思維模式。當一個流程緩慢或者繁瑣時，要嘗試去改變它，使其變得更好。這樣做的一種方法是使用 OODA 循環：
觀察（Observe）
定位（Orient）
決定（Decide）
行動（Act）
為了正確觀察緩慢或繁瑣的流程細節，最好的方式就是成為其中的一員（例如：著名的現場主義），并體驗與團隊中其他人一樣的痛苦。
你應該采取一種不斷改善某種狀況的心態。日本稱之為“Kaizen”（改善法，其起源于豐田公司在生產、機械和商務管理中持續改進的管理法）。
在我們的研發過程中，希望改進的是團隊的效率和樂趣，以及軟件項目的最終交付。
事情有可能會失敗，不用過分擔心失敗
技術方案落地可能失敗，項目開發建設可能失敗、部署上線可能失敗、系統重要監控點可能被遺漏、系統宕機崩潰可能會發生。
如果你已經為失敗做好了十足的準備，那么應該會比較容易應對。
當事情失敗時，不要尋找責怪的人！你是技術 Leader，有承擔的責任和義務。
花費你的精力來解決手頭的問題并從中吸取教訓。當然，不要在一個坑里摔倒兩次，如果你需要經歷兩次相同的失敗來解決同一個錯誤，那么你應該是做出了錯誤的決定。
從失敗中汲取教訓，將塑造您的方向，并在未來做出更好的決策。
學會為成功喝彩
當團隊有成就感時，成員們會感受到快樂，同時積極的情緒會讓后面的工作盡可能做到最好。慶祝階段的小成就非常重要，例如成功地沖刺或完成的功能。
當有人想出一個新想法時，也許是他們在會議上看到的一種方法或框架，如果這個想法得以實現，重要的是任何帶有新想法的人都應該被認可。這是非常有益的，將帶來更多的合作，創造力和開箱即用的思維。
形式也許沒那么重要，一頓小午餐，也許是一個團隊建設都是一個很好的想法，同樣可以凝聚一個快樂和積極的團隊。
技術主管有很多非編碼職責，但不要忽視實踐技術活動是非常重要的：
編寫代碼，進行概念驗證，定義接口等，根據團隊的成熟程度，您的參與會有所不同。
進行代碼CR，并審核您的代碼。當新人參與項目時，我傾向于進行大部分代碼審查，而且我會非常嚴格：我會編寫導致 NullPointerExceptions 的測試，我會要求他們遵守慣例，使用單一責任原則，小心包裝和命名等。我還將詳細說明這些評論的推理和所做出的選擇。這可能會挑戰現有的工作方式并提高代碼庫的成熟度。他們必須做的更改（審核后）將很快變得更少。
確保技術愿景存在，并由團隊共享。這一愿景需要符合客戶的需求。客戶需求將導致重要的限制，例如。關于重用（一個一次性的營銷項目與多年的企業努力……但要注意這種類型的約束也可能會改變）。分享您與團隊實現這一愿景的方式，將會對其采用產生巨大影響。嘗試讓團隊參與到技術愿景中。并確保他們知道他們如何為實現這一愿景做出貢獻。
密切關注代碼的演變：一段時間后，您所做的實際編碼量可能會更低，但您需要及時了解代碼的演變。您需要了解系統及其技術限制。
大多數（如果不是全部）開發人員將樂于定義框架，提倡某些方法等。但是，一些非功能性需求（也稱為質量屬性）（如網絡，安全性，部署和一致性）經常被忽視。
作為技術Leader，您應始終為您的團隊服務；提問、支持、指導或做出決定。
技術設計 為團隊（包括您）準備工作。確保清楚需要實施什么以及如何實施。這通常會考慮很多質量屬性，如網絡，安全性等。
業務：與客戶交談，查看他們的需求和目標，并將這些與項目的技術愿景相匹配。
項目管理：定義用戶故事，估算，跟進。
代碼：編寫代碼，進行代碼審查等。
對于每個人和每個項目，分配的百分比顯然會有所不同。查看實際情況也很重要，因為這些可以幫助您了解所花費的時間。
調解員：技術主管應該是調解員，便于討論。當人們有不同的意見時，你應該接受這一點。因為這意味著他們足夠關心某些事情來討論它。最后，我們朝著同一個目標努力。每個人都可以從別人的意見中學習。獲得團隊的意見并嘗試達成共識。如果達成共識真的不可能并且需要做出決定，那就做出決定。不決定總是會引發更多的討論。
導師：技術主管應該是開發人員的導師，當老師。當您查看代碼或解釋某些約定時，請務必清楚地解釋您為何以特定方式執行某些操作的原因。
有效的授權：一段時間后，您的團隊將采用某些最佳實踐，并且需要較少（嚴格）的審核或更多人將進行審核。在這一點上，您還可以向更多開發人員提供用戶故事的所有權。通過將所有權轉讓給開發人員，他們將非常積極地做好工作。技術主管不應該試圖承擔所有責任。技術主管需要確保某人承擔責任。
匹配目標：將開發人員的個人目標與項目和組織的更大目標相匹配。這是專門針對性的動態指導。動態，因為目標可以改變。在匹配目標時，溝通非常重要：它會讓人感到受到重視。
針對小組進行優化：團隊中的個人非常重要，但是當難以找到共識時，您應該關注的是團隊。合作良好的團隊將表現得更好，表現良好的團隊成員是快樂的成員。
一個好的技術 Leader：
知道什么時候給予輸入
知道何時做出決定
知道什么時候退后一步，讓團隊獲得更多的所有權。
分擔責任，給予所有權，但同時要保持負責。
霍夫施塔特定律：即使考慮到霍夫施塔特定律，它也總是比你預期的要長。——Douglas Hofstadter
項目工時評估很難，如果你經常這樣做，你會變得更好，但你仍然會有可能犯錯。
作為 Tech Leader，可能需要在團隊實際需求開發之前進行預估。更便于了解實現成本及優先級的安排調整。
為了達到這個目的，我建議使用三點估計，做一個樂觀的（Optimism 簡稱：O），一個最好的猜測（Best Guess 簡稱：BG）和一個悲觀的估計（Pessimism 簡稱：P），并使用這個公式：
（O + 4BG + P）÷ 6 //得到加權平均值
估計代表了團隊執行的能力；不是你自己實施的能力。還要確保，你知道你的可交付成果。這可能不止包括代碼和部署工具，例如：代碼CR，接口文檔等等
掌握評估是一生的旅程，它會讓你與眾不同。合作方會將你與專業、穩定和高質量的工作聯系起來。
非技術利益相關者使用的語言可能與開發團隊的語言是不同的。技術 Leader 必須找到一種以非技術人員可以理解的方式交流思想的方法。
這在 DDD （領域驅動設計）世界中，這意味著建立一種連接上下文通用語言。
與客戶密切合作，嘗試從他們那里檢測需求，并不斷地將他們的需求與正在進行的實施相關聯。
作為技術 Leader，在外部溝通合作中作為關鍵聯系人，與其他技術Leader 的溝通協作同樣也不可或缺。
有很多理由將自己與其他技術Leader 聯系在一起。
在個人層面上，它提供了向同行學習的機會：他們如何為團隊提供意見，以及他們如何在角色的不同職責之間分配時間。
在組織層面，應該考慮到是否有明確理解的總體目標。跟進技術架構設計的落地非常重要，以確保您的產品能夠很好地與其他組件一起使用，并確保更大的系統保持一致。有可能依賴于其他團隊的產品或其他團隊的成員，要確保在編制項目排期時考慮到這些因素。
這種協調在較大型的組織或客戶時是一個真正的問題。投入一些時間是必要的，以避免超出您的控制范圍的意外。
到此，相信大家對“怎么成為一名優秀的技術Leader”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
