Всем привет! Меня зовут Иван Леонов, и я тимлид в AGIMA. А до этого долгое время был рядовым разработчиком в нашем цехе PHP. Хочу рассказать, чего ожидал от новой должности и что в итоге получил. Надеюсь, смогу кого-то вдохновить на дальнейший профессиональный рост, а кого-то — наоборот, отговорю от ненужного карьерного витка. Тут не будет прикладных советов по управлению, зато будет простая человеческая история, из которой вы сможете сделать собственные выводы.
Но для начала в двух словах о своем опыте. Лет мне уже немало, за плечами много разных IT-работ, в том числе 10 лет в IT-отделе банка. Еще я пробовал развивать свое региональное агентство, но вскоре понял, что не готов быть директором, HR-специалистом, менеджером по продажам, руководителем проектов и тимлидом одновременно.
Поэтому в какой-то момент я решил сконцентрироваться на том, что у меня хорошо получается и что я люблю — писать код. Так я попал на один из проектов компании AGIMA.
Роли в команде — кто есть кто
Проект оказался довольно крупным (по крайней мере, по моим региональным меркам): два проджект-менеджера, два тимлида, два фронтенд-разработчика, четыре бэкендера и три тестировщика. Вся команда на выкупе. Я был одним из бэков.
Процесс для меня был предельно понятным. С вопросом «Что они имели в виду?» идешь к проджекту, с вопросом «Как лучше это реализовать?» — к тимлиду. Общаешься с фронтами по особенностям интеграции, тестировщику объясняешь, как это работает «под капотом» и на что обратить внимание при проверке. Все остальное время занимаешься любимой работой. Ровно той, на которую я и шел.
Поскольку проект был большим, поначалу много времени уходило на то, чтобы разобраться, что, как и почему именно так работает. Команда мне охотно помогала и в целом оказалась исключительно дружной. Через пару недель я даже осознал, что приятно удивлен: заказчик ставил задачи четко, а все встречи с ним проходили легко и приятно. Даже поделился этой радостью с проджектом, но в ответ получил лишь загадочную улыбку.
Основное флоу разработчика
Выкупная схема оказалась очень удобной. Утро начиналось с дейлика, длился он максимум полчаса, а проходил в Google Meets. Обсуждали текущие задачи и расходились работать дальше. Время от времени приходилось созваниваться с тимлидами или QA, чтобы обсудить что-то срочное. Но такое было редко и даже приносило удовольствие — приятно было пообщаться с ребятами.
Иногда и вовсе бывали дни, когда я уже успевал закончить все задачи, а новых еще не подвезли. Тогда было время спокойно погружаться в проект дальше и разбираться в том, в чем не разобрался раньше. Так я смог лучше понять и сам проект, и процессы. И в целом вскоре уже неплохо ориентировался во всем, что происходит. И это произошло как-то плавно и ненапряжно.
Самым стрессовым был день релиза, когда какие-то мои задачи ехали в продакшен. Буквально через пару недель после того, как я подключился к проекту, уже на проде в одной из моих фич тестировщики нашли баг. Так я узнал новые для себя термины «хотфикс» и «минорный релиз». А еще с такой скоростью, как в тот день, код я не писал никогда :)
Еще через некоторое время я узнал, что такое ретроспектива. Оказалось, что это только звучит страшно. В нашем случае это было похоже на междусобойчик, на котором «без купюр» можно было высказать всё, что наболело, получить поддержку от команды и поддержать кого-то взамен. Также мы обсуждали проблемы и способы их решения. И — вот это да! — проблемы реально решались.
Что я знал о работе тимлида
Для меня было загадкой, как проходит день тимлида. Но представлял я это себе примерно так: формализуешь клиентские задачи, проводишь код-ревью и отвечаешь на глупые вопросы разработчиков. А поскольку сам я вопросы задавал редко, было ощущение, что и остальные тимлиду почти не пишут. А значит, день его проходит спокойно и гладко, даже время остается.
И поэтому я никак не мог взять в толк, почему ответа на те вопросы, которые я всё-таки доносил до него, мне иногда приходилось ждать по полдня. Явно он был чем-то занят — но чем? Конечно, я понимал, что он участвует в каких-то встречах с заказчиком, но мне представлялось, что это работа проджекта, а тимлид там нужен как бы на всякий случай — чтобы быть в курсе.
Первый опыт в роли тимлида
Со временем я полностью освоился в команде, поучаствовал в создании нескольких стратегических фич и уже сам начал помогать новичкам. Под конец второго года работы мне предложили подхватить задачи одного из тимлидов, пока тот в отпуске. Я сразу согласился: интересно было понять, из чего же состоит его день и смогу ли я потянуть его обязанности.
Тимлид передал мне список активных задач, всё объяснил и подсказал, на что обращать внимание. До прямого общения с заказчиком меня пока не допустили, но вот в таск-трекере мы уже переписывались. Тут я уже попробовал формализовывать задачи, делать код-ревью и мержить задачи в QA-ветку. Для меня тогда это было уже очень круто.
Эксперимент, как по мне, прошел успешно. Новая роль показалась привлекательной и интересной. И я стал раздумывать над тем, что мне пора брать новую высоту. А пока я размышлял, моему тимлиду предложили повышение, а мне — его место. Поэтому в конце 2022 года я получил новые функции и обязанности. И это было большое событие.
Чем оказалась работа тимлида
Пока я принимал дела, произошло еще одно событие: второго тимлида перевели на другой продукт. И вот оно — я осталися один на один с нашим проектом. Мне пришлось быстро, даже очень быстро осваивать новые навыки. И в первую очередь — умение вести переговоры, потому что количество коммуникаций у меня в жизни выросло кратно. Сейчас объясню почему.
Выше я говорил, что проект довольно большой. Но честно говоря, изначально я даже не догадывался, насколько большой. В роли разработчика я использовал какие-то интеграции со сторонними системами, но мне казалось, что это единичные случаи. Став тимлидом, я увидел нашу инфраструктуру целиком — и был немного поражен.
Кроме того, в конце 2022 года из России массово уходили зарубежные бренды. А мы на проекте использовали несколько западных систем, в том числе в критически важных областях — в CRM, в обработке заказов и т. п. Стоило мне занять новую должность, как заказчик решил начать два глобальных проекта:
первый — резервный план на случай, если зарубежные поставщики внезапно откажутся с нами работать;
второй — планомерный переход на собственные IT-продукты и отказ от высокорисковых поставщиков IT-услуг.
Поскольку мы обеспечиваем функционирование веб-сайта заказчика, в первый проект нам пришлось влететь с разбега. Он предполагал создание резервных личных кабинетов для бэк-офиса клиента на случай отказа их основной системы ведения заказов и клиентов. Второй проект предполагал планомерное написание отдельными командами замещающих продуктов и последующую интеграцию их с сайтом.
И вот тут мне пришлось в срочном порядке осваивать переговорные техники. Созвонов было безумное количество. По первому проекту мы часто созванивались с менеджерами заказчика и с представителями сторонних команд. Поскольку они тоже пилили резервные интерфейсы, нам нужно было поддерживать связь с ними. А до этого подобной коммуникации просто не было, она была не нужна. По второму проекту мы участвовали в проектировании интеграционных решений. И всё это нужно было обсуждать. При этом основной сайт должен был продолжать работать в обычном режиме, маркетинговые активности продолжались, запланированные фичи пилились.
К счастью, через месяц на проект нашли второго тимлида, и моя нагрузка уменьшилась. Тем не менее, я всё еще отлично помню те дни, когда на созвоны уходило по 6–7 часов в день. За оставшееся время нужно было формализовать задачи, которые обсуждались на созвонах, провести код-ревью и зарелизить новые фичи.
Помните загадочную улыбку проджекта, о которой я говорил в начале? Теперь-то я понял ее смысл. Не подумайте плохого: и заказчик у нас классный, и команда проекта крутая. Но поначалу я просто не представлял, какая баснословная работа стоит за той задачей, которая уже попала к нам в бэклог. А это часы обсуждений и размышлений.
Больше того, я не представлял, сколько ресурсов уходит на то, чтобы уже готовую задачу вывести в прод. Это те же переговоры, только теперь это уже согласование и убеждение. И это в нашем случае, когда заказчик понимает, чего хочет, а мы понимаем заказчика. Можно представить, что бывает на других проектах.
Чем я в итоге занимаюсь
Считается, что среди задач тимлида не только управление техническими аспектами разработки, но и управление командой. Он должен развивать сотрудников, поддерживать их моральный дух и быть главным мотором коллектива. Техлид же больше концентрируется на архитектуре, интеграциях и техническом развитии. Думаю, первое время я был больше техлидом, чем тимлидов.
И мне повезло: со мной работали толковые менеджеры, которые брали на себя большую часть «нетехнической» коммуникации с командой и с заказчиком. Мне оставалось только держать под контролем технические вопросы, в решении которых у меня к тому времени уже был хороший опыт. И эта ситуация послужила для меня очень удобным батутом. Я как бы упал в тимлидинг мягко и безопасно.
В таких тепличных условиях я и начал развивать уже софт-скиллы: выстраивать коммуникации, прислушиваться с команде, помогать разработчикам и мотивировать коллектив. Такие вещи не приходят сразу, хотя и кажутся простыми. Нужно уметь давать обратную связь, поддерживать и учить не поучая. И уже сейчас какие-то вещи мне удаются. Хотя предстоит еще многому научиться.
Становиться ли тимлидом?
Хотя эта профессия не сильно похожа на ту, которую я себе представлял, мне она показалась интересной. Я для себя определился быстро: да, тимлид — это хорошая перспектива. Если вы сейчас находитесь на распутье и думаете, что делать дальше — не сомневайтесь, пробуйте. В конце концов вернуться в разработку можно в любой момент — писать код так быстро не разучитесь.
У нас в команде есть такие примеры, когда люди, проработав какое-то время тимлидами, возвращались на позиции сеньор-инженеров. И все они согласны в одном: рады, что попробовали. Без такого решения в прошлом они бы не поняли, чего хотят от себя и от своей работы в будущем. Так что советую рискнуть.
И напоследок: вообще-то расти будет комфортнее в дружелюбном и профессиональном коллективе. К счастью, у нас как раз такой. Так что приходите в AGIMA работать и развиваться. У нас всё для этого есть.
Что еще почитать
Как стать тимлидом, или Что вас ждет по другую сторону разработки?
Быть или не быть начальником. 3 вопроса, которые я не задал себе, прежде чем пойти на повышение
Как управлять командой разработки
