Привет, Хабр!
Меня зовут Ваня Антипин, я Deputy CTO в компании AGIMA. Сегодня я постараюсь вам рассказать про роль техлида в компании. Напомню, что в октябре 2020 года мы говорили о роли тимлида в компании и команде. Если кратко от тимлида зависит многое, включая эффективность команды, достижение поставленных целей, оперативное решение рабочих тасков.
А что насчет техлида? Об этой специальности говорят не так часто, но техлиды важны и нужны не менее тимлидов. Более подробно я рассказываю об этом на курсе Руководитель команды разработки и делюсь реальными кейсами. Но не будем отвлекаться, приступим!
Техлид не специальность, а роль
Главное, что нужно знать о техлиде то, что это роль. Она может быть формальной, и может быть и номинальной, все зависит от проекта и команды. Так, техлидом может стать и чаще всего становится опытный инженер, который не только оперативно справляется с собственными задачами, но и может помочь коллегам, беря на себя дополнительные технические задачи и ответственность за них.
Что касается формальной или номинальной роли, то в классическом Scrum, например, нет роли техлида, а вот в проектах и командах, которые живут по Scrum, техлид есть.
Когда нужен техлид? В целом, он будет полезен практически везде и всегда, но особенно важна эта роль на больших проектах, где много задач, насыщенная архитектура и команда состоит из 3-х и более человек.
А что насчет обязанностей?
Основная задача техлида техническое ведение проекта, включая как всю целиком архитектуру решений, так и какие-то отдельные части. Техлид эксперт по технологиям реализуемого компанией проекта. За ним обычно последнее слово в принятии технических решений.
Пример разработка мобильного приложения. Если проект большой, то здесь обязанности техлида и тимлида редко пересекаются. Так, техлид отвечает за архитектуру мобильных приложений под две платформы, iOS и Android, за проектирования REST API в контексте разрабатываемой мобильной архитектуры. А вот за управление проектом, разработку серверной реализации API и результаты всего проекта отвечает тимлид.
Если проект не очень большой, то случается, что тимлид забирает на себя задачи техлида это те самые hard-скиллс, которые нужны тимлиду наравне с soft-скиллс.
Кстати, одна из главных задач техлида процесс управления техническим долгом проекта. Технический долг это несделанная в проекте работа, которая будет мешать его развитию в будущем, если так и не будет выполнена. В технический долг не включаются баги или отложенные низкоприоритетные фичи. Технический долг это, например, плохо спроектированная архитектура или запутанный код. Управление техническим долгом это его постоянный поиск, подсчёт стоимости и постепенное устранение.
Техлиды и тимлиды зоны ответственности
Выше эта тема уже немного затронута. Но в целом, разделение зон ответственности тимлида и техлида довольно дискуссионный вопрос. Но, в целом, у любой компании уникальный опыт и свой взгляд на разделение ответственности, плюс собственная схема распределения команды, операционные и бизнес-процессы. Поэтому сколько компаний, проектов и команд - столько и мнений.
Мы сразу провели границу между тимлидами и техлидами. Техлид это упор на Hard-скиллс, а тимлид на Soft-скиллс. Граница в соотношении этих навыков, причем в зависимости от контекста, заданного проектом и командой.
Для того чтобы прояснить ситуацию, приведу пример. Это кросс-платформенные проекты с сервис-ориентированной архитектурой по разработке омниканальных цифровых витрин. В рамках такого проекта разрабатываются web&mobile-приложения, сервисы управления контентом, сервисы интеграции и реализации бизнес-логики (API). В таком проекте может быть целая команда лидов:
-
Тимлид, управляющий процессами, коммуникациями и бюджетом.
-
Техлиды для каждой платформы, отвечающие за технические аспекты архитектуры и реализацию решений.
Разберемся детальнее с распределением ответственности между тимлидом и техлидом на примере процесса управления разработкой в контексты реализации фичей из бэклога. Процесс может быть таким:
-
Списком задач в бэклоге управляет руководитель проекта. Задачи по разработке уходят в работу на тимлида.
-
Тимлид получает задачу, проверяет точность и полноту требований в задаче, при необходимости уточняет детали или дополняет описание задачи описанием уточнением требований или описанием возможной реализации. Задача уходит в работу на техлида. При этом на проекте работает три техлида: фронт, бэк, мобилка; и тимлид понимаем из описания, на кого делегировать задачу.
-
Техлид получает задачу, проверяет точность и полноту требований в задаче, при необходимости дополняет описание задачи своей экспертизой в предметной области, может описать реализацию или уточнить по реализации предложенной тимлидом.
-
Техлид определял исполнителя и отдаёт задачу в работу.
-
Задача от разработчика возвращается на код-ревью к техлиду и техлид принимает задачу или отправляет на доработку с комментарием содержащим уточнения и рекомендации.
В таком процессе за техническое качество реализации отвечает техлид, а тимлид за сроки и бюджет.
В целом, тимлиду обязательно нужны технические знания, но они могут быть не настолько глубокими, как у техлида. А вот техлид в обязательном порядке должен быть экспертом во всех технологиях, которые используются в проекте, за который он отвечает.
Знания, умения и скиллы поговорим конкретнее
Важный момент в понимании сути работы техлида состоит в том, что техлид это эксперт. В то же время далеко не каждый эксперт техлид. Выше мы говорили, что техлид это, в основном, про Hard-скиллы. Но он должен владеть и определенным набором Soft-скиллов, ведь ему тоже нужно коммуницировать внутри команды, а также управлять знаниями о технологиях.
Базовый набор Soft-скиллс:
-
Поиск и подбор кандидата, собеседование.
-
Постановка личных целей.
-
Стратегическое видение развития.
-
Отношения с людьми: эмпатия и эмоциональный интеллект.
Базовый набор Hard-скиллс:
-
Знание языков разработки и опыт программирования. Знание сопутствующих и окружающих этот стек технологий.
-
Понимание архитектуры проекта: принципы проектирования архитектуры, паттерны и инструменты.
-
Процессы и инструменты тестирования. Оптимизация тестирования, метрики и мониторинг.
-
Управление инцидентами.
Теперь стоит поговорить технологии и инструменты, которыми должен владеть хороший техлид. Его зона ответственности технологии, IT-ландшафт проекта и технологический стек, реализующий бизнес-логику в контексте проекта. Соответственно, технологий много, а их сочетаний еще больше, причем для каждого конкретного проекта это сочетание уникально. Поэтому имеет смысл говорить не о конкретных программах, а сразу о классах решений и инструментов:
-
Текстовые редакторы и интегрированные среды разработки.
-
Инструменты для создания схем в разных графических нотациях и офисные программы.
-
Системы управления задачами и проектом.
-
Системы управления знаниями и документаций.
-
Системы управления версиями кода и инструменты CI/CD.
-
Системы контейнеризации и инструменты DevOps.
-
Системы мониторинга и управления инцидентами.
-
Серверные операционные системы и их сервисы.
-
Скрипты и собственные наработки кода.
Кто может стать техлидом?
В целом, любой опытный разработчик, который любит и умеет глубоко погружаться в технологии, плюс эффективно управляет собственными знаниями и ориентируется на вертикальное масштабирование компетенций. Время, которое нужно для того, чтобы стать хорошим техлидом, определить сложно. Здесь высокая корреляция между проектами и профессионализмом. В целом, техлид становится техлидом примерно за год работы в проекте, насыщенном технологиями.
Те же из разработчиков, кто эффективно работает и с базовыми знаниями по разным технологиям, плюс ориентируется на горизонтальное масштабирование, могут быть очень хорошими разработчиками-инженерами, тимлидами, при условии наличия соответствующих амбиций и софт-скиллов. Но вот техлидами они вряд ли станут.
Для становления в качестве профессионала нужно быть очень сильно увлеченным технологиями человеком, который при этом владеет навыками самоорганизации. Не помешает еще и умение мыслить стратегически, плюс уметь видеть перспективность тех либо иных технологий в применении к текущему проекту.
