Что меняется, когда разработчик переходит в тимлиды

Кто я

Мой «официальный» опыт в разработке уже около 10 лет. Примерно половину этого времени я решаю менеджерские задачи — работаю тимлидом.

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

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

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

Разработка изнутри

Уверен, вы все знаете, как выглядит рабочий день разработчика. Но начнем с некоторых очевидных акцентов, чтобы было, от чего отталкиваться.

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

Когда пишу код, я всегда в так называемом «потоке». Не использую никаких специальных техник повышения производительности — ни метод помидора, ни чего-то подобного. В моем случае они бессмысленны — в этом процессе вряд ли можно что-то улучшить. Прихожу утром, сажусь за рабочее место, погружаюсь в задачу — моргнул — уже вечер. Все это время я в задаче. И так проходят все рабочие дни.

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

Режим тимлида

А вот когда ты управляешь командой разработки, все иначе. Задача менеджера — подумать о том, о чем не будут думать разработчики (потому что им и не надо об этом думать). Ты живешь в режиме многозадачности. Каждый день на повестке десятки разнородных задач — мелких и крупных. Позвонить одному, согласовать с другим, узнать статус задачи у третьего. Удержать все это в голове практически невозможно — обязательно что-нибудь забудешь, если не попытаешься зафиксировать.

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

Менеджерская текучка зачастую не уходит далеко вперед по времени, но все равно плодит сотню мелочей. А поскольку наша оперативная память ограничена, без инструментов уже никак.

Тимлиду не обойтись без календаря, особенно когда периодически заводишь встречи на большое количество людей с синхронизацией удобных им слотов в расписании. А для записи своих задач я использую блокнот. Он помогает расширять список того, что ты контролируешь.

Зачем мне блокнот

Чтобы не забывать, использую самое простое решение — бумажный блокнот, в который записываю каждую таску, вне зависимости от ее срочности и размера. Это может быть задача буквально на минуту, но прежде чем сделать, я все равно ее запишу, ведь это отнимает всего 5-10 секунд. Возможно, за день накопится целая кипа таких задач, но это гарантия, что я про них не забуду.

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

Блокнот постоянно лежит на столе. Рабочий день начинается с того, что я его открываю и вспоминаю, что надо сделать сегодня, и просто подряд записываю все, что могу вспомнить. Если что-то вспоминаю позже, в течение дня, дописываю — это помогает сохранить важные вещи, которые ты не можешь сделать прямо сейчас. Я не заполняю блокнот на несколько недель — это бессмысленно. Глобальные задачи всегда отражены в Jira проекта — их надо не на листочке писать, а детали за неделю несколько раз поменяются.

После окончания работы с самим списком, я беру наиболее приоритетную задачу для выполнения. Как правило, это таска, которая дает работу наибольшему числу людей — чтобы никто не простаивал. Мне обычно сразу понятно, что надо сделать здесь и сейчас, не требуется никаких внешних инструментов приоритизации.

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

Можно ли совмещать?

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

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

Предположим, ты менеджер и вынужден бегать «галопом по Европам» между задачами, не фокусируясь ни на одной из них. Ты начинаешь писать код, а этот процесс подразумевает очень глубокое погружение в контекст. В итоге у тебя остается одна задача, а все остальные из «зоны видимости» просто вылетают. И начинаются проблемы — там не усмотрел, тут созвон проморгал, здесь ко встрече не подготовился.

Если же кодить, погружаясь не так глубоко, стараясь закончить быстрее и переключиться на другие активности, будет страдать качество кода. Пытаешься погрузиться в задачу, но тебя со всех сторон выдирают из контекста. Это выматывает.

Я понял, что у меня не работает даже популярное временное разделение режимов работы, когда утром — созвоны, вечером — решение более крупных задач. В реальной жизни подчиненным от своего начальника что-то нужно с самого раннего утра и до позднего вечера. Им можно запретить беспокоить начальство условно с 10 до 12, но даже если они будут соблюдать режим, в этот период их работа будет простаивать. Зато тимлид покодил.

Важный момент заключается в том, что с тимлида спрашивают, не как с кодера. Он не отвечает, как хорошо написан код, его сфера ответственности — как команда выполняет задачи. Если они не решаются из-за того, что тимлид решил покодить, даже высокое качество этого кода положения не исправит. Пропущенные командой сроки никак не объясняются тем, что тимлид любит Java.

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

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

Максимум кодинга, который я могу позволить себе в статусе тимлида, — это код-ревью. Я провожу его, если хорошо знаю код проекта. Обычно это так, поскольку я начинаю, как разработчик, изучаю кодовую базу, а потом перехожу в тимлиды. Соответственно, код-ревью у меня получается хорошо. Изредка бывает так, что я прихожу тимлидом на написанный кем-то проект, и тогда нормально проводить код-ревью не могу — просто нет возможности погрузиться. По трудозатратам это почти то же самое, что написать с нуля (я стараюсь ревьювить глубоко), так что приходится передавать задачу коллегам.

Все так плохо?

И что, скажете вы, все пропало? Переход в тимлиды означает потерю связи с кодом и технических знаний? Вовсе нет!

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

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

Автор: Андрей Буров, МаксилектP.S. Мы публикуем наши статьи на нескольких площадках Рунета. Подписывайтесь на нашу страницу в VK или на Telegram-канал, чтобы узнавать обо всех публикациях и других новостях компании Maxilect.