Как фронтендеру стать тимлидом кросс-функциональной команды

Нужно выучить бэкенд.

Ладно-ладно, все немного не так, поэтому давайте знакомиться. Меня зовут Илья, я техлид в Авито Авто.

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

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

Так как остальные 5 разделов с технологиями особо не связаны и одинаково легко сложно закрываются как бэкендером, так и фронтендером, предлагаю сконцентрироваться на блоке «Техническая экспертиза». Отмечу пункт, который кажется для меня принципиально важным: «Техническая экспертиза на уровне Е5-разработчика». В Авито обязательным требованием для перехода в менеджерский трек является нахождение на инженерном грейде E5+, то есть ты должен быть сеньором.

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

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

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

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

Тут все очевидно: контрибьютишь в бэк, помогаешь тестировать задачи. Как итог – начинаешь понимать, что же делают ребята по ту сторону API.

Очередной пункт, который позволяет попробовать на себе роль тимлида на минималках. Дело в том, что в задачи руководителя входит развитие его сотрудников: помощь в составлении индивидуальных планов развития, выборе задач. Чем младше грейд сотрудника, тем больше помощи ему потребуется.

Какой общий вывод можно сделать?

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

Так, стоп! А где связь-то? Вроде начинали про фронт-бэк, а по итогу большая часть пунктов с этим не связана.

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

Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.