Тимлид vc техлид. В чем разница, какие функции

5030
#Команда 27 мая 2021

Сегодня я постараюсь рассказать про роль техлида в компании. Напомню, что в октябре 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.
  • Системы мониторинга и управления инцидентами.
  • Серверные операционные системы и их сервисы.
  • Скрипты и собственные наработки кода.

Кто может стать техлидом?

В целом, любой опытный разработчик, который любит и умеет глубоко погружаться в технологии, плюс эффективно управляет собственными знаниями и ориентируется на вертикальное масштабирование компетенций. Время, которое нужно для того, чтобы стать хорошим техлидом, определить сложно. Здесь высокая корреляция между проектами и профессионализмом. В целом, техлид становится техлидом примерно за год работы в проекте, насыщенном технологиями.

Те же из разработчиков, кто эффективно работает и с базовыми знаниями по разным технологиям, плюс ориентируется на горизонтальное масштабирование, могут быть очень хорошими разработчиками-инженерами, тимлидами, при условии наличия соответствующих амбиций и софт-скиллов. Но вот техлидами они вряд ли станут.

Для становления в качестве профессионала нужно быть очень сильно увлеченным технологиями человеком, который при этом владеет навыками самоорганизации. Не помешает еще и умение мыслить стратегически, плюс уметь видеть перспективность тех либо иных технологий в применении к текущему проекту.


Комментарии и обсуждения статьи в нашем блоге на Хабр.


Контент-хаб

0 / 0
+7 495 981-01-85 + Стать клиентом
Услуги Кейсы Контент-хаб