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