Как тимлиду провести первый год в незнакомой среде

Дарья Корчуганова

Ведущий разработчик Управления реализации бизнес-решений и обеспечения контроля качества внедрений

Привет! Я фронтенд-разработчик и бывший тимлид дашборд-команды Газпромбанка (сейчас снова работаю разработчиком, но уже в другой команде). Расскажу про первый год работы тимлидом: что важно в этой работе и с какими трудностями можно столкнуться.

И при чём тут мемы.

Как стать тимлидом

Сперва разберёмся, кто такой тимлид. Это — руководитель группы одной компетенции, например, фронтенд-разработчиков или аналитиков.

Обязанностей у тимлида много и, как правило, они разные от компании к компании. Но в целом их можно описать так: тимлид отвечает за то, чтобы команда была достаточно компетентной для работы над проектом, выполняла все поставленные перед ней задачи и не разваливалась. А её члены не конфликтовали между собой и не выгорали.

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

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

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

Скорее всего, сыграло и то, что у меня прокаченные софт скилы. Разработчики — обычно интровертные ребята, а я тесно контактировала с аналитиками и бизнесом, помогала команде с инструментами типа Jira. К тому же не ленилась: меня можно было смело отправить на какое-нибудь совещание по поводу той или иной фичи, потому что могу без проблем объяснить одну и ту же вещь аналитикам на человеческом языке, а разработчикам — на техническом.

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

Ещё через полгода мне сначала «мягко» предложили взять ответственность за команду (отпочковывался подпроект — на планшеты — и на него нужен был тимлид). Я ушла в отпуск, взяла время подумать. Но после узнала, что меня назначили лидом — и думать уже не надо.

Тут надо оговориться, что бывший тимлид — крайне проницательный человек, который понял, что я испугалась нового опыта, но была к нему готова как специалист. И решил взять инициативу в свои руки и отправить меня в команду. Притом всё равно был рядом. И в случае чего помогал с задачами и давал советы.

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

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

Как выстраивать процессы

Прекрасно работает метод научного тыка:

• делаешь что-то;
• понимаешь, что не получается;
• откатываешься до точки, где всё начало идти не так;
• анализируешь, что пошло не так;
• ищешь способ сделать лучше;
• пробуешь снова;
• запоминаешь успешный кейс и идёшь дальше.

Таким образом, ты нарабатываешь нормальный — и что немаловажно, вариативный — алгоритм работы. И учишься разруливать те или иные ситуации.

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

Это похоже на отлавливание багов. Встречаем баг, ищем причины, думаем, как исправить, и прикладываем подорожник (синяя изолента — тоже вариант).

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

Как стать хорошим руководителем

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

Самым сложным было погрузиться в организаторские активности. Я понимала, какую атмосферу хочу создать в команде: чтобы у разработчиков было достаточно свободы и никто не ходил за ними с бесконечным «А когда будет готово?», но при этом я оставалась авторитетом и человеком, к которому можно обратиться за помощью — а не подружкой, которая ничего не решит. Но не знала, как к этому прийти — потому что не хватало опыта.

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

Вот те вещи, которые позволили создать нужную атмосферу в команде.

Давать разработчикам раскрыться

У меня в команде был разработчик, который начал вязнуть в задачах, как в каком-то каучуке. При этом он говорил на дейликах, что всё нормально, и создавал видимость работы.

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

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

После этого случая ребята в команде стали мне доверять.

Вставать на сторону команды

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

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

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

Любой разработчик, аналитик, тестировщик – должен чувствовать такую защиту. И даже если приходит разъярённый менеджер, тимлид разрулит.

Помогать с кодом, если надо

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

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

Кидать мемы

В какой-то момент работы ребята в команде приуныли. Потому что банк начал думать над новым вектором развития, стало непонятно, нужна ли будет фича, которую мы разрабатываем, и так далее.

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

При этом каждую неделю жаба была новой: сегодня с французскими усиками и багетом, на следующей неделе — в сомбреро и так далее.

Кстати, на аватарке тоже стоял мем.

Как влиться в команду менеджеров

Первые два месяца мы конфликтовали с менеджером. Я — вспыльчивая, эмоциональная, экспрессивная, она — вспыльчивая, эмоциональная, экспрессивная. В итоге начали делить зону влияния.

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

Даже если у тимлида прямо сейчас не получается выкатить идеальный продукт, он должен прийти к менеджеру и предупредить об этом. И предложить варианты решения проблем.

Что точно нужно, чтобы стать тимлидом

В конце обозначу два ключевых для тимлида скила.

Говорить. Снова «словами через рот»

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

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

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

Задать вопросы

В управлении идея «помолчи — за умного сойдёшь» не работает. Все мы можем чего-то не знать, особенно в начале работы, и лучше попросить помощи, чем тыкать самостоятельно, создавая косяки на пустом месте. При этом задавать вопросы нужно грамотно. Если спросишь, где находится кнопка А в Jira, а через три дня благополучно забудешь и пойдёшь снова её искать, то просто достанешь коллег.

Это умение помогает и в планировании задач. В моей практике были случаи, когда прибегал менеджер и рассказывал, что не спал всю ночь, потому что увидел такую-то фичу в приложении другого банка — и теперь обязан внедрить её у нас. Пара хорошо заданных вопросов, например, «Зачем нам копировать чужие фичи?», освобождала от ненужной работы.

Также важно быть готовым к критике. И принимать её с позиции: поняли, приняли, записали и поправили.