Как перейти из QA или поддержки в разработку: стратегия внутреннего трансфера

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

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

Превратите очередь тикетов в портфолио кода

Каждая роль в QA и поддержке порождает поток артефактов, которые превращаются в инженерную работу, если сделать на один шаг больше, чем требует должность.

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

Делайте так два раза в месяц в течение квартала — и у вас будет около дюжины смерженных коммитов в продакшен-репозитории. Каждый коммит можно объяснить одним предложением и привязать к конкретному влиянию на клиента.

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

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

Выбирайте первые пулл-реквесты по лёгкости ревью, а не по амбициозности. Фикс на 15 строк с тестом, который сначала падает, а потом проходит, смержится за день. Рефакторинг на 400 строк чужого кода зависнет в ревью на три недели и научит команду тому, что ревьюить вашу работу дорого. Вы строите репутацию низкотрения-мержей — именно она и зарабатывает перевод.

Просите рано и письменно

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

Поговорите, когда у вас есть два-три смерженных изменения. Этого достаточно, чтобы доказать серьёзность намерений, и достаточно рано, чтобы менеджер успел спланировать замену. Формулируйте это как запрос на путь, а не на разрешение. Например: «Я хочу перейти в разработку в команду платформы в течение следующих двух-трёх кварталов. Вот что я уже смержил. Что вам нужно увидеть, чтобы это случилось, и как выглядит закрытие моей текущей позиции?» Потом задайте тот же вопрос инженерному менеджеру той команды — в отдельном разговоре.

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

Договаривайтесь об испытательном периоде, а не только о должности

Большинство компаний оформляют это как ротацию перед постоянным переводом: 20% времени на целевой команде или фиксированный «займ» на 60–90 дней с сохранением текущего титула. Настаивайте на займе. Разделение времени означает две очереди задач, и очередь поддержки всегда побеждает, потому что именно она вам пагит.

Перед тем как соглашаться, добейтесь трёх явных договорённостей:

• Назначенный ментор и ограниченный первый проект. «Походи по команде и посмотри, как идут дела» — это способ тихо похоронить ротацию. Вам нужен измеримый результат и человек, который отвечает за ревью.
• Кто закрывает вашу старую очередь. Если никто не подхватит ваши тикеты, вы будете работать на двух работах и провалите испытательный срок по пропускной способности.
• Что происходит в случае успеха. Перевод конвертируется в постоянную позицию или вы всё равно проходите стандартный процесс?

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

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

Как выжить в первые шесть месяцев

Когда вы уже внутри, разрыв редко бывает в умении кодить. Сложнее части работы, которые были не видны снаружи: быстрое чтение незнакомого кода, оценка сроков и умение вовремя остановить расследование и спросить.

В первый месяц читайте больше, чем пишете. Выберите сервис, за который будете отвечать, и проследите один запрос от начала до конца: точка входа, обработчики, слой данных, ответ. AI-редакторы здесь помогают: попросить инструмент вроде Cursor объяснить цепочку вызовов и сверить его ответ с кодом — быстрее, чем слепой grep, если относиться к объяснению как к гипотезе, а не как к истине.

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

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