Всем привет! Меня зовут Юлия Новикова, и мае 2025 года я стала Team Lead группы фронтенд-разработки в Ozon. В моей команде сейчас 5 разработчиков и 2 тестировщика, и мы создаём фронтенд для админок, которые управляют работой складов, распределительных центров и дарксторов. Но путь мой сюда был не самым тривиальным — до этого я была QA Lead, а не разработчиком.
А началось всё с того, что я начала думать: а что дальше? Кем я могу стать, если ещё вырасту? Вакансий руководителей тестирования, а особенно руководителей отделов тестирования, не так много, а хотелось больше влияния, больше развития. И я решила прыгнуть вбок и сменить профессию: стать тимлидом разработки. Расскажу, как это было и чего стоит ожидать тем, кто задумывается о таком же повороте.
Мой путь: смена амплуа
По образован��ю я программный инженер (окончила бакалавриат и магистратуру МГТУ им. Баумана), так что с основами разработки была знакома. В тестирование пришла в 2019 году, и за это время успела поработать с самым разным стеком и в разных компаниях и процессах: тестировала бэкенд, фронтенд, веб-приложения, WebView и десктоп. Занималась автоматизацией, нагрузкой, успела побыть QA Lead команды и до прихода в Ozon, и уже в Ozon. Обучала, занималась наймом и ростом сотрудников — в принципе, попробовала многое.
Но внутри всегда тянуло к чему-то большему. Мне нравилось не просто тестировать, а выстраивать процессы, и не только в команде тестирования, а во всех кросс-функциональных командах, работать с метриками, прорабатывать задачи от самых сырых требований до релиза на продукта. И поняла: хочу быть по ту сторону — там, где всё это создаётся, но при этом становиться разработчиком я никогда не стремилась. Мне было интереснее управление командой.
Но как? Без опыта в разработке моя кандидатура выглядела бы сомнительно. Мне нужно было превратиться из «QA Lead, который хочет в разработку» в «потенциального тимлида с уникальным бэкграундом».
Мне надо было понять, что меня выгодно выделяет для роли Team Lead в сравнении со среднестатистическим разработчиком, и оказалось, что это:
Экспертность в продукте: я знала бизнес-логику и подводные камни практически всех наших админок лучше многих разработчиков. Парадокс: админки своей будущей команды я тестировала меньше всего, но изначально мы рассматривали меня в другую команду, и в этом случае это было бы моим конкурентным п��еимуществом.
Взгляд изнутри на качество: мой опыт QA — это не просто строчка в резюме. За шесть лет работы в тестировании я поработала в разных компаниях, увидела многие процессы, многое пыталась и сама выстроить. Я всегда думаю о качестве и поэтому вижу многие корнер-кейсы на этапе презентации задачи до передачи её в разработку.
Управление командой: я уже была QA Lead, умела проводить one-to-one, ретроспективы, составлять OKR (методика постановки задач, позволяющая командам формировать измеримые цели), давать обратную связь, планировать нагрузку и развитие сотрудников.
Процессы и метрики: внедрение их, в том числе и во всём отделе.
Но был и главный «босс», которого нужно было как-то победить, — техническая экспертность в целом как фронтенд-разработчика и на уровне принятия решений. Я могла найти баг, но не всегда могла авторитетно сказать, как его правильно исправить с точки зрения архитектуры, или при обсуждении задачи сказать, какие контракты между Frontend и BFF будут более верным техническим решением. Я понимала, что без этого мою кандидатуру даже рассматривать не будут.
Тактичный захват: от багов к тестам
Я не могла просто прийти и сказать: «Хочу писать фичи». Это бы создало напряжение и недоверие, да и ещё не на сто процентов отвечало тому, чего я хотела. Вместо этого я выбрала стратегию «троянского коня» — я стала проникать в свободное время в разработку через зоны, где моя QA-экспертность могла помочь. Я дала себе срок, что через два года я хочу перейти в тимлиды (спойлер: всё случилось гораздо быстрее).
Я начала с багов. В то время в одной из команд, в которой я тестировала задачи, была очень большая нагрузка и на баги не хватало ресурсов разработки, что мне и помогло. Поэтому я смогла договориться с тимлидом команды разработки, что я в свободное время буду править баги. Это было предложение, от которого сложно было отказаться. Я стала изучать код и пытаться сама чинить баги. Я не просто их исправляла — я училась: тому, как устроен проект, как писать мерж-реквесты, как проходить ревью. Да, это происходило первое время совсем не быстро, но иначе бы эти задачи так и остались в бэклоге.
Я стала драйвером unit-тестирования. Как QA, я понимала ценность тестов, но в нашем отделе их почти не писали и не было понимания, а что конкретно нужно покрывать, и это была большая боль. Я инициировала ряд отдельных встреч с разработчиками и организовала процесс, в ходе которого мы определили, что мы будем покрывать и как.
Моими главными учителями стали DevTools и разработчики команды. Я завела правило: прежде чем задать вопрос, я должна сама попытаться найти ответ минимум 20–30 минут. Это дисциплинировало и помогало формулировать очень конкретные вопросы. Но что намного ценнее, я стала тем, кто добровольно берёт на себя боль команды и объединяет усилия для совместного поиска решений. Я начала зарабатывать себе очки для того, чтобы быть рассмотренной, но до уверенности в своих знаниях было очень далеко.
Спустя полгода после начала этого «захвата» в отделе намечалась реорганизация: три команды должны были стать четырьмя. Я не чувствовала себя на сто процентов готовой, да и моя кандидатура не рассматривалась для роли руководителя команды, рассматривались senior-разработчики. Мне не хватало знаний, и я боялась. Но понимала, что такой возможности может больше не быть. Я решилась: предложила свою кандидатуру на роль тимлида.
Решение было непростым. Мой руководитель признался позже, что ключевыми факторами стали:
«Ты уже качала технические скиллы, делала задачи на фронтенде. Ты уже была хорошим руководителем, о тебе хорошо отзывались подчинённые. У тебя было горение — желание работать и развиваться. И главное — ты поддерживала открытый диалог со мно�� и была готова меняться для новой роли».
Меня поддержали. Так начался мой переход.
Страхи, риски и первое время в новой роли
Конечно, были сомнения и страхи. Но смелым быть легче, когда нет пути назад, поэтому я, напуганная, но настроенная, пошла знакомиться с командой. В моей команде на тот момент были два сеньора, мидл, джун разработчики и тестировщик. Как они отнесутся к бывшей QA во главе? Особенно волновало мнение senior-разработчиков. Первым делом я поговорила с ними с глазу на глаз: спросила об их карьерных планах. Оказалось, ни один не метил в тимлиды — им была интереснее прокачка своей технической экспертности. Их поддержка стала ключевой — они и сейчас помогают советами по архитектуре и сложным решениям.
Первые месяцы были периодом «притирки» — классический storming, через который проходит почти любая новая команда. Мы сталкивались с недопониманием, спорили на код-ревью, сетовали на коллег на one-to-one и искали комфортный формат работы и коммуникации друг с другом. Чтобы пройти этот этап, я запустила регулярные ретроспективы раз в две недели. На них мы постепенно договорились о процессах, код-стайле, принципах коммуникации. Не всё получалось сразу, но мы справились.
Ещё я стала чаще проводить one-to-one, чтобы слышать каждого. И вот результат: за полгода никто не ушёл, более того — мы взяли двух стажёров (фронтенд и QA), и совместный наём тоже нас сплотил.
Мой QA-бэкграунд сильно повлиял на то, как мы теперь работаем. Я стала драйвером качества в команде: мы наконец-то пишем unit-тесты, увеличиваем покрытие e2e-тестов и встраиваемся с ними в процессы смежных команд. Также мне очень помогает моя любовь к метрикам, в тестировании я всегда стремилась оперировать цифрами. Не «мне кажется, тут всё плохо», а «посмотрите на график — количество багов, найденных при тестировании задачи, выросло на 15% за последний квартал, и вот в каких именно сервисах». Эта привычка оказалась моим преимуществом в роли тимлида, так как разговоры о конкретных цифрах снимают огромный пласт сопротивления и споров, потому что мы начинали опираться на общие факты, а не на мнения.
Со временем я поняла свою сильную сторону в технических дискуссиях: я не всегда знала, как сделать хорошо, но благодаря опыту тестирования я очень хорошо видела, как сделать плохо и какие корнер-кейсы у нас могут возникнуть. Я никогда не стеснялась сказать: «Мне нужно время, чтобы дать ответ на этот вопрос». Сначала я звала кого-то из разработчиков на созвоны по техническим улучшениям, чтобы услышать, какие вопросы они задают, и просила их объяснить мне выбранный путь, чтобы понять логику, и потом могла аргументировать этот путь. Сейчас я уже начала «об них думать», то есть принимать черновое решение сначала для себя, а потом спрашивать, какие минусы в нём видятся.
Параллельно я продолжила брать задачи в нашей команде, выписывала непонятные моменты, а затем целенаправленно искала информацию по ним. Ещё нашла внутренние курсы и начала их проходить, чтобы знания были более структурированными.
Как победить главного «босса» — техническую экспертность?
Я сменила внутреннюю установку. Раньше я думала: «Lead должен быть экспертом во всём», потому что я привыкла, что у меня есть ответы на вопросы моих подчинённых. Теперь я думаю: «Моя задача — чтобы в команде был эксперт по каждому вопросу и чтобы процессы были выстроены так, чтобы к его опыту можно было обратиться». Мой страх теперь не «а справлюсь ли я технически», а «правильно ли я выстроила процессы, чтобы команда могла эффективно работать». Это смещение фокуса с собственной компетенции на компетенцию команды и есть главная победа над «боссом».
Первое performance review
В Ozon ревью проводится два раза в год — весной и осенью. И осенью наступило моё первое ревью в роли Team Lead. Конечно, в моей голове был ряд вопросов: смогу ли я достойно защитить свою команду, получится ли мне презентовать точки роста для разработчиков, когда буду давать обратную связь, какой фидбэк дадут по команде в целом и по мне в частности?
Я готовилась как к экзамену: перечитала все завершённые задачи, ещё раз пересмотрела метрики команды и даже подготовила себе конспекты. Но всё прошло успешно — и калибровки, и представление оценки команде. Реакция была не той, что я боялась. Команда внимательно отнеслась к результатам, совместно с каждым мы определили, что и как будем прокачивать в новом цикле ревью.
Помимо волнения перед performance-ревью моей команды, меня преследовал ещё более глубокий страх — получить негативную оценку о себе. И этот страх был двусторонним: снизу — от команды, которая может не принять нового лидера, и сверху — от других тимлидов и руководства, которые могли усомниться в правильности своего решения.
Со стороны команды я боялась услышать:
«Она не справляется, она слишком медленно принимает технические решения».
«Она не может помочь со сложным кодом, какой от неё толк?»
«Мы потеряли сильного QA-лида и получили слабого тимлида».
Я проигрывала эти диалоги в голове, готовясь к первому ревью. Мне казалось, что маска новичка-руководителя вот-вот спадёт и все увидят самозванку, которая не тянет.
Со стороны других тимлидов, особенно бэкенда (чья работа была тесно связана с нашей), страх был иным:
«Её команда тормозит общие процессы из-за непонимания архитектуры».
«Она не может авторитетно обсуждать технические моменты, и мы теряем время».
Я боялась не только профессиональ��ой оценки, но и того, что подведу своего непосредственного руководителя, который поверил в меня и защищал мой переход перед другими.
Каково же было моё удивление, когда итог ревью оказался не только конструктивным, но и позитивным. Руководитель объявил оценку и дал фидбэк, и в нём прозвучало именно то, во что я сама пока не могла поверить.
Положительно отметили работу с процессами, которые я выстроила в команде, а также начала выстраивать с лидами бэкенда. Неожиданно было услышать, что у меня хорошая техническая база, я поняла, что страх негативной оценки часто сильнее самой оценки.
Я получила подтверждение, что команда и коллеги видят мои усилия и готовы идти навстречу, потому что я была честна с ними и с собой с самого начала.
И вот сейчас впереди нас ждёт второе ревью. Волнуюсь ли я перед ним? Да, однозначно, но уже не испытываю того страха, что был в первый раз.
Так стоит ли переходить? Мои выводы
Теперь, оглядываясь назад, я могу сказать: такой путь подойдёт не всем. Он для тех, кто:
уже смотрит в сторону большего влияния на процесс разработки продукта, а не только качества;
готов учиться и советоваться, особенно в технических вопросах;
умеет слушать команду и не боится быть новичком снова.
А вот если вам по-прежнему нравится глубина тестирования, автоматизация или методология — возможно, есть смысл расти внутри QA-вертикали. Помните, что в карьере всегда больше одного правильного варианта и пути и не обязательно работать внутри одной профессии, если хочется чего-то другого. Но и если вам нравится развиваться в одном, то продолжайте и не слушайте вредных советов с Хабра :)
Я могу уверенно сказать: без опыта руководства в тестировании мой переход был бы намного сложнее, а адаптация — гораздо болезненнее. Мои менеджерские навыки, отточенные в роли QA Lead, стали тем самым фундаментом, который позволил мне уверенно стоять на ногах, пока я наращивала недостающую техническую экспертность.
Как QA Lead, я постоянно думала о том, как улучшить наши процессы: чтобы багов было меньше, а выпуск качественного продукта — быстрее. Я уже умела анализировать узкие места и балансировать нагрузку команды между техническими улучшениями и задачами от бизнеса.
Но главное, что я поняла: переход из QA в разработку — это не предательство профессии, а тоже рост. Не потому, что это разработка, а потому, что это возможность получить иное видение процессов. Опыт тестирования — не груз, а суперсила: ты уже знаешь продукт, видишь слабые места системы и умеешь договариваться с командой.
Если решитесь: мой сокращённый чек-лист
Начинайте внутри команды. Берите мелкие задачи по разработке, разбирайте баги, читайте код.
Узнайте карьерные планы коллег. Особенно сеньоров. Без поддержки будет тяжело.
Говорите с руководством. Узнайте, возможен ли такой переход в принципе.
Не скрывайте прошлое. Ваш QA-опыт — преимущество, а не недостаток.
Будьте готовы к storming. Команде нужно время принять вас в новой роли.
Учитесь постоянно. Но теперь — в поле архитектуры и разработки.
А у вас был опыт смены роли? Делитесь в комментариях — уверена, нам есть чем поделиться!
