Привет, Хабр!
Меня зовут Ваня Антипин, я 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.
Системы мониторинга и управления инцидентами.
Серверные операционные системы и их сервисы.
Скрипты и собственные наработки кода.
Кто может стать техлидом?
В целом, любой опытный разработчик, который любит и умеет глубоко погружаться в технологии, плюс эффективно управляет собственными знаниями и ориентируется на вертикальное масштабирование компетенций. Время, которое нужно для того, чтобы стать хорошим техлидом, определить сложно. Здесь высокая корреляция между проектами и профессионализмом. В целом, техлид становится техлидом примерно за год работы в проекте, насыщенном технологиями.
Те же из разработчиков, кто эффективно работает и с базовыми знаниями по разным технологиям, плюс ориентируется на горизонтальное масштабирование, могут быть очень хорошими разработчиками-инженерами, тимлидами, при условии наличия соответствующих амбиций и софт-скиллов. Но вот техлидами они вряд ли станут.
Для становления в качестве профессионала нужно быть очень сильно увлеченным технологиями человеком, который при этом владеет навыками самоорганизации. Не помешает еще и умение мыслить стратегически, плюс уметь видеть перспективность тех либо иных технологий в применении к текущему проекту.
