Типичный программист

Привет, дорогой читатель! Хочу поделиться историей о том, как за 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. Статьи»

Привет! Хочу поделиться открытием, которое изменило моё отношение к работе. Оказывается, моя «странная» привычка отвлекаться на что-то фоном – вроде фильмов, серфинга по статьям или похода на кухню за кофе – на самом деле имеет научное обоснование. Возможно, далее ты узнаешь и себя.

ЧУТЬ ПОЯСНЕНИЯ

«Когнитивная недогрузка» – состояние, когда мозг получает недостаточно стимулов для полной загрузки. Исследования* показали: когда нам скучно, мозг начинает искать дополнительные источники информации. То есть чем больше ты погружаешься в задачу – тем сложнее уже тормозить во время вынужденных пауз и твой мозг «ищет топливо» для дальнейшей эффективной работы без остановки.

У программистов это особенно выражено. Запустил сборку – сиди «тупи» 3 минуты. Отправил вопрос в рабочий чат – ждёшь ответ. Думаешь над архитектурой – процесс небыстрый. В эти моменты часть мозга «простаивает» и требует загрузки.

МОЙ СЛУЧАЙ

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

Сначала думал, что это просто плохая привычка. Потом прочитал про когнитивную недогрузку и понял – это особенность работы моего мозга. Это объясняется нехваткой дофамина: мозг ищет дополнительные источники стимуляции. Дефицит дофамина затрудняет сосредоточение на рутинных задачах и приводит к быстрой потере интереса.

КАК ПРОЯВЛЯЕТСЯ У МЕНЯ

Я люблю во время вынужденных пауз читать различные технические статьи в интернете. А ещё у меня почти всегда запущен фоном какой-нибудь фильм, сериал или YouTube-подкаст во время работы.

Из-за этого, кстати, уже было недовольство начальства, когда приходилось работать в офисе. Со стороны кажется, что моё основное занятие за компом – это просмотр фильмов, хоть это совсем и не так. Тем более, что результаты работы, наоборот, были одни из лучших.

КАК НА СЧЁТ МУЗЫКИ?

Хороший вопрос. Пробовал музыку – не то. Мне нужен именно визуальный ряд, чтобы занять «простаивающую» часть мозга. Плюс, с YouTube я могу параллельно что-то новое узнать из последних тенденций IT в мире (привет TED).

ЧТО ГОВОРИТ НАУКА

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

Кто-то крутит спиннер, кто-то жуёт жвачку, кто-то листает соцсети. Главное – найти свой способ «догрузить» мозг, не мешая основной работе.

* см. работу «Malleable attentional resources theory» от Young & Stanton, 2002г.

А как ты справляешься с паузами в работе?  Что делаешь, пока ждёшь компиляцию кода?

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

Цитата из отчета:

"...ИИ помогает дописывать 50% символов кода. Другими словами, сейчас столько же символов в коде дописывается с помощью ИИ, сколько вручную вводят разработчики. Хотя инженерам всё ещё нужно тратить время на проверку предложений, у них остаётся больше времени для сосредоточения на проектировании кода"

📊 Подробнее в отчёте Google

Пишу о применении и влиянии новых технологий на бизнес и повседневную жизнь в Telegram канале: : https://t.me/+NimdslpY9WU0MDYy

Честно говоря, это было круто! Понимаешь весь процесс от начала до конца, можешь сам решить любую проблему. Никого не ждёшь, ни на кого не злишься – просто делаешь.

КАРЬЕРНЫЕ КАЧЕЛИ

Последние лет 10 меня кидает как маятник: то руковожу проектом, то ведущий фронтенд-разработчик, то архитектор, то снова тимлид. Код-ревью, планирование, совещания, ещё совещания... В какой-то момент понял, что кода пишу всё меньше, а времени на орг вопросы трачу всё больше.

Тимлид – это когда ты должен быть на связи 24/7. Суббота, воскресенье, утро 1 января – не важно. «Можешь быстро посмотреть?», «А как ты думаешь?», «А почему не работает?». И вроде бы статус высокий, зарплата больше но кайфа от работы меньше. Да, ты как небольшой руководитель стараешься всё автоматизировать, все процессы работы твоих сотрудников – от Jira правил до автопроверки кода и выкладки Docker-контейнеров на стенд. Но при этом теряешь контроль над самым важным элементом – кодом проекта.

ПРОЗРЕНИЕ

И тут до меня дошло: я программист, чёрт возьми! Мне больше нравится решать задачи кодом, а не людьми. Мне нравится видеть, как оживает интерфейс, как оптимизированный алгоритм работает в разы быстрее. Мне НЕ нравится объяснять в пятый раз, почему нужно не просто «добавить кнопочку» из задачи, а и предугадать к чему это добавление может привести (в том числе намёк в сторону тестов кода).

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

ВЫВОД

Карьерный рост – это не всегда движение вверх по иерархии. Иногда это движение в сторону того, что тебе действительно нравится. Хочешь управлять людьми – становись менеджером. Хочешь решать сложные технические задачи – оставайся разработчиком.

Мой совет: не гонись за должностями. Иди за тем, что приносит удовольствие. Потому что в IT можно хорошо зарабатывать и просто кодя. А спать спокойно – это вообще бесценно.