Карьерный путь инженера часто представляют как лестницу, хотя на деле это холмистый трек с элементами полосы препятствий. Каждая «неровность» в итоге может стать трамплином на новый уровень — к той самой работе мечты. О том, как вписываться в карьерные повороты, рассказал Алексей Нелюбов, старший консультант по гибким методам разработки в дивизионе Телеком YADRO. Он начал с работы эникейщиком — чинил ПК и чайники, а сейчас Алексей сопровождает процессы нескольких групп тестирования GSM-решения.
- как понять, что вам пора менять направление внутри профессии
- как переходить между разными сферами и не «обнулять» предыдущий опыт
- почему даже нерелевантная, на первый взгляд, работа может пригодиться в будущем
- какие навыки можно переносить между разными ролями и индустриями
- чем занимается Agile Team Leader в телекоме
Закладываем карьерную базу: курсы, выбор вуза и первая подработка
Мои родители верили, что за компьютерами будущее, поэтому рекомендовали развиваться в этом направлении. Пришлось отказаться от тренировок по гребле в пользу компьютерных курсов, но я не жалел — работа с ПК была мне искренне интересна.
На курсы я ходил с восьмого по одиннадцатый классы: мы изучали «компьютерную грамотность», Pascal, операционные системы типа MS-DOS, веб-дизайн. Как раз тогда стали выходить первые фреймворки типа Dreamweaver, появлялись заготовки на JavaScript для красивых анимаций.
Раз в три месяца на курсах мы сдавали проекты: это были и сайты, и программы для решения конкретной задачи. Тему ученики всегда выбирали самостоятельно — например, можно было создать веб-страницу для администрации города или сделать калькулятор для подсчета урожая.
Курсы и общение с такими же энтузиастами укрепили мой интерес к разработке. Я понял, что хочу продолжать заниматься этим в вузе.
Современным абитуриентам мой подход к выбору места обучения может показаться «легкомысленным». Друг рассказал, что его брат учился в Воронежском государственном техническом университете, а затем устроился в «компьютерную фирму» и переехал в Москву. Для меня это было достаточным маркером успеха.
Так я поступил в ВГТУ на естественно-гуманитарный факультет, выбрав специальность «Информационные системы и технологии». Мы изучали все подряд: и физику, и химию, и метрологию. Делали эмуляторы Unix и рисовали анимации в Flash Adobe. В рамках дисциплины «Телекоммуникационные информационные системы» мы изучали, как устроена связь, рисовали карту покрытия местности базовыми станциями с учетом рельефа. Тогда я думал, а где мне это пригодится? Предугадать будущее я не мог и, как мне потом поможет этот предмет, даже не догадывался.
Но я понимал полезность изучения аппаратной разработки, фронтенда и бэкенда. Мой диплом, например, был фулстек-проектом. Я создал модуль составления учебных планов для кафедры: код написал на PHP, подвязал базу данных. Само программирование не вызывало у меня отклика, ближе и интереснее было находить уязвимости программ.
Основа была заложена: я понимал, что мне интереснее делать, как искать подход к задачам и самостоятельно обучаться. Применять знания на практике я начал уже со второго курса.
Для первой подработки выбрал роль эникейщика. На ремонт мне приносили не только ПК, но и бытовую технику — чайники или утюги. Большой разницы между этой электроникой клиенты не видели. Быстро «прогуглить», в чем проблема, и уж тем более воспользоваться ИИ-ассистентом, возможности не было. Я учился разбираться в совершенно разной технике и находить причины поломок самостоятельно.
Приходилось жертвовать свободным временем, но такая работа «в полях» стала фундаментом моей дальнейшей карьеры. Задачи были неглобальными, а заработок — небольшим, но эта работа помогла мне погрузиться в контекст работы разного оборудования, разобраться в сути систем, проявить креативность в решении задач.
— Харды: искать баги, разбираться с ПК и бытовой техникой, настраивать роутеры, обжимать витую пару.
— Софты: отвечать на технические вопросы пользователей, самостоятельно находить решения нетривиальных задач, сохранять стрессоустойчивость.
Карьерный старт в техподдержке — почему это было полезно
После третьего курса я начал искать первую «серьезную» работу. Поиски были непростыми: опций для студента очного направления было немного, в основном нужны были сотрудники на полный рабочий день. В итоге я устроился на работу в техподдержку сервиса онлайн-игр Nival — ее можно было удобно совмещать с учебой.
На собеседовании пригодилась моя техническая база: я понимал, что посоветовать пользователю, если игра вылетает или медленно запускается. А лучше погрузиться в контекст и термины индустрии, важные на интервью, мне помогли друзья-геймеры.
Первые две недели я знакомился с продуктом компании и большой базой знаний, которую сотрудники Nival периодически пополняли случаями из тикетов. У меня появилось понимание, какие логи и скриншоты запросить у пользователя, когда у него что-то не работает, какую диагностику провести. С технической точки зрения я понял, как устроена архитектура онлайн-игр: что может их замедлить, как на это влияет скорость интернета или версия драйверов, а как — объем графической памяти.
В качестве «сайд-эффекта» работа в техподдержке помогла мне прокачать коммуникационные навыки и грамотность. За орфографические и пунктуационные ошибки можно было получить штраф, так что — сами понимаете — мотивация к самообучению была сильной.
Спустя несколько месяцев график в вузе поменялся, и я был готов уделять работе больше времени. Можно было перейти во вторую линию поддержки и разбираться со сложными кейсами, но я решил продолжить расти в L1.
Я заметил проблему: у нас не было фиксированных требований при наборе новичков, поэтому их уровень сильно разнился. Опытным специалистам приходилось доучивать стажеров: они отвлекались от основных задач. Чтобы это исправить, нам не хватало части регламентов и непрерывного улучшения. Этим я и занялся: составил план развития новичков и гайд по процессам, принялся их реализовывать.
Так я понял, что, если хочется карьерного роста, хороший подход — подсветить то, что стоит изменить. Но просто прийти с предложением и сказать, что так будет лучше, не получится. Порой какие-то нововведения могут казаться полезными, но по сути — убыточны. Нужно задействовать метрики, чтобы посчитать, что именно станет лучше и как. Нужен факт, а не просто ощущение.
В техподдержке я проработал 4 года: за это время я сменил сферу и переехал в другой город. Пришло осознание, что я хочу двигаться дальше — влиять на продукт и взаимодействовать с другими командами, но уже не как специалист техподдержки.
Я начал задумываться о смене направления. Программирование меня не особо привлекало, а вот поиск багов, наоборот, казался интересным. В играх я легко замечал ошибки. Оценив свои интересы, начал готовиться к переходу в тестирование.
— Харды: понимать архитектуру игр, находить в них баги, анализировать логи, выявлять системные ошибки.
— Софты: оптимизировать процессы, обучать и наставлять новичков, составлять планы развития, графики и отчеты, проводить 1−1, выстраивать работу с командой, проводить собеседования.
Переход в тестирование
Менять сферу после нескольких лет работы в той же техподдержке, решится далеко не каждый. Придется что-то осваивать с нуля, переходить на меньший грейд и зарплату. Было страшно, но я принялся готовиться к собеседованию на роль тестировщика.
Начал с систематизации знаний. Для этого повторил теорию: каковы цель и принципы тестирования, что такое black/white box testing и прочую базу. Я использовал интернет-источники, читал тематические треды в онлайн-сообществах. В итоге сумел найти работу в качестве middle QA в компании, которая занималась разработкой таск-трекера.
Работа тестировщиком привлекала разноплановостью: не надо фокусироваться исключительно на разработке, но ты все равно влияешь на жизненный цикл продукта. Можно участвовать в кросс-командном взаимодействии — собирать людей и помогать им договариваться.
Здесь мне пригодился приобретенный на прошлой работе навык самоорганизации. Процессы в новой компании были не отлажены, и я самостоятельно планировал свое время на определенные задачи — на тесты, регресс, операционку. Стратегии тестирования и тестовой модели тоже не было: приходилось тестировать «наживую». Но даже без тест-кейсов и тест-дизайна нам удавалось практически не пропускать критичных багов.
Опыт работы без документации научил меня не паниковать: что-то лучше уточнить у коллег или начать выполнять комплексную задачу небольшими шажочками, сверяясь с заказчиком задачи в правильности действий.
Так произошло с тестированием функции lazy loading, которая была для меня в новинку. Я исследовал корнер-кейсы: что будет, если увеличить или уменьшить масштаб при прокрутке? Насколько быстро можно скроллить, чтобы страничка продолжала грузиться? Из этого мы описывали ожидаемое поведение и согласовывали его с владельцем продукта и аналитиками .
— Харды: применять теорию тестирования на практике, готовить техническую документацию.
— Софты: самоорганизовываться, выстраивать индивидуальный план развития, взаимодействовать с другими командами; не останавливаться на формальном «все работает» — самые неприятные баги часто проявляются позже и в неожиданных местах.
Возвращение к наставничеству — теперь в тестировании
Через год мне пришлось сменить работу: компания покинула российский рынок. Я вернулся в игровую индустрию, но теперь уже в роли лида команды тестирования.
Мой пул задач расширился — пришлось вспоминать программирование для написания автотестов. Также вне своих обязанностей я распределял работу команды по спринтам, готовил отчеты по релизам и общался с beta-тестировщиками.
Мне не хватало структурированности в знаниях теории тестирования. Я самостоятельно восполнял пробелы, чтобы получить сертификат ISTQB. Хотелось сразу же применить новые знания на практике, но на текущем месте работы это оказалось избыточным: я написал новую политику тестирования и составил матрицу грейдов, но на процессы это никак не повлияло.
Благодаря опыту работы в техподдержке сервиса онлайн-игр у меня получалось отлавливать проблемы не только по тест-кейсам. Так, тестируя интерфейс, я также заметил проблемы с UX. Поскольку меня посчитали предвзятым, инициировал небольшой UX-тест — пользователи подтвердили мои опасения. Так я понял, что мой предыдущий опыт, который кому-то может показаться нерелевантным, позволяет шире смотреть на задачи и приносить больше пользы компании.
После игровой индустрии я смог поработать QA-лидом еще в нескольких компаниях — как в hardware-, так и в software-тестировании. Этот опыт объединил мое желание расти в развитии процессов, наставничестве и обучении.
В компании Macnica я лидировал направление тестирования web-интерфейса управления платой передачи HDMI-сигнала по сети. Тут вновь занялся налаживаем процессов с нуля и people-менеджментом. Я научился разрешать острые конфликты и доносить смыслы до подчиненных. В этом помогло внедрение регулярных 1−1 и матрицы компетенций. Полезно было и научиться работать в рамках годового релиза, когда результат виден не сразу.
На подработке, где я тестировал умные телевизоры, мне довелось обучить двух специалистов с нуля: офис-менеджера и бывалого работника НИИ. До этого тестированием они не занимались.
Этот опыт очень пригодился, когда меня пригласили вести QA Lead-курсы. Для них у меня была сильная техническая база и немалый управленческий опыт. Подготовка к курсу помогла структурировать навыки, а в каких-то местах — найти этому практическому опыту название в виде конкретных методологий.
— Харды: тестировать интерфейсы и ПО, работать с умными телевизорами, участвовать в годовых релизах.
— Софты: адаптироваться к изменениям, разрешать конфликты, внедрять матрицу компетенций, обучать с нуля, выстраивать взаимодействие с иностранными коллегами.
Адаптивность — главный навык успешного специалиста
Погружение в Agile при подготовке к QA Lead-курсам помогло при поиске новой работы. Я подтягивал методологию, и вскоре эти знания пригодились на новой роли — уже в совершенно другой сфере, телекоме.
В YADRO я занял позицию консультанта по гибким методам, он же Agile Team Leader (ATL). Изначально моя должность подразумевала построение QA-процессов — что было мне знакомо и интересно — в рамках методологии. Хотя со временем пул моих задач изменился.
Дивизион Телеком, где я работаю, живет в парадигме Enterprise Agile. Что это значит? У нас нет смешанных команд, когда, допустим, разработчики сами пишут тесты, — для этого им понадобится огромная экспертиза. Здесь большое телеком-решение делится между отдельными командами разработки и тестирования разных компонентов. Чтобы команды работали слаженно, им нужен свой фасилитатор — этим и занимается ATL.
Я работаю с восемью командами, которые занимаются автоматизированным и ручным тестированием GSM. Моя задача — синхронизировать их работу и помогать им развиваться. Сначала мы определяем зоны роста с помощью опросов в рамках процедуры inspect & adapt. Затем, опираясь на результаты, я внедряю необходимые практики и изменения: если команде не хватает адаптивности — помогаю выстроить более гибкие процессы, если не хватает времени — фокусируемся на эффективном планировании.
Получилось так, что моя текущая роль касается и менеджмента, и тестирования, но я не техлид и не тестировщик в прямом смысле. Теперь я помогаю, консультирую и организую мероприятия для внедрения позитивных изменений в работу команд.
Моя работа мне нравится тем, что я полезен и вижу результаты своих усилий — пускай и не сразу. Здесь пригодился навык работы вдолгую: улучшить удовлетворенность качеством встреч в командах — с одного балла до девяти — удалось почти за год. Для этого я самостоятельно освоил основные Agile-фреймворки, методы фасилитации и расширенные методы обратной связи. Вложенные усилия стоили того — теперь почти все проводимые митинги полезны каждому участнику.
В работе мне всегда очень помогали сообщества — когда я начинал в тестировании, я искал помощи в тематических пабликах. На работе вступал во внутренние корпоративные комьюнити, где можно обсуждать с коллегами все подряд и не бояться нарушить NDA.
У нас в YADRO много таких сообществ — например, у ATL есть свое сообщество с лидами и бэклогом. Мы поддерживаем коллег в трудные моменты, а также делимся лучшими практиками: что удалось улучшить и как.
— Харды: разбираться в архитектуре мобильной связи «в полях», применять принципы ручного и автоматизированного тестирования GSM-решений.
— Софты: работать в рамках методологий (в том числе Agile), различать Kanban и Scrum, собирать расширенную обратную связь, фасилитировать процессы.
Заключение
Моя карьера получилась далеко не линейной: я переходил между сферами (игровая индустрия → разработка ПО → телеком) и между специальностями (специалист техподдержки → тестировщик → ATL). Но, несмотря на эти изменения, каждый раз осознавал пользу предыдущего опыта. Компетенции и умения, которые казались случайными и несвязанными, в итоге начинали работать вместе. Опыт из одной работы неожиданно помогал решать задачи в другой, а старые, казалось бы, ненужные знания — применялись. По итогу всё — обжим витой пары, составление карты покрытия базовыми станциями и обучение новичков — оказалось не зря.
Начиная с курсов по Pascal и веб-разработке, я даже не мог представить, что буду задействован в тестировании и игр, и базовых станций. Но, если бы я не попробовал, вряд ли узнал, что у меня это хорошо получается и что мне это действительно интересно.
