Тимлидство — дорога с двусторонним движением. Я трижды становился тимлидом и дважды возвращался в разработку. Проехал все ямы на этой дороге, и каждая — это боль. Но я понял: одни ямы можно объехать, перед другими — просто притормозить.
Одна из главных болей — нехватка программирования. Невозможность просто сесть и пописать код беспокоит почти всех начинающих тимлидов. Да и опытные от этого не застрахованы. Ведь востребованность тимлида зависит от того, насколько он держит свои hard skills в тонусе.
Как найти баланс между управлением и кодом? Как не стать «менеджером-менеджером»?
Меня зовут Иван, я работаю лидом в Цифровом СИБУРе, делюсь опытом и своими мыслями.
Дисклеймер:
Если вы уже полностью в менеджменте и код для вас — это прошлое, тут вряд ли найдёте что-то новое. Но если вы всё ещё пытаетесь совмещать управление и программирование, welcome to the club. Буду рад критике и надеюсь, что кому-то станет легче (или нет).
Недостаток программирования в организме
За баланс программирования в организме отвечает кодилка. Это такой орган, которым пишут код, иначе говоря — программируют.
Где находится кодилка
Анатомически она может находиться в самых разных частях тела разработчика. Лично у меня кодилка находится по соседству с выражальником — органом, через который я самовыражаюсь в случае неординарных событий, когда рядом нет женщин и детей.
Если я не могу самовыразиться через кодилку, мне больно так же, как от невозможности изъясниться через выражальник после удара мизинчиком об угол кровати.
У обычного разработчика кодилка болит редко. Но уж когда болит — это серьёзный симптом. Если разработчик не может разрабатывать на регулярной основе, возможно, ему пора менять проект.
Для тимлида болезнь кодилки обычно хроническая. Смена проекта тут не поможет.
Когда тимлиду полдня приходится «отличаться умом и сообразительностью», а вторые полдня «программировать» в аутлуке — кодилка болит. Когда стейкхолдер прибегает с интересной задачей — она болит ещё сильнее. Хочется перестать заниматься фигнёй и вновь сделать что-то полезное своими руками.
Когда «юные падаваны» накодили что-то странное, кодилка болит так сильно, что появляется нестерпимое желание засучить рукава и переделать «как надо». Но с этой болью тимлид ещё может как-то жить.
Куда хуже страх. Страх, что кодилка атрофируется и отсохнет. Страх тимлида, что он откроет код и... ничего не сможет сделать. Страх стать ИТ-импотентом.
Типичная реакция на недостаток программирования
В этом случае частая реакция тимлида — броситься на амбразуру разработки. А это можно сделать либо в рабочее время, забив на свои прямые обязанности, либо ночью. Либо и в рабочее время, и ночью. Заканчивается это, увы, плачевно.
Если тимлид выбросит на периферию процессы — на проекте начнётся ералаш. Станет непонятно, кто чем занимается. Поставка ценности бизнесу забуксует.
Если выбросит продуктовые активности — станет непонятно, когда, зачем и для кого выполняют задачи. Люди будут грести, как рабы на галерах. Тимлид станет грести больше всех. Вопрос только — куда?
Если забьёт на взаимодействие с людьми, то люди... Люди, поглядев на сломанные процессы и бесцельность работы, начнут потихоньку уходить.
Программировать или нет?
Может показаться, что тимлиду нельзя программировать. Но это не совсем так. Программировать или нет — это выбор, который каждый делает сам.
Тимлид может и не кодить, если
он прокачан как управленец и в дальнейшем собирается строить карьеру менеджера;
на проекте есть все необходимые технические специалисты, поэтому техническая экспертиза тимлида не востребована;
он сумел построить качественные процессы, требующие минимального вмешательства;
процессы и люди обвешаны метриками — кто и как работает, можно понять, не изучая код коллег.
Также тимлид может не кодить, если он управляет командой на другом стеке.
Тимлид должен кодить, если
нужно, чтобы команда уважала его как технаря. Тогда это не только расширит его поле влияния, но и даст дополнительные инструменты управления;
требуется поддерживать остроту навыков разработки. Это может быть полезно в случае смены работы;
без него на проекте образуется нехватка технической экспертизы;
метрики не дают полной картины происходящего на проекте и в команде;
кодовая база — лучший источник знаний о том, что сделать невозможно, а что возможно и по какой цене.
Лично я считаю, что тимлид должен программировать, но строго дозированно и осознанно. Благодаря этому мнению я остаюсь востребованным специалистом.
А для того, чтобы программировать, нужны две вещи: задача и время.
Поиск задач
Брать все задачи подряд — не самая лучшая тактика. Лучше выбрать те, которые быстрее утолят жажду кодирования: позволяют написать максимум кода за минимум времени.
Задача должна
соответствовать критериям SMART. Вообще, это относится к любой задаче;
иметь выраженную ценность для навыка программирования. Например, помогать что-то вспомнить или изучить;
быть несрочной, не связанной жёсткой зависимостью с задачами коллег — нам ведь не хочется просрочить дедлайн и (или) подставить команду;
по возможности быть значимой для бизнеса.
Вот примеры из моих недавних задач:
Реализация отчёта на SQL.
Цель: попрактиковаться с оконными функциями. Задача не срочная, но важная для бизнеса: «Смотрите, какой красивый отчёт, позволяющий прогнозировать маржинальную прибыль». Для меня польза состоит в самом факте практики, ведь об оконных функциях часто спрашивают на собеседованиях. Об этой пользе я, конечно, не говорю бизнесу, но могу обсудить её со своим чаптер-лидом.Оптимизация узких мест в C#-коде.
Цель: вспомнить, как работать с профайлером, как бенчмаркать, как применять на практике советы умных людей. Задача важна для текущего проекта. Без неё он через некоторое время упадет под нагрузкой. А ещё она полезна для прокачки востребованных на рынке труда навыков: понимания работы памяти и процессора. Задачу в любой момент можно поставить на паузу. Поэтому, несмотря на наличие неопределённостей, я взял её в работу.
А вот примеры задач, которые брать не стоит:
Баги и задачи поддержки.
Они часто сводятся либо:
— к исправлению некорректных данных;
— объяснению пользователям, что «это не баг, а фича»;
— многочасовой отладке.
Ценности для развития в таких задачах немного. Доработки кода обычно незначительны. А исправление может требоваться ещё вчера.Задачи по автоматизации
Написание разных скриптов, настройка CI/CD. Это разовые операции, которые мало дают для прокачки навыка программирования. А временные затраты на них спрогнозировать трудно.
Выделение времени
Ок, задачу нашли. Теперь нужно выделить время — и сделать это так, чтобы не зафейлить основные обязанности.
Где брать время? Есть много хороших методик по тайм-менеджменту и улучшению эффективности. Но тому, кто сделал много задач, в награду достанется... ещё больше задач. Чтобы задачи для вашей кодилки имели шанс попасть в работу, нужно не только улучшать эффективность, но и проводить скоринг с приоритизацией.
Все входящие задачи я прогоняю через фильтр вопросов
В чём ценность задачи?
Что будет, если эту задачу не сделать или сделать позже?
Может ли эту задачу выполнить кто-то, кроме меня?
Если делегировать задачу, чем будет отличаться результат?
Если делать все же надо, можно ли воспользоваться принципом 80/20 и потратить только 20% времени?
Пока делаю — проверяю, не буксует ли задача, на верном ли мы пути. А вдруг пора «зафиксировать убытки» и остановить задачу, чтобы не тратить время зря.
Пропуск своих задач через этот фильтр помогает мне освободить время для кодирования.
Не призываю лениться и отфутболивать задачи — я рекомендую делать только то, что нужно, и не делать то, что не нужно. И вам, и вашей компании. Ваш «Кэп».
Рассмотрим на примерах
Технический долг: причесать код
Ценность в том, чтобы «было красиво». Но понятие красоты у всех разное. Думаю, что ценность задачи недостаточна, чтобы ей заняться. Предлагаю навести порядок ровно тогда, когда придут связанные с этим кодом требования. А до этого момента — не трогать.Бага
Если не починить, бизнес понесёт убытки. Значит, делать надо. Если отдать коллеге, работа будет выполняться чуть дольше из-за необходимости погружения в контекст и дополнительных коммуникаций. Ну ок, не страшно. Делегирую.«Реализовать годовой отчёт по… »
Ценность есть, делать надо сейчас, а разработчики загружены. Согласно принципу 80/20, предлагаю бизнесу: «Полноценную форму отчёта реализовывать долго. Давайте раз в году вам поддержка ручками сформирует отчёт в Exсel?» Получив «ок», на коленке пишу скрипт для базы, снабжаю его инструкцией, отдаю техподдержке.Переписка
Делать нужно, делегировать нельзя.
Я знаю, как нужно писать, но это занимает время. Делю коммуникации на три части:
— важные письма для начальства пишу качественно и трачу много, очень много времени;
— письма смежникам и стейкхолдерам пишу попроще, не вылизываю;
— с письмами команде вообще не парюсь: непонятно написал — спроси.
В итоге получаем рост скорости коммуникаций за счёт потери качества некритичных писем.Коллега сделал не то и не так
Со всеми бывает. Но ни в коем случае не надо перехватывать задачу и доделывать, а тем паче — переделывать. Это непедагогично. Это чертовски демотивирует человека, не исправляет корень проблемы и тратит много времени тимлида.
Я вижу такие варианты решения:
— попросить ребят в команде помочь друг другу;
— подсказать товарищу, как доделать задачу;
— сесть и программировать в паре. Увы, тут время не сэкономишь, зато это работа на перспективу.
Истинная цель
Итак, я описал свои ухищрения, чтобы программировать, будучи в роли тимлида.
Но программирование — это не цель. Цель — поддерживать свою востребованность на рынке. Именно для этого требуется выделять время.
Этично ли преследовать свои цели в рабочее время? Не знаю.
Но точно знаю, что компании часто хотят получить в штат сильного управленца, который помнит, как программировать. И загружают процессами — людьми — продуктом, не оставляя времени на техническое развитие. Ничего личного, просто бизнес.
А потом, при необходимости сменить работу, тимлида-управленца ждёт сюрприз: с неактуальными техническими компетенциями он сильно теряет в зарплате. Поэтому я работаю на опережение. Не позволяю своей технике заржаветь. Чего и вам искренне желаю.
