Можно ли из тестирования перейти в разработку да еще и стать лидом? Можно. Но в моем случае всё началось не с решения сменить профессию или получить новую должность. Сначала появилось новое направление, в развитии которого мне захотелось участвовать. Затем — возможность влиять на решения и брать на себя всё больше ответственности. А уже вместе с ней постепенно выросла и моя роль.

Привет, Хабр! Меня зовут Алина Сычёва, я около трех лет работаю в МТС Линк. В компанию я пришла на позицию middle QA, а сейчас руковожу одной из команд разработки. В этой статье я расскажу, как работа с релизами локальной версии продукта оказалась для меня школой лидерства, какие навыки из тестирования пригодились в новой роли и чему пришлось учиться после перехода.

Нулевая точка отсчета

У меня не было озарения: «Все, теперь хочу руководить разработчиками». Рост был постепенным. Вместе с новыми задачами появлялась и новая ответственность, а готовность к ней формировалась постепенно — через новые навыки, понимание процессов и опыт управления ими.

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

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

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

Постепенно к основному продукту «МТС Линк Вебинары» добавлялись другие части системы: чаты, доски и другие новые сервисы. Число зависимостей росло, а это усложняло каждый следующий релиз.

Каждый релиз как первый

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

Мы объединили разрозненные релизы продуктов в единый процесс. Этот процесс пересмотрели, буквально под лупой, вникая в каждую деталь. Затем описали достигнутые договоренности и новый согласованный порядок работы в базе знаний.

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

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

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

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

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

Сначала появилась ответственность, потом должность

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

Чтобы двигаться дальше, мне требовалась более широкая зона ответственности. Такая возможность появилась, когда вырос спрос на локальные продукты, а работа коробочного направления потребовала от руководителей больше внимания.

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

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

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

Какие навыки из QA помогли в новой роли

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

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

Работа команды — тоже система, в которой каждый человек вносит свой вклад. Нужно понимать, как решение одного участника отразится на работе другого, какие последствия возникнут позже и где локальное изменение может повлиять на общий результат.

Умение задавать вопросы. Тестировщикам свойственна здоровая дотошность: желание добраться до причины, разобраться, почему решение устроено именно так, и проверить исходные предположения. Этот навык хорошо переносится и в работу тимлида. 

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

Управление рисками. В QA работа часто приходится на этап, когда времени уже мало. Приходится искать баланс между сроками, качеством и глубиной проверки. Протестировать все возможные сценарии в каждом релизе нельзя: при таком подходе ни один выпуск не доберется до пользователей.

У тимлида похожая задача. В разработке неизбежно появляются внеплановые запросы, а при планировании приходится сопоставлять их с текущими обязательствами и приоритетами. Опыт тестировщика помог мне принимать такие решения, не пытаясь охватить все одновременно.

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

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

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

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

Пришлось наращивать техническую экспертизу

Конечно, не всё было легко. Самым очевидным пробелом после перехода стала техническая экспертиза. Было бы странно ожидать, что я сразу окажусь на одном уровне с разработчиками, которые годами работали в своей сфере. При переходе я особенно переживала о том, как быстро смогу освоиться в новой технической области, и первое время действительно было непросто.

Значительная часть обучения происходила прямо в работе. На ежедневных встречах я уточняла у коллег то, что раньше могло пройти мимо меня: почему мы используем именно такой подход, откуда появилась зависимость, как устроена конкретная часть системы и какие у нее ограничения. Иногда приходилось честно говорить: «Я не поняла, давайте еще раз».

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

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

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

Ситуации, в которых я чего-то не знаю, по-прежнему возникают. Здесь важнее не изображать всезнание, а быть готовой разобраться.

Еще один навык, который я продолжаю развивать, — способность не проверять все самостоятельно. Для тестировщика внимание к деталям и стремление ничего не пропустить естественны. В роли тимлида та же привычка превращается в микроменеджмент. 

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

Один человек не может сделать все сам, именно поэтому ему нужна команда. Не стоит приучать сотрудников к тому, что без руководителя решение не может быть принято. 

Задача лидера — это как раз выстроить систему, в которой его постоянное вмешательство не требуется. Я все еще учусь находить этот баланс.

Стоит ли QA идти в тимлиды

Человеку, который рассматривает похожий переход, я бы сначала предложила честно ответить на вопрос: ему действительно интересно работать с людьми или новая роль просто кажется следующей ступенью карьеры?

Тимлид не просто тестировщик с бо́льшей ответственностью и несколькими сотрудниками в подчинении. Фокус работы меняется. Вместо собственных задач на первый план выходят развитие других людей, работы всей команды и ее общий результат.

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

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

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

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

Что меняется в команде решения on-premise

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

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

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

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