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

Меня зовут Любовь Молчева, я руководитель группы unit-верификации дивизиона разработки полупроводниковых продуктов YADRO. До этого вся моя карьера была связана с программной разработкой и тестированием. Перейдя в верификацию полупроводников, я обнаружила, что многие управленческие и инженерные навыки остаются нужными, а требования новой роли во многом совпадают с уже накопленным опытом. В этой статье разберу, какие навыки из software оказываются полезны в hardware, с какими сложностями сталкиваешься в первые месяцы и как выстроить погружение в новую область без ощущения, что начинаешь карьеру с нуля.

17 лет в тестировании: опыт до перехода в верификацию

В тестирование я пришла случайно. В 2007 году увидела вакансию инженера по ручному тестированию в американскую компанию Netcracker, решила попробовать и задержалась на 17 лет. Компания специализируется на создании, внедрении и сопровождении систем поддержки бизнеса (BSS) и систем операционной поддержки (OSS) телеком-операторов и интернет-провайдеров по всему миру. 

За это время я успела побыть инженером, аналитиком и руководителем отдела QA на международных проектах. Посчастливилось посмотреть страны заказчиков для организации тестирования продукта (SIT, E2E, UAT) и обучения пользователей. Проекты могли быть очень разными: от инфраструктурных систем до сервисов для пользователей — личных кабинетов, тарифных платформ и систем обслуживания клиентов.

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

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

Релизы были объемными и частыми: раз в две недели, через год стали раз в месяц. В релизы заходили как новые фичи, так и фиксы найденных проблем. Это означало постоянный цикл: стабилизация системы, исправление дефектов, тестирование новых функций. Помимо регулярных релизов, в продакшен выпускали протестированные фиксы для сломанных данных после очередного релиза и срочные функциональные фиксы. 

Команда QA состояла из русскоговорящих специалистов и коллег из Индии. В определенные периоды к работе также подключались сотрудники из Мексики. Из-за разницы во времени они работали, когда мы спали, и наоборот. Наличие команд в разных тайм-зонах обеспечивало практически непрерывный процесс тестирования. В разное время на проекте работало от 30 до 40 инженеров и аналитиков по тестированию.

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

Когда я впервые столкнулась с верификацией

Хотя я уже писала, что разнообразия в работе хватало, периодически все же появлялись мысли: «Так долго работать в одной компании — не лучшая стратегия». Нужно оставаться конкурентоспособной на рынке труда. Как говорится, бойтесь своих желаний. В 2024 году компания Netcracker ушла из России.

Один из коллег предложил отправить резюме в YADRO, о которой я тогда ничего не знала. HR-специалисты связались со мной довольно быстро и предложили вакансию, описание которой удивительным образом совпадало с моим опытом. Мне стало интересно, но редкое для меня слово «верификация» в описании позиции сразу вызвало вопросы.

Собеседование прошло очень комфортно. Меня удивило, что интервьюеры гораздо больше интересовались моим опытом работы с людьми в роли линейного руководителя, чем моими навыками технического лида. Меня приглашали на позицию лида unit-верификации RTL, и на этом этапе были сомнения в собственной компетентности.

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

На дополнительной встрече мне объяснили, что от меня не ожидают экспертных знаний в области микроархитектуры процессоров или языка Verilog. Эта часть работы остается за техническим лидом. Моя зона ответственности — работа с командой. Все то, чем я привыкла заниматься на ежедневной основе. Так в январе 2025 года я присоединилась к YADRO и стала руководителем команды unit-верификации в департаменте разработки процессорных архитектур.

Чем занимается команда unit-верификации

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

  1. Разработчики пишут RTL-код — описывают логику работы блока или отдельной функции процессора.

  2. Команда верификации проверяет, что этот код реализует нужную функциональность. Для этого используют симуляторы, автотесты и специальные тестовые сценарии.

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

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

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

Планирование релизных работ команды — классическая управленческая задача. При этом важно учитывать множество факторов: 

  • Объем работ. Сколько блоков и функций процессора входит в релиз и насколько они сложны. Не менее важна готовность документации или хотя бы архитектурного решения по фиче, чтобы избежать многочисленных переделок в процессе работы.

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

  • Срок готовности фичи со стороны RTL-разработчиков. Это нужно, чтобы верификаторы успели подготовить тестовое окружение, написать тесты, прогнать их, а также выполнить регрессионные проверки до запланированной даты релиза.

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

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

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

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

В чем разница между управлением софтом и железом 

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

Время на верификацию. В разработке CPU от 60% до 80% времени и ресурсов команды уходит не на проектирование новых фич, а на верификацию. 

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

Цена ошибки. В софте фикс можно выпустить за часы или дни. В железе ошибка в RTL-коде может привести к повторному выпуску чипа на фабрике. Это 6–12 месяцев по времени и десятки миллионов долларов. Пока вы перевыпускаете чип, конкуренты уже продают свой продукт, а ваш к моменту выхода устаревает.

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

Первые месяцы: как я погружалась в новую область

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

Больше источников и бесплатных курсов собрано в статье.

Для новых сотрудников в YADRO есть проработанный онбординг для комфортного погружения, а также индивидуальные наставники. 

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

Один из самых важных факторов успешной адаптации — команда. Поддержка чувствовалась на каждом уровне. Технический лид, инженеры объясняли мне, как устроен мир микроархитектур и unit-верификации RTL. Расшифровывали мне аббревиатуры и их логический смысл. Наиболее активно с погружением во все процессы помогал Алексей Ковалов, мой коллега и руководитель модульной верификации. Недавно он написал статью про то, как стать верификатором. 

Первые несколько месяцев стали периодом интенсивного обучения. Было ли тяжело? Конечно. На митингах я иногда понимала лишь около 10% сказанного — все остальное состояло из терминологии, аббревиатур и профессионального сленга. То еще испытание.

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

Где помог бэкграунд из программной разработки

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

Некоторые практики из софта мы начали использовать и в «железе». Например:

  • системное планирование задач, 

  • дашборды для отслеживания статуса работ,

  • анализ того, сколько времени занимают разные задачи, 

  • спринты со всем содержимым (ретро, ежедневные митинги, планирование и т. д.),

  • регулярные встречи один на один.

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

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

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

Советы тем, кто думает о переходе в верификацию

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

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

В первую очередь это:

  • инженеры по тестированию, особенно automation QA,

  • разработчики backend, embedded и системного ПО,

  • firmware-инженеры,

  • FPGA/RTL-инженеры и специалисты по цифровой схемотехнике,

  • инженеры, работавшие с телекомом, сетями, драйверами, ОС и другими сложными инфраструктурными системами.

Ниже сформулировала советы для тех, кто думает о переходе. 

Разберитесь в базовых принципах процессорной архитектуры

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

  • какие основные блоки входят в архитектуру процессора,

  • как устроены подсистемы памяти,

  • что такое RTL и на каком уровне происходит разработка,

  • какую роль в этом процессе играет верификация.

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

Поймите, как устроен процесс верификации

Важно представить себе полный цикл работы команды верификации. Обычно он выглядит так:

  1. Архитекторы и разработчики определяют новую функциональность.

  2. Она реализуется в RTL-коде.

  3. Команда верификации разрабатывает тесты и сценарии проверки.

  4. С помощью симуляторов и других инструментов проверяется корректность реализации.

Когда понятна логика этого процесса, технические детали и термины начинают восприниматься гораздо легче.

Не пугайтесь новой терминологии

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

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

Используйте предыдущий инженерный опыт

Независимо от того, из какой области приходит специалист, многие навыки оказываются полезными:

  • системное мышление,

  • понимание сложных технических систем,

  • опыт работы с инженерными процессами,

  • внимательность к деталям,

  • умение анализировать проблемы и искать причины ошибок.

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

Будьте готовым к другому темпу разработки

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

Опирайтесь на команду

При переходе в новую область ключевую роль играет команда.

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

Сильная команда и понятные процессы значительно упрощают адаптацию и позволяют быстрее почувствовать уверенность в новой роли.

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