Всем привет! Меня зовут Антон Чижов, я руковожу в MWS центром практик agile. Вместе с Александром Демидовым, директором по разработке MWS, расскажем о продуктовом инженере — новой роли, которая открывает для опытных специалистов более гибкие варианты карьерного трека.
В классических командах каждый участник развивается в своем направлении, но такой вариант подходит не всем. Специалистам в одной предметной области — например, архитектуре, разработке на Go и так далее — сложно охватить и постоянно держать в уме цели продуктов: у них не так много возможных карьерных треков. Убрать эти ограничения позволяет концепция продуктовых инженеров — специалистов, сочетающих в себе несколько технических компетенций, а также развитые продуктовые и софт скиллы.
Сегодня подробно рассмотрим эту новую роль и покажем, чем она может быть интересна, кому подходит, какие варианты развития открывает и что дает компании.
Почему классическая структура команд теряет эффективность
Привычная модель обеспечивает четкое разделение ролей и обязанностей, что действительно снижает дублирование работы, но требует постоянной координации и контроля. Это приводит к росту числа менеджеров и к проблемам на стыках этапов жизненного цикла ПО (SDLC, Software Development Life Cycle).
Именно переходы между этапами становятся основной зоной риска. Специалистам, помимо своих основных задач, приходится погружаться в бизнес-цели продукта и понимать смежные области. Например, архитектору изучать DevOps, тестировщику — аналитика, фронтендеру — бэкенд.
Как правило, это выливается в дополнительную нагрузку, которая в классической структуре команд не учитывается. Чтобы ее снять, вводятся новые роли — штат постепенно разрастается, и людям все сложнее взаимодействовать.
Кроме того, работа в командах с такими специалистами приводит к простоям (временным потерям) между этапами. Например, время ожидания между разработкой и началом тестирования напрямую влияет на общий Lead Time продукта.
Изменить этот процесс можно переходом к небольшим командам из продуктовых инженеров (микростартапам) — новой формализованной ветке развития российской ИТ-индустрии.
Переход к кросс-функциональному карьерному треку
Совершенствуя процессы разработки, мы расширили роль для Middle, Senior, Senior+ и назвали ее «продуктовый инженер». В нашем понимании это эксперт, который сочетает несколько технических компетенций и обладает развитыми софт скиллами.
Внедрение роли у нас идет по двум направлениям:
Первый путь связан с трансформацией продуктов и переходом к малым инженерным командам (МИК). Мы берем существующую архитектуру, проектируем целевое состояние и формируем новые команды вокруг него. Сервисы при этом приходится выделять более четко, потому что они не всегда построены идеально.
Второй путь — индивидуальный: любой разработчик может подать заявку на портале. Продуктовый инженер может работать и вне МИК, — это допустимо и нормально.
В MWS в этой роли работают уже несколько сотен человек. Из них более 10 специалистов закрепили переход юридически. Они заявили смежную компетенцию, прошли интервью у технических мастеров и получили новый грейд.
Даже внутри монолита роль несет пользу команде. SDLC остается тем же, но за счет смежных компетенций инженер работает заметно эффективнее. Мы это видим по цифрам. Например, если специалист подтвердил уровень сеньора и по QA, и по разработке, его метрики качества соответствует старшему уровню сразу в двух ролях.
Новая роль — основа для концепции МИК
МИК — это формат организации работы, когда небольшая группа специалистов (обычно до 10 человек) отвечает за создание, развитие и поддержку конкретного сервиса или продукта. Состав команды подбирается исходя из целевой архитектуры и набора необходимых компетенций. При этом ключевой принцип МИК — наличие критических навыков как минимум у двух человек, что снижает риск зависимости от отдельных сотрудников (bus factor).
Основные преимущества такого подхода связаны с масштабом команды: небольшой размер сокращает время поставки инкремента и упрощает управление сложностью задач.
Однако есть и обратная сторона. Универсальность неизбежно усложняет обучение специалистов, потому что им приходится одновременно удерживать фокус на нескольких направлениях и поддерживать уровень экспертизы в каждом из них. Со временем это может приводить к выравниванию навыков: глубина знаний снижается, а команда начинает тратить больше ресурсов на поддержание компетенций, чем на развитие продукта.
Поэтому продуктовый инженер — ключевая роль для формирования МИК. Он понимает смежные области и развивается как специалист широкого профиля, потому что продуктовые навыки позволяют экспериментировать. Кроме того, основные инновации происходят на стыке дисциплин, потому именно там он наиболее полезен.
Формат малых команд привлекателен и для самих специалистов. Небольшой состав требует от участников широты компетенций. Чтобы оставаться автономными и закрывать все ключевые направления, каждый осваивает смежные области. Такой подход ускоряет обмен опытом внутри группы и снижает зависимость от внешних ролей.
Примеры такого специалиста — фулстек-разработчик, совмещающий работу с фронтендом и бэком, или сеньор-бэкендер, берущий на себя роль архитектора. Такой продуктовый инженер способен спроектировать микросервис с подходом API First, понимая, как он будет взаимодействовать с внешним миром и какое место займет в продукте. А если умеет автоматизировать тестирование, он сам прогонит базовые тесты и задеплоит результат.
Благодаря совмещению навыков из разных направлений продуктовый инженер работает эффективнее специалистов с классическими выделенными ролям. Он понимает, как код будет писаться и тестироваться, поэтому может сформировать необходимые требования и предложить оптимальную архитектуру.
Итак, какой он, идеальный продуктовый инженер?
Имеет как минимум два технических навыка. Такие специалисты не боятся экспериментировать, быстрее находят рабочие решения и растут как эксперты широкого профиля. Логично, что именно они драйвят появление ключевых инноваций.
Знает свою предметную область. Даже если речь идет о микросервисе как об отдельной реализации, он оценивает его ценность для других команд.
Видит продукт целиком. Понимает, как его сервис используется другими и как он встраивается в более крупные решения.
Имеет развитые софт скиллы: умение ставить цели, понимать мотивацию, видеть сильные стороны коллег. Без этого равноправные эксперты в команде легко уходят в конфликты.
Какие варианты карьерного развития появляются
Стать продуктовым инженером можно не только из позиции сеньора. Этот путь открыт и для мидлов. Чтобы переход был прозрачным и объективным, мы используем институт технических мастеров для подтверждения второй компетенцию.
Процесс выглядит так. Инженер подает заявку на внутреннем портале, указывает дополнительную специализацию (например, DevOps) и проходит интервью. На встрече присутствуют два технических мастера, которые оценивают уровень кандидата. После этого проводится проверка знаний — фактически экзамен по новой компетенции. Если результат успешный, сотруднику присваивается роль продуктового инженера и открывается следующий грейд.
Для джунов сложнее: сначала необходимо вырасти до мидла в своей области, а затем параллельно освоить еще одну на том же уровне. Но и для них этот трек остается возможным.
Роль продуктового инженера расширяет классическую узкую специализацию (I-shape) и предлагает новый вектор роста. У него своя система грейдов, при этом уровень выше, чем у выделенных ролей. Так, мидл продуктовый инженер ценится выше, чем мидл разработчик, потому что его компетенции шире.
Например, QA-инженер может развиваться по классическому пути — до сеньора и техлида, наращивая лидерские навыки. Но появляется возможность выбрать и другое направление: освоить архитектуру или системный анализ и перейти в продуктовые инженеры.
Внутри MWS мы создаем все условия для такого развития: поддерживаем сотрудников, помогаем выбрать путь и даем возможность расти. И уже видим интерес к новой роли: коллеги стали чаще запрашивать курсы по смежным специальностям.
В целом мы сейчас в начале пути и только обкатываем новый формат, но уже видим, что он востребован внутри компании.