Привет, Хабр! Меня зовут Павлова Наталия, я выпускница курса «Мидл Python-разработчик» и свежеиспеченный Python Team Lead в финтех-компании: руковожу небольшой бэкенд-командой.

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

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

Радужные ожидания и суровая реальность

Лидом я стала 4 месяца назад случайно: мне предложили эту позицию, хотя я собеседовалась на Middle Python Developer’а. Конечно, я радостно ухватилась за такую возможность, так как хотела прийти к менеджерской роли — правда, года через три. Моё становление как разработчика происходило в ламповой уютной небольшой компании, и мне хотелось понять, как IT устроено «у больших дядь».  

Ожидания были радужные. Работа в корпорате означала для меня учёбу на практике. Там есть опытный CTO, у которого можно поучиться и разработке, и управлению, есть состоявшийся и давно существующий бизнес. Ещё я договорилась, что половину рабочего времени буду писать код. Что могло пойти не так?

Реальность оказалась полной противоположностью. Команды, которую я должна тимлидить, не обнаружилось. Онбординга не было, и меня как будто бы бросили в море — плыви или тони. Состоявшийся бизнес обслуживал регулярно падающий легаси-код без документации, тестов, ci/cd и прочего привычного блэкджека. 

Бизнес был активный, быстрорастущий и не особо ценящий сотрудников. 10—12 часов каждый день я проводила на созвонах, а ночью периодически мне звонили какие-то люди и требовали что-то починить. Для примера: я неделю не могла получить доступ на сервера, так как никто не мог сказать, какие сервера использует бэкенд. 

Я не ушла на первой же неделе из-за коллеги-рекрутера, который меня в это заманил. Он терпеливо слушал моё нытье, поддерживал и подбадривал меня.

Мой типичный рабочий день

Я стараюсь начинать в 8 утра: час я трачу на чтение IT-литературы или просмотр образовательного видео. Сочетаю с кофе. Держу все мессенджеры закрытыми — это условие надо обязательно соблюдать, иначе не выйдет никакой учёбы. Моё самое спокойное и любимое время дня.

Через час я открываю Skype, и дальше всё как в тумане. Рабочий день превращается в непрерывный поток встреч, диалогов, анализа задач, код-ревью, ответов на вопросы бизнеса и смежных IT-команд, управления спринтами, интервью новых кандидатов, релизов, предупреждений бизнеса о релизах, работу с инцидентами, отбивание попыток быстро задеплоить задачу в пятницу или сделать задачу "на 15 минут" сверх спринта. 

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

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

Плюсы работы тимлидом

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

Я не считаю себя крутым разработчиком, и тимлид я совсем зелёный, поэтому мне постоянно приходится искать Best Practices: как рефакторить, как деплоить, как оценивать, как спроектировать, и ещё много «как». Мозги кипят — и вот это мне очень нравится.

Второй плюс заключается в эффекте низкой базы. Вначале был хаос и полтора землекопа. Через 3 месяца моей работы появилась команда из пяти разработчиков, тесты, на 10% покрывающие кодовую базу. Также появились адекватно сформулированные задачи в Jira, логирование, какая-то документация, тестовые сервера, код-ревью, релиз-ноутсы. Количество инцидентов заметно уменьшилось. 

Сейчас ребятам, которые присоединяются к команде, гораздо легче, чем было мне: они быстрее и менее болезненно проходят онбординг. Время и усилия потрачены явно не зря. Такая ретроспектива даёт энергию на то, чтобы продолжать, даёт и уверенность в себе.

Если бы я могла вернуться в прошлое

Сейчас я понимаю, что надо было не стесняться на интервью и задавать CTO больше неудобных вопросов. 

• Как устроен онбординг? Кто меня будет через него проводить? Сколько времени в среднем уходит у новых сотрудников, чтобы во всём-всём-всём разобраться и начать контрибьютить? Как часто сотрудники на позициях моего уровня созваниваются со своим менеджером и с другими менеджерами?

• Как происходит деплой задач? Есть ли тесты? Сколько задач вне спринта было сделано в предыдущий спринт? Есть ли дежурства и оплачиваемые ли они? Сколько инцидентов было за предыдущий месяц? 

Может, наниматель и не сможет (или не захочет) ответить честно на эти вопросы, но по тому, как он будет отвечать, можно сделать какие-то выводы.

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

Я надеюсь, что мой опыт кому-то поможет реальнее смотреть на работу тимлидом и лишний раз задуматься: стоит ли принимать заманчивый оффер и идти в тимлиды сейчас, или лучше уделить ещё время разработке. Этот выбор сильно сложнее, чем кажется.