Я работаю тимлидом уже несколько лет и с уверенностью могу сказать, что это направление развития мне очень нравится. А помню, я чуть не запорол свою карьеру тимлида в самом начале, на переходном этапе разработчик - тимлид. Я тогда работал разработчиком в большой компании и, в общем, работа мне нравилась. У нашей команды был номинальный тимлид - хороший, душевный человек, которому очень нравилось ковыряться в своих железках, а в жизни команды его участие ограничивалось только вопросами на дейлике “как дела?”. В общем, проблемы в команде копились, и никто ими не занимался, и меня это беспокоило. В итоге мне предложили попробовать себя тимлидом. Я эту историю рассказываю к тому, что я начинал свой путь с огромным воодушевлением, но уже через 3-4 месяца я почти выгорел и хотел вернуться в разработку или вообще уволиться. Поразмыслив тогда, я решил, что не могу так бесславно уйти и должен попытаться разобраться в ситуации и найти другое решение. Я сформулировал 4 основные причины такого быстрого выгорания, которое случилось со мной на этом переходном этапе. Мне удалось найти решение этих возникших трудностей и продолжить работу.
Итак, четыре проблемы начинающего тимлида:
#1 По-прежнему пытаться выполнять роль разработчика
Когда разработчик становится тимлидом, это значит, что в вашей команде теперь на одного разработчика меньше. Это ключевой момент, который нужно четко уяснить в своей голове, а также обязательно обсудить с бизнесом. Тимлиды могут по-разному относиться к написанию кода: кто-то пишет много кода (играющий тренер, хотя я не разделяю этот подход), кто-то пишет немного, а кто-то вообще не пишет. Но, в любом случае, большая часть ваших обязанностей уже не связана непосредственно с разработкой. Понятно, что кодить хочется, потому что мы все-таки технические специалисты. Но вы больше не должны брать на себя задачи из разработки, у которых есть жесткий дедлайн. Когда у вас есть свободное время от основных обязанностей (уже теперь лидовых), можно кодить техдолг, баги, архитектуру на перспективу, еще что-то, у чего нет ограничения по времени выполнения. Дело в том, что ваш рабочий день становится непредсказуемым: можно просидеть весь день на звонках, на аварийных ситуациях и т.д. Если вы будете брать на себя разработку, настанет время, когда вы завалите дедлайн, или команда фактически останется без лида, потому что вы будете только кодить, как раньше. У меня хватило ума брать на себя не так много задач, как когда я был разработчиком, но все равно я не успевал и мне приходилось много перерабатывать, чтобы закрывать задачи вовремя, что в результате привело к усталости. Сейчас я вообще не беру бизнесовые задачи, не пытаюсь замещать разработчиков и т.д., все задачи планируются исходя из текущего ресурса разработчиков. Кстати говоря, в проекте начинаешь находить много вещей, которые можно покодить, но на которые не обращаешь внимание, будучи заваленным бизнес задачами.
#2 Думать, что ты ничего полезного не делаешь
Когда я только начал работать тимлидом, я стал замечать, что бывают дни, когда вообще непонятно, а что, собственно, я сделал за день. Начинаешь анализировать, понимаешь, что весь день проторчал непонятно где, и занимался непонятно чем. Т.е. в конце рабочего дня нет ощутимого результата. И меня эта мысль очень беспокоила, мне казалось, что я ничего не делаю или делаю, но бесполезные вещи. Когда пишешь код, все просто: результат твоей работы очевиден. В общем, нужно просто принять идею о том, что у вас не всегда будет ощутимый результат проделанной работы в конце рабочего дня или даже недели. И это нормально. Результат вашей работы отразится на команде и продукте в целом лишь спустя некоторое время.
#3 Не заниматься планированием
Как только вы становитесь тимлидом, вы начинаете взаимодействовать с бОльшим количеством других участников, которым всем что-то нужно от вас. Это нормально, потому что, как правило, тимлид - это входная точка в команду, и все пойдут с вопросами именно к нему. Я помню свои первые недели в роли тимлида. Для меня было открытием, сколько ещё людей вместе со мной работает на проекте. Я бегал, как ужаленный, чтобы помочь всем с их вопросами и проблемами, но все равно не успевал обработать за день все “входящие заявки”, а помимо этого у меня копились дела моих непосредственных обязанностей в команде.
Решить эту проблему мне помогло осознание того, что мне теперь нужно планировать свое время. А 99% вопросов, которые стекаются ко мне, не требуют немедленного ответа.
Я завел себе отдельную доску для своих дел, входящих вопросов, мыслей и т.д. Это, своего рода, личный бэклог, с которым я работаю, регулярно чищу и приоритезирую.
Что я веду своем бэклоге:
-
Список дел. Этот список у меня представлен в виде простой канбан доски: сделать, в работе, готово.
-
Входящие вопросы - это просто список карточек, которые отсортированы по дате создания. Еще эту колонку я называю “distractions list” - список отвлечений. Когда ко мне приходят с каким-то вопросом или просьбой, если я сейчас занят, то копирую целиком сообщение в карточку, а собеседнику отвечаю, что посмотрю чуть позже, если это не срочно. Когда у меня появляется свободное время, я прохожусь по этому списку и решаю, что делать. Могу сразу вернуться к коллеге, который этот вопрос задал, или завести задачу в свой список дел, делегировать и т.д. Этот distractions list позволяет мне не отвлекаться на “внешние запросы” от текущих дел (я могу быть на совещании, собеседовании, проводить ревью и т.д.), но при этом не забывать, а решать эти вопросы в подходящее время и подходящими ресурсами. Кстати, у меня есть distractions book и для личных целей. Я туда записываю всякие идеи, которые то и дело всплывают у меня в голове, но которыми нет возможности заняться в текущий момент. Это очень помогает не забыть и подумать на досуге над возникшей идеей.
-
Идеи и мысли. Обычно сюда я заношу некоторые соображения, над которыми нужно будет подумать или поделиться в подходящее время, например на ретроспективе.
Это что касается дел, не привязанных ко времени. Чтобы управлять своим временем нужно вести календарь. Я выделил в своем рабочем календаре слоты под свои задачи, командные встречи и т.д. Вся моя занятость отражена в календаре. Если кто-то хочет мне назначить встречу, он просто смотрит свободные слоты в моем календаре. Личные слоты помогают мне не копить “внутренние дела”, которые касаются только меня и моих разработчиков. Сейчас у меня выделено 2 часа ежедневно на личные задачи, это 10 часов в неделю, плюс 6 часов в неделю на регулярные встречи в команде. Получается 16 часов в неделю для команды и 24 часа на “внешние” вопросы. Конечно, не всегда и не все 24 часа забиваются “внешними” встречами, но все же обычно мой календарь забит очень плотно, и без личных слотов многие вещи я бы не успевал сделать, как это было до того, как я начал вести календарь.
#4 Быть узким горлышком для команды
Когда я только начинал, то пытался контролировать всё и вся. Такой контроль выливался в переработки, стресс и т.д. Я глубоко погружался во все задачи разработчиков. Без моего аппрува никто не мог ничего сделать. В результате я много времени тратил на погружение в детали, на построение архитектуры, код-ревью и т.д. А команда была беспомощной, частенько простаивала и не развивалась. Я считал, т.к. я теперь несу ответственность, то должен все тщательно проверять и контролировать. А про делегирование задач я и слышать не хотел. При таком подходе страдают все: тимлид не может расслабиться и забывает, что такое отпуск, а разработчики перестают развиваться, начинают скучать и уходить. Особенно остро я ощутил эту проблему, когда команду нужно было расширять. Когда ты лид небольшой команды (2-3 человека), все контролировать еще получается. Но когда команда вырастает и становится 10+, ты попадаешь в аврал, потому что такой подход с гиперопекой не масштабируется. Сейчас моя главная задача - это развитие команды, которая всегда способна масштабироваться. Я больше не погружаюсь в детали задачи, если нет острой необходимости, а многие технические решения оставляю за разработчиками, что положительно сказывается на их скиллах и ответственности. В идеале, команда может работать и без лида. В книге “Делай, как в Google” это как раз очень хорошо описано. Рекомендую почитать.
Небольшой совет около этой темы:
Постарайтесь в первые 6 мес. выбрать из команды своего заместителя, который будет заменять вас в отпуске или во время болезни. Хочу отметить, что назначение заместителя ничего не имеет общего с делегированием задач. Можно делегировать любую задачу любому разработчику (например, отправить вместо себя на встречу). Заместитель должен уметь поддерживать функционирование команды в ваше отсутствие, чтобы задачи делались, а релизы выпускались. Кого поставить заместителем, решать вам, посоветую только не забывать синхронизировать ваши отпуска.
Собственно, и все. Решение этих проблем позволило мне перестроиться на новую роль и начать развиваться в этом направлении в спокойном рабочем режиме.
//Upd. Спасибо @Metotron0за исправления ошибок в тексте.
Автор: Алексей Рожков
