Топ-5 технических навыков лучших тимлидов
2024-08-14 11:11
Статьи
За более чем 10 лет своей карьеры я наблюдал за развитием и работой 50+ команд: кто-то был менее успешным, кто-то был более успешным. Когда я перешел на позицию главного архитектора в компании, я стал отвечать в том числе за техническое развитие команд. В это время я начал подмечать разницу между техническими навыками тимлидов более успешных команд. В этой статье я расскажу вам о 5 навыках, владея которыми, вы сможете привести свою команду к успеху.
1️⃣Понимание архитектуры своего продукта
Тимлиды очень часто вырастают из разработчиков, причем какого-то определенного стека: фронтенд, бекенд или другого. Это влияет на то, что новоиспеченный лид больше фокусируется на частях системы, знакомых ему по предыдущей роли. Как-то я общался с лидом, экс-фронтендером, и спросил, где хостится его приложение. Он не смог мне ответить :(
Понимание того, что из себя представляет подконтрольная система критически важно для обеспечения технического качества, дальнейшего развития, реализации различных изменений.
Когда я пришел на позицию тимлида в Xsolla, у меня было три основных стека - backend (PHP), frontend (JS/ReactJS) и desktop (С++/Qt). На тот момент я был уже синьором-плюсовиком, но я понимал, что мне необходимо “раскурить” остальные части системы. Я потратил достаточно много времени на то, чтобы разобраться в общей архитектуре системы, где она хостится, какие у нас БД и так далее, после этого я стал изучать backend-разработку (уже через несколько месяцев я сносно писал на Golang). Все это было очень кстати, так как мне предстояло принять несколько важных решений по реализации сложных технических компонентов и по смене стека - мы решили переезжать с PHP на Golang.
Здесь можно отметить следующие пункты, необходимые для понимания:
2️⃣Архитектура решений
Очень часто инженеры работают на уровне одного приложения, гораздо реже на уровне системы. Тимлид же охватывает полностью всю систему, включая интеграции с внешними компонентами. Поэтому для развития критически важно иметь навыки архитектуры решений, то есть работы на уровне нескольких приложений или даже систем.
В рамках работы лидом я принимал решения по изменениям, которые могли задевать сразу все наши технические компоненты. Чтобы задача была решена успешно, необходимо было учесть абсолютно все связи, абсолютно все интеграции. Для этого я сначала смоделировал новую систему, описал основные решения (ADR), спроектировали API и только после этого мы начали собственно разработку.
Такую функцию может выполнять и синьор, и командный архитектор, или даже выделенный архитектор решений, но тимлид должен понимать, как работать со своим набором приложений.
Дополнительно стоит отметить документирование решений, что необходимо для развития системы на протяжении длительного промежутка времени: такие артефакты как ADR позволяют определить мотивацию того или иного решения, а также помочь понять, как работает система. Плюс это большое подспорье в онбординге новичков.
3️⃣Управление техническим долгом
Технический долг - очень трудная к пониманию концепция, и в тоже время сильно влияющая на эффективность процессов разработки и даже на эмоциональное состояние программистов. Я даже решил посвятить этой теме отдельную главу в своей книге.
Зачем же необходимо управлять техническим долгом? Чрезмерное увеличение долга влечет за собой:
Финансово технический долг представляет из себя увеличение расходов на поддержку и развитие системы. Это достаточно просто перевести в рубли (или доллары, как удобнее).
Основные составляющие управления долгом:
4️⃣Техническое оперирование
Если система кому-то нужна, то она должна работать. Если система работает, то периодически могут возникать непредвиденные ситуации: будь то проблема в самой системе или внешние обстоятельства.
Техническое оперирование сводится к тому, чтобы минимизировать количество инцидентов во время работы системы, а также к минимизации длительности и ущерба самих инцидентов.
Я включаю сюда следующие пункты:
Данная тема сильно перекликается с архитектурой, в частности масштабирование и обработка трафика и SRE (метрики, логи, мониторинг, инцидент-менеджмент).
Владение навыком технического оперирования позволяет делать системы стабильными, выдерживающими необходимый набор трафика, что напрямую влияет на то, сколько денег может заработать компания.
5️⃣Стратегическое развитие
Реализованная система соответствует требованиям очень небольшой промежуток времени, потому что требования меняются с очень большой скоростью. Я слышал такую фразу: “Крупную систему необходимо переписывать раз в 5 лет”. Я согласен с этим утверждением, потому что легаси трудно развивать, скорость внесения изменений низкая, что замедляет развитие компании. А в наше время быстрая реакция на вызовы рынка жизненно необходима.
Навык стратегического развития позволяет тимлидам планировать изменения своих систем согласно вектору изменений продукта или проекта, в том числе:
Планы по техническому направлению могут включать в себя:
Также здесь могу посоветовать прорабатывать план “сверху-вниз”, т.е. определять сначала самые важные цели и моменты, и лишь потом прорабатывать детали.
Итого
Развитие успешной команды — это сложная, но интересная задача. Наличие технических навыков, которые мы обсудили, поможет вам не только обеспечить устойчивое развитие вашего проекта, но и создать продуктивную и мотивированную команду, готовую к любым вызовам. Понимание архитектуры продукта, грамотное управление техническим долгом, навыки стратегического развития и другие аспекты, упомянутые выше, — все это критически важно для тимлида.
Если вы хотите углубиться в эти темы или нуждаетесь в персональной консультации по развитию ваших технических навыков или навыков вашей команды, не стесняйтесь обращаться ко мне. Я с удовольствием поделюсь своим опытом и помогу вам наметить план развития.
1️⃣Понимание архитектуры своего продукта
Тимлиды очень часто вырастают из разработчиков, причем какого-то определенного стека: фронтенд, бекенд или другого. Это влияет на то, что новоиспеченный лид больше фокусируется на частях системы, знакомых ему по предыдущей роли. Как-то я общался с лидом, экс-фронтендером, и спросил, где хостится его приложение. Он не смог мне ответить :(
Понимание того, что из себя представляет подконтрольная система критически важно для обеспечения технического качества, дальнейшего развития, реализации различных изменений.
Когда я пришел на позицию тимлида в Xsolla, у меня было три основных стека - backend (PHP), frontend (JS/ReactJS) и desktop (С++/Qt). На тот момент я был уже синьором-плюсовиком, но я понимал, что мне необходимо “раскурить” остальные части системы. Я потратил достаточно много времени на то, чтобы разобраться в общей архитектуре системы, где она хостится, какие у нас БД и так далее, после этого я стал изучать backend-разработку (уже через несколько месяцев я сносно писал на Golang). Все это было очень кстати, так как мне предстояло принять несколько важных решений по реализации сложных технических компонентов и по смене стека - мы решили переезжать с PHP на Golang.
Здесь можно отметить следующие пункты, необходимые для понимания:
- Текущая архитектура
- Инфраструктура: где хостятся приложения, какие БД, кеши используются, есть ли CDN и так далее
- Используемый стек, вне зависимости от области - фронт, бекенд, мобилки и так далее.
2️⃣Архитектура решений
Очень часто инженеры работают на уровне одного приложения, гораздо реже на уровне системы. Тимлид же охватывает полностью всю систему, включая интеграции с внешними компонентами. Поэтому для развития критически важно иметь навыки архитектуры решений, то есть работы на уровне нескольких приложений или даже систем.
В рамках работы лидом я принимал решения по изменениям, которые могли задевать сразу все наши технические компоненты. Чтобы задача была решена успешно, необходимо было учесть абсолютно все связи, абсолютно все интеграции. Для этого я сначала смоделировал новую систему, описал основные решения (ADR), спроектировали API и только после этого мы начали собственно разработку.
Такую функцию может выполнять и синьор, и командный архитектор, или даже выделенный архитектор решений, но тимлид должен понимать, как работать со своим набором приложений.
Дополнительно стоит отметить документирование решений, что необходимо для развития системы на протяжении длительного промежутка времени: такие артефакты как ADR позволяют определить мотивацию того или иного решения, а также помочь понять, как работает система. Плюс это большое подспорье в онбординге новичков.
3️⃣Управление техническим долгом
Технический долг - очень трудная к пониманию концепция, и в тоже время сильно влияющая на эффективность процессов разработки и даже на эмоциональное состояние программистов. Я даже решил посвятить этой теме отдельную главу в своей книге.
Зачем же необходимо управлять техническим долгом? Чрезмерное увеличение долга влечет за собой:
- значительное замедление работы команды, в том числе, собственно, кодинг и тестирование
- рост числа инцидентов и багов на продакшене
- снижение мотивации и ухудшение эмоционального состояния разработчиков (вспомните все эти шутки про страшное легаси).
Финансово технический долг представляет из себя увеличение расходов на поддержку и развитие системы. Это достаточно просто перевести в рубли (или доллары, как удобнее).
Основные составляющие управления долгом:
- Фиксация: необходимо регистрировать найденный или созданный долг
- Анализ: как много долга сейчас? Насколько это критично? Объем долга увеличивается или уменьшается? Какой тренд?
- Гашение: определение стратегии уменьшения долга, выделение времени, использование принципа бойскаута
- Определение и демонстрация результатов: фиксация изменения уровня долга, демонстрация команде для повышения ее мотивации и “боевого духа”.
4️⃣Техническое оперирование
Если система кому-то нужна, то она должна работать. Если система работает, то периодически могут возникать непредвиденные ситуации: будь то проблема в самой системе или внешние обстоятельства.
Техническое оперирование сводится к тому, чтобы минимизировать количество инцидентов во время работы системы, а также к минимизации длительности и ущерба самих инцидентов.
Я включаю сюда следующие пункты:
- Защита от атак и увеличения трафика: rate-лимиты, масштабирование систем, в том числе автоматическое горизонтальное масштабирование
- Работы с метриками и логами
- Disaster recovery: определение DR планов, проведение обучение
- Инцидент-менеджмент: решение инцидентов, фиксация пост-мортемов, выполнение экшенов для предотвращения инцидента в будущем.
Данная тема сильно перекликается с архитектурой, в частности масштабирование и обработка трафика и SRE (метрики, логи, мониторинг, инцидент-менеджмент).
Владение навыком технического оперирования позволяет делать системы стабильными, выдерживающими необходимый набор трафика, что напрямую влияет на то, сколько денег может заработать компания.
5️⃣Стратегическое развитие
Реализованная система соответствует требованиям очень небольшой промежуток времени, потому что требования меняются с очень большой скоростью. Я слышал такую фразу: “Крупную систему необходимо переписывать раз в 5 лет”. Я согласен с этим утверждением, потому что легаси трудно развивать, скорость внесения изменений низкая, что замедляет развитие компании. А в наше время быстрая реакция на вызовы рынка жизненно необходима.
Навык стратегического развития позволяет тимлидам планировать изменения своих систем согласно вектору изменений продукта или проекта, в том числе:
- Адаптация под новые функциональные требования
- Адаптация под новые нефункциональные требования: система для 100RPS сильно отличается от системы на 1000RPS, которая отличается от системы на 10000 RPS
- Изменение рынка труда: например, сейчас трудно найти Ruby разработчиков, поэтому будет неэффективно иметь системы на Ruby. Оптимальнее перейти на Golang или Python.
Планы по техническому направлению могут включать в себя:
- Изменение стека: переходим с PHP на Golang
- Изменение архитектуры: шардируем БД для увеличения пропускной способности
- Инфраструктурные изменения: переходим в k8s для упрощения горизонтального масштабирования
- Использование тех или иных технологий или подходов: к примеру, serverless.
Также здесь могу посоветовать прорабатывать план “сверху-вниз”, т.е. определять сначала самые важные цели и моменты, и лишь потом прорабатывать детали.
Итого
Развитие успешной команды — это сложная, но интересная задача. Наличие технических навыков, которые мы обсудили, поможет вам не только обеспечить устойчивое развитие вашего проекта, но и создать продуктивную и мотивированную команду, готовую к любым вызовам. Понимание архитектуры продукта, грамотное управление техническим долгом, навыки стратегического развития и другие аспекты, упомянутые выше, — все это критически важно для тимлида.
Если вы хотите углубиться в эти темы или нуждаетесь в персональной консультации по развитию ваших технических навыков или навыков вашей команды, не стесняйтесь обращаться ко мне. Я с удовольствием поделюсь своим опытом и помогу вам наметить план развития.
