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

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

Загадочным контактом оказался американец, который открывал офис в моем городе и набирал команду. Интервью было не одно, а три, и все с коллегами из Америки. На техническом этапе мне показали программу на C++: попросили объяснить, как она работает, и внести небольшую доработку. Справился я лучше, чем ожидали от студента, и меня взяли на работу. Формально — в отдельной локальной компании, а по сути — в Macnica Americas, американском подразделении японской Macnica. Там я провел практически восемь лет.

Сначала я был разработчиком: писал на Node.js и C++ для устройства, которое передает 4K-видео по IP-сетям (в своей финальной форме это модуль MPA1000). Года через четыре мне стало тесно в коде, и я вызвался навести порядок в требованиях и добрал себе «бейджик» бизнес-аналитика. Первое время совмещал новое направление с разработкой, а потом полностью ушел в аналитику и управление проектом — с командировками на демо и воркшопами от Японии до Канады.

Летом 2022 года наш директор вернулся в Америку, я принял его дела, возглавив наше подразделение из 20 человек. Вместе с руководством компании организовал переезд команды в Грузию. В 2024 году мы доработали продукт до стабильной версии, и глава моей жизни под названием «работа на американскую компанию» закончилась.

Скучал я недолго: коллеги позвали в проект, где мы делали ИИ-агента для написания кода — по сути, это аналог сегодняшнего OpenCode. Роль у меня была необычная: не менеджер и не разработчик, а скорее методолог. Я руками исследовал, как строить разработку с помощью ИИ: где он силен, где врет, как его промптить, как собирать цепочки и оркестрацию агентов. Было интересно, но в мою жизнь снова вмешался случай: бывший коллега устроился в YADRO, оценил размах проектов и четкость процессов и предложил мне попробоваться на вакансию руководителя. И я попробовал!

Коллега, который позвал меня в YADRO, работал в направлении RISC-V, и сначала я откликнулся на роль руководителя в эту команду. Оказалось, для этой роли нужен сильный технический бэкграунд именно в разработке процессоров. Но рекрутер предложила мне попробоваться в другое направление — телеком, и я согласился.

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

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

Первое — традиционный скрининг с HR-специалистом.

На втором несколько опытных руководителей в телекоме оценивали мои управленческие навыки, в том числе через решение кейсов. Кейсы, в целом, классические: «Два тимлида месяц воюют из-за архитектурного решения, команды разделились на лагеря, сроки едут, и каждый по-своему прав. Как разруливать?». Или «За две недели до релиза выясняется, что ключевая фича не успевает, а команда предлагает срезать тестирование. Что выберешь?» Конечно, правильных ответов на такие вопросы нет и быть не может: оценивают ход мыслей, скорость реакции и широту опыта.

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

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

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

Погружаться в предметную область я начал уже в рамках онбординга — стал интенсивно осваивать дивный новый мир 5G Core буквально с нуля.

В целом, онбординг я могу поделить на три части:

• адаптация как руководителя;
• погружение в телеком-матчасть;
• погружение в процессы компании: для этого в YADRO есть подробные гайды на все случаи жизни.

Расскажу про каждый из них.

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

Далее у нас были еженедельные 1:1 с руководителем: на них я мог уточнять все, что было непонятно. Помню, что вопросов по процессам у меня было немного, большинство сложностей вызывали различные аббревиатуры — TGM, TPdM, OAM, NMS, BS. Я постоянно слышал их на встречах, но не понимал, о чем идет речь. Выписывал, чтобы уточнять значения. Скоро у меня появился целый словарь таких сокращений, а через полгода я уже перестал в него заглядывать — сам постоянно использовал эти сокращения.

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

Контекста требовалось много, так как мне передавали сразу две команды. Одна делает непосредственно компонент 5G Core — SMF, вторая занимается common-частью: инструментами для других разработчиков — от логгеров и трейсинга до фильтров. Приходилось изучать оба мира параллельно: какие задачи и цели у сотрудников, сильные стороны и т. д.

Еще один «культурный шок», который меня ждал в телекоме, — это «нестандартный» набор ролей в команде. Классическая продуктовая команда в IT: бэкенд- и фронтенд-разработчики, тестировщики, один-два DevOps-специалиста, возможно, «встроенный» в команду ИБ-специалист. Владелец продукта, или Product Manager, бизнес-аналитик, который общается с заказчиком, в некоторых конфигурациях — техлид.

В YADRO же к «классическому» набору прибавляется еще несколько ролей. Добавлю, что в департаменте проектирования и разработки пакетного ядра сети, в который входит мой отдел, работают 20 команд (от 4 до 10 сотрудников).

У каждой команды есть свой Agile Team Leader — человек, который держит процессы в тонусе и помогает команде самоорганизовываться. Внутри команды — это про понятный ритм работы и прозрачность, на стыке со смежными командами — про ясность, кто именно и что конкретно делает.

Еще есть продакты, и их сразу несколько:

• Business Product Manager живет в мире заказчиков: общается с ними, выясняет боли, согласовывает ожидания.
• Technical Product Manager живут (да-да, он не один) в мире инженеров: вместе с архитекторами и лидами команд превращают ожидания заказчиков в роадмап разработки.

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

Весь испытательный срок я опирался на чек-лист новичка (про него я расскажу чуть ниже). В нем было четко прописано, что мне стоило сделать, получить, изучить. В списке были и ссылки на видеоматериалы внутреннего курса по телекому на корпоративной платформе для обучения. Смотрел их несколько месяцев параллельно с основными задачами: изучал поколения связи, 5G Core, SMF, разбирался в архитектуре, спецификациях, разбирал компоненты, которыми занимается моя команда.

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

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

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

На время онбординга в YADRO мне выдали чек-лист новичка — это список задач со всеми необходимыми ссылками на ближайшие три месяца. Перечень немаленький (там около 80 пунктов), но ты быстро понимаешь, насколько это удобно. Когда идешь по чек-листу, весь миллион вопросов, который у тебя есть на старте, сокращается с каждой закрытым пунктом.

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

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

Я работаю руководителем отдела в YADRO уже полтора года. Внутри дивизиона Телеком эта роль называется Team Group Manager, тот самый TGM из моего словаря сокращений. В моих командах сейчас более 30 человек, и в первую очередь я несу ответственность за их результат и помогаю им достигать поставленных целей. Главный мой инструмент — работа с людьми и процессами.

Я оцениваю эффективность работы команды, выстраиваю процессы, где их нет, провожу командные встречи и 1:1, нанимаю сотрудников и интегрирую их в команду. Знаю сильные и слабые стороны каждого сотрудника, его карьерные цели и то, как он к ним идет.

Например, хочет инженер стать архитектором, но никто, кроме него, об этом не догадывается. В итоге к этой цели он может идти неоптимальным путем (а может, и не идти к ней совсем). В компании мы рассматриваем лида как наставника, поэтому на 1:1 с сотрудниками часто обсуждаем их профессиональные цели, прорабатываем план, как к ним прийти. Иногда даже «приходится» немного побыть психологом и «повытаскивать» из человека амбиции, о которых он по какой-то причине не решился сказать прямо.

Ты делаешь шаг на ступеньку выше, когда полезен не только в команде, но и в рамках всего департамента.

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

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

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

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

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