Служить и защищать: тимлид на страже команды⁠⁠

Привет, дорогой читатель! Хочу поделиться историей о том, как за 6 лет работы тимлидом в разных компаниях я понял, что наибольшую эффективность работы команды стоит ждать тогда, когда ты служишь своей команде. Сейчас объясню на примерах.

Кстати, термин «servant leadership» ввёл в 1970-х годах Роберт Гринлиф в своём эссе «Слуга как лидер». Он работал топ-менеджером в AT&T, и я понял то же, что и он, только спустя полвека.

Статья – чисто моё мнение и видение ситуации исходя из опыта. В роли тимлида я руководил различными командами: от 1 разработчика до группы из 20 человек (разработчики, тестеры, аналитики).

НАЧАЛО ПУТИ: ОТ ОДНОГО РАЗРАБА ДО ДВАДЦАТИ

Когда я дорос до тимлида, я попал в классическую ловушку. Думал: «Ну всё, теперь я главный, буду раздавать указания и следить за их выполнением». Но реалии были таковыми, что выполнять задачи – это полдела, а вот делать их эффективно – это надо попотеть и примерить на себя роли психолога, «старшего товарища» и лидера, которому доверяют коллеги, кто может свободно общаться с начальством о нуждах команды. По сути, такое связующее звено между эффективной командой и заказчиками. Это и есть суть servant leadership – служить команде, а не командовать ею.

Эту-то эффективность и надо выстраивать тимлиду, приводя команду к максимальной точке эффективности. Микроменеджмент долой!

К слову, обязанности тимлида, руководителя проекта и руководителя продукта в небольших компаниях переплетаются.

АВТОМАТИЗАЦИЯ РУТИНЫ

Первое, что я стараюсь сделать в этой роли – избавить команду от рутины. Настроить автоматизацию в Jira: сценарии для создания задач, автоматические переходы по статусам, уведомления, шаблоны новых задач. Разработчики, тестировщики и аналитики перестают тратить время на заполнение полей вручную, а рабочий процесс по описанию задач поставлен на рельсы.

Дальше берусь за GitLab (а в основном его сейчас используют) – включил линковку задач Jira с MR, проверки code style (линтер + SonarQube), запуск тестов. Также, MR проверяется в полуавтоматическом режиме с помощью AI.

Для тестировщиков будет удобным настроить систему логирования ошибок в проде – Sentry.

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

Таким образом, команда получила больше времени на то, что действительно важно – на написание кода. И, хочу заметить, что всё это должен проконтролировать тимлид (ну и техлид, если имеется).

ЗАЩИТА КОМАНДЫ ОТ НАЧАЛЬСТВА

Отдельная история – это утилиты для сбора статистики по работе сотрудников. Начальство любит цифры, и мы их должны предоставить. Вместо того, чтобы заставлять разработчиков писать отчёты – обычно автоматизируются выгрузки отчётов о закрытых задачах, времени их выполнения в разрезе по каждому разработчику. Всё это можно настроить через Jira API, либо платные плагины. Получилось «два в одном»: менеджмент доволен красивыми графиками, а команда не отвлекается на отчётность.

РИТУАЛЫ БЕЗ ФАНАТИЗМА

Насчёт стандартного набора тимлида: дейлики, ретро, планирование с Planning Poker. Главное – не переусердствовать. Всё для команды, а не команда для процессов. Если какая-то практика не работает, меняем или убираем.

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

Также хорошей практикой будет совместный поход в бар/квест с коллегами.

SCRUMBAN КАК КОМПРОМИСС

Насчёт методологий – никто в чистом виде их не использует. Обычно в моей практике получается так называемый Scrumban – помесь Scrum и Kanban. Почему? Потому что чистый Scrum слишком жёсткий для фронтенда (особенно когда постоянно прилетают «горящие» задачи), а чистый Kanban не особо предназначен для планирования.

Scrumban даёт гибкость Kanban с планированием из Scrum. Команда может быстро реагировать на изменения, но при этом не теряет фокус на основных целях спринта.

ВСЁ ВЫШЕ И ВЫШЕ И ВЫШЕ…

Отдельный навык servant leadership – это умение защищать интересы команды перед руководством. Когда разработчик хорошо работает, но по каким-то причинам не получает повышение зарплаты, моя задача – это исправить.

Готовлю аргументы, собираю метрики производительности, иду к начальству и «выбиваю» повышения. Не всегда получается, но попытки нужно делать. То же касается и обновления оборудования, или повышения в должности. После ответа руководства для самого разработчика перспективы работы в этой компании будут видны чётче. Команда должна знать, что тимлид на её стороне, что тимлид первым принимает удары и берёт ответственность за подчинённых и их ошибки.

Разбор ошибок с командой – всё это делается на общих встречах, а частные проблемы разбираются один на один (не при всех).

ПОЧЕМУ ЭТО РАБОТАЕТ

Servant leadership работает по простой причине: когда разработчики видят, что ты работаешь для них, а не против них, они начинают работать лучше. Не из страха, а из уважения и желания не подвести.

Плюс, такой подход снимает множество конфликтов. Команда понимает, что тимлид – это не «надсмотрщик», а партнёр, который помогает решать проблемы и защитит, если необходимо.

ЗАКЛЮЧЕНИЕ

За примерно шесть лет тимлидерства я понял: лучший руководитель – тот, кого не замечают, потому что всё работает как часы. Моя задача в роли тимлида – создать систему, где команда может эффективно работать без постоянного контроля и не отвлекаясь на посторонние дела.

Servant leadership – это не про мягкотелость или попустительство. Это про создание условий для максимальной продуктивности команды. И да, иногда приходится быть жёстким – но всегда в интересах команды, а не для демонстрации власти.

Если ты ещё не в деле – попробуй этот подход. Возможно, твоя команда станет не только эффективнее, но и счастливее. А счастливые разработчики пишут лучший код.

PS: Я не описал здесь про решение конфликтных ситуаций, но это тоже надо уметь делать деликатно. О чём будет одна из последующих статей.

Эту и другие мои статьи можно всегда обсудить тут «Life Developer. Статьи»