От новичка до тимлида: гайд по продвижению

Андрей Ефремов

Руководитель центра компетенции разработки в Центре Big Data компании МТС Диджитал

Всем доброго дня, я Андрей. В этой статье поделюсь своим опытом и расскажу о том, кто такой тимлид. Чем он занимается. Какие у него обязанности. Какими навыками нужно обладать. И как стать тимлидом.

Чем занимается тимлид

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

Обязанностей и ролей у тимлида много. Но условно их можно разделить на несколько частей.

Первая — формирование своей команды: собеседования, технический онбординг, развитие своих сотрудников.

Вторая — распределение задач между своими разработчиками. Сюда входят декомпозиция и оценка этих задач, планирование работ, соблюдение сроков проекта.

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

Наконец, тимлид выполняет роль координатора — например, между своей группой разработки и другими членами команды (тестировщиками, аналитиками, DevOps-инженерами).

В разных компаниях у тимлида могут быть разные обязанности и роли (я работал в месте, где тимлид совмещал свои обязанности с функциями техлида, архитектора и владельца продукта). Всё зависит от размера команды. Для группы от 5-7 человек точно нужен отдельный лид без дополнительных ролей.

Какие навыки нужны тимлиду

Хард скилы

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

Кроме того, он понимает смежные технические области — DevOps, тестирование, архитектуру и так далее (зависит от проекта). Хотя бы на базовом уровне. Почему это важно?

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

Софт скилы

С софт скилами сложнее. Для удобства разделим их на несколько групп.

Лидерство

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

Планирование и тайм-менеджмент

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

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

Мне для планирования нравится диаграмма Ганта. А для приоритизации — матрица Эйзенхауэра, вести которую можно в Excel. Но можно использовать Jira, Trello, Google календарь — всё зависит от личных предпочтений.

Коммуникативные навыки

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

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

Эмпатия и рациональность

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

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

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

Эти навыки особенно проявляются на one-to-one встречах, где тимлид даёт обратную связь. Эмпатичный человек зайдёт не с позиции «я начальник, ты дурак», а разберёт достижения и ошибки, попытается понять, почему сотрудник не выполняет задачи или выполняет их не так, поможет найти решение, выработать план развития.

Приведу пример из своей практики. В нашу команду пришёл новый разработчик, сильный и опытный. Я поручил ему разработать сервис. Но он не выполнил задачу в срок, объяснив проблему и сказав, что со всем разобрался и скоро закончит.

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

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

Как всё это прокачивать

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

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

У меня есть свой метод обучения, который помогает постепенно развивать самые слабые и самые важные скиллы. Я составляю личный план развития:

1. Выписываю все компетенции, которые мне нужно изучить.
2. Определяю текущий уровень владения каждой и указываю приоритетность — насколько она мне важна.
3. Описываю действия, которые нужно выполнить, чтобы освоить компетенцию.
4. Ставлю дедлайн.

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

Получается такая таблица:

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

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

Сперва нужно дорасти минимум до ведущего специалиста и начать развивать технические знания вширь: изучать архитектуру, тестирование, DevOps и так далее.

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

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

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

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

В итоге руководитель предложил мне должность тимлида (но, конечно, можно и самому обратиться к руководителю и обозначить, что для вас важно дорасти до тимлида и уточнить что для этого нужно).

Вместо вывода

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

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

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

Ещё важно учиться разговаривать и договариваться, уделять много времени софт скилам, примерять на себя множество ролей — от «играющего тренера» до медиатора в конфликтах. И всё успевать.

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

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