Переход из QA в тимлиды разработки не обязательно начинается с громкого заявления «я больше не тестировщик». У Алины Сычёвой из МТС Линк этот маршрут занял около трёх лет: она пришла в компанию middle QA, а сейчас руководит одной из команд разработки.
Историю карьерного перехода Сычёва рассказала в колонке, сообщает Habr / Карьера. Важная деталь: роль выросла не из формального переквалифицирования, а из работы с релизами локальной версии продукта, где быстро выяснилось, что тестирование — только часть большой инженерной головоломки.
После испытательного срока Сычёва заинтересовалась выпуском облачной версии продукта: как изменения доходят до рабочей веб-версии, кто принимает решения, где появляются задержки. Несколько месяцев она занималась релиз-менеджментом облака, а затем переключилась на локальную, или «коробочную», поставку. Такой вариант продукта клиент устанавливает в собственном контуре и меньше зависит от внешней инфраструктуры поставщика.
На бумаге задача выглядела почти буднично: продуктовая команда сообщает, что нужен новый выпуск, релиз-менеджер помогает его организовать. В реальности приходилось собирать вместе продукт, поддержку, разработку, QA и команды, отвечающие за разные части системы. За год выходило от двух до четырёх релизов, но точный график заранее определить было трудно: планы тестирования и состав работ формировались ближе к конкретному выпуску.
Сложность росла вместе с продуктом. К «МТС Линк Вебинарам» добавлялись чаты, доски и другие сервисы. Каждый компонент жил в своей логике, а локальная версия должна была собирать их в один поставляемый клиенту продукт. Из-за этого проблемы часто проявлялись не внутри отдельной команды, а на стыках: один сервис обновился, второй не учёл новую зависимость, поддержка принесла клиентский кейс, продукт поменял приоритеты.
Сначала команда действовала привычным способом: ближе к релизу собирала нужных людей и тушила накопившиеся вопросы. Затем процесс начали приводить в порядок. Разрозненные релизы объединили, договорённости описали в базе знаний, порядок подготовки пересмотрели по шагам. Это помогло, но не решило главную проблему: даже после улучшений подготовка одного релиза занимала полтора-два месяца.
Причина была не в том, что QA медленно тестировал. Локальная поставка оказалась точкой, где сходились интересы нескольких групп. Основная разработка шла для облачного продукта, команда локального решения интегрировала изменения и готовила сборку, поддержка приносила обратную связь от клиентов, продукт определял состав поставки. Без человека, который держит всю картину целиком, зависимости накапливались до самого конца.
Именно здесь переход из QA стал не сменой бейджа, а расширением зоны влияния. Сычёва взяла на себя планирование релизов, координацию команды поставки, взаимодействие с другими подразделениями и работу над процессом выпуска. Руководство, по её словам, дало не только возможность предлагать изменения, но и право участвовать в их внедрении. После этого ей предложили постоянную роль тимлида.
Для IT-команд в этой истории полезен не карьерный лозунг, а механика роста. QA часто видит систему шире отдельной задачи: зависимости, риски, побочные эффекты, сценарии отказа. Эти навыки хорошо переносятся в лидерскую роль, особенно там, где продукт состоит из нескольких сервисов и команд. Тимлиду тоже приходится задавать неудобные вопросы, проверять предположения и выбирать, какие риски допустимы, а какие потом дорого прилетят в продакшене.
Есть и менее романтичная часть. После перехода в лиды приходится учиться не только процессам, но и работе с людьми: распределять ответственность, помогать команде принимать решения, разговаривать о сроках и качестве без иллюзии полного контроля. Для бывшего QA это может быть непривычно: раньше можно было найти дефект и доказать его сценариями, теперь часть задач решается через договорённости, приоритеты и доверие.
Для бизнеса такой пример показывает, где часто прячется управленческий резерв. Лидер может вырасти не из самого громкого разработчика и не из человека, который заранее строил карьерный трек в менеджмент. Иногда сильный кандидат появляется там, где кто-то долго разбирал сложный процесс, видел повторяющиеся сбои и постепенно брал на себя ответственность за результат шире своей должностной инструкции.
Переход из QA в тимлиды вряд ли станет универсальной карьерной формулой: не каждому тестировщику нужно управление, и не каждой команде нужен лидер именно из QA. Но история МТС Линк хорошо подсвечивает тренд: в зрелых продуктах ценность всё чаще создают люди, которые умеют соединять разработку, качество, поддержку и продуктовые решения в одну рабочую систему. Вопрос только в том, замечают ли компании таких людей до того, как они устанут быть неформальными координаторами без полномочий.