Кто такой Product Engineer? И почему эта роль набирает популярность в эпоху ИИ?

Я проработал в ИТ более 20 лет. Первую половину из них я верстал сайты, писал код, настраивал сервера, скрапил данные и даже был со-автором системы аналитики, которую купила Data.AI. Вторую половину я пробовал силы в предпринимательстве и работал в продуктовом департаменте ВКонтакте — создал и развивал Маркет ВКонтакте с MAU продукта 14 млн. А сегодня пытаюсь запустить ИТ-продукт в России. Конечно, не без помощи ИИ. Но речь не обо мне и не о моем продукте, а об изменениях которые я наблюдаю с приходом ИИ в профессиях менеджер продукта и разработчик ПО.

В нашей отрасли уже никого не удивить тем, что поменялся подход к работе. ИИ набрал популярность и проник в наши рабочие процессы. В мире по официальным данным еженедельно 5 млн. ^[1]разработчиков используют ChatGPT Codex, 11 млн. ^[2] разработчиков используют Claude Code, 8.5 млн. ^[3]используют Gemini. А по грубым подсчётам общая активная аудитория всех пользователей ChatGPT, Claude и DeepSeek достигла 1.5 млрд. человек в мире. В России по данным ВШЭ проникновение в небольших организациях составило 4.8% ^[4] и с каждым месяцем проникновение увеличивается. Проникновения среди крупных ИТ компаний выглядит на порядок выше — 71%.

На мой взгляд, одна из ярких трансформаций происходит в цикле разработки программных продуктов PDLC (The Product Development Life Cycle). Можно заметить появление на зарубежном и отечественном рынке требований и вакансий с непривычным слуху сочетанием — Продуктовый Инженер / Product Engineer. Давайте попробуем разобраться что это за роль, почему она может стать востребованной в эпоху ИИ и какими навыками необходимо обладать кандидатам.

Какие требования к Продуктовым Инженерам / Product Engineers

Если посмотреть на сайте Y Combinator и их специализированном хабе вакансии относительно роли Продуктового Инженера — 1 ^[6], 2 ^[7], 3 ^[8], то кандидат должен иметь: продуктовое мышление ^[9], навыки общения с потенциальными пользователями продукта, уметь выявлять бизнес-проблему и искать для неё решение, а также иметь технические full-stack навыки для самостоятельной реализации этого решения и его доставки до конечного пользователя.

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

Выглядит как симбиоз двух ролей, в которой слились роль инженера и роль менеджера продукта. С точки зрения ^[13] бизнеса желание понятное и не новое. Звучит многообещающе, если добавить инженеру навыков менеджера продукта, или наоборот — научить менеджера продукта писать код и делать деплой. Давайте разбираться насколько это желание осуществимо на практике. Для начала сравним процесс разработки ПО до появления ИИ и с его участием.

Классический процесс разработки программного продукта

У всего есть свой жизненный цикл — у продукта, у компании, у человека. Мы же будем сейчас говорить только про продукт. В зависимости от этапа жизненного цикла продукта перед менеджером ставятся разные цели, задачи и измеримые результаты. Так к примеру, на этапе идеи самого продукта важно пообщаться с целевой группой людей, создать прототип и быстро проверять гипотезы, чтобы найти PMF (Product Market Fit). На этапе роста важно много рассказывать о продукте на рынке, наращивать пользователей и улучшать сам продукт. А на этапе зрелости удерживать пользователей, следить за их лояльностью (NPS) и оттоком. Продукты бывают, кстати, не только коммерческие, поэтому монетизация не всегда требуется. Это я рассказываю очень сжато, быстро и грубо, конечно. Здесь важная мысль в том, что есть ответственный менеджер продукта, прямой задачей которого является запускать новые и развивать существующие продукты, иногда даже отстреливать ^[14] неудачные из них.

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

Команда с которой работает менеджер продукта зависит от масштаба нововведения. Минимальная команда включает дизайнера, разработчиков и тестировщиков. Но нужно понимать, чем крупнее нововведение, тем больше требует людей и ролей. ВКонтакте обычно мне приходилось подключать дополнительно в рабочую группу аналитиков, юристов, маркетологов, модераторов, службу поддержки, копирайтеров, PR-специалистов. А когда я запускал интеграцию ВКонтакте с Ozon у нас в рабочей группе было свыше 100 разных специалистов и руководителей. По структуре это больше напоминало кластерную структуру с зеркалированием ролей и зон ответственности. Так что с командами может быть всё очень индивидуально. Но так или иначе, команда в большей степени отвечает за реализацию продуктового замысла, который получила от менеджера продукта и за скорость этой реализации — TTM (Time-to-Market).

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

Процесс разработки программного продукта с участием ИИ

С появлением ChatGPT, Claude и других генеративных моделей процесс разработки программного продукта изменился. Абсолютно все участники цикла смогли делегировать часть своих обязанностей со-пилотам. Сегодня почти каждый менеджер продукта ^[15] и разработчик ^[16] использует так или иначе ИИ в своих рабочих процессах. Как следствие ИИ постепенно забирает себе часть наших служебных функций. В таблице ниже я по своему личному опыту ^[17] выделил несколько core-функций ролей и отметил какие из них уже перешли от человека к ИИ

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

В свежем исследовании от Stackoverflow ^[19] показано топ-5 категорий задач для которых разработчики привлекают ИИ. Среди них, как раз, генерация и рефакторинг кода, отладка, написание и улучшение тестов, а также работа с документацией.

Итак, по итогу мы получаем картину в которой обе роли отдали свои рутинные задачи искусственному интеллекту ^[20]. Он делает понятные задачи в десятки раз быстрее человека, не спит и не устает; находит закономерности там, где человеку будет сложно их найти; анализирует объемы информации с которым когнитивный аппарат человека не справляется.

Но также можно сделать вывод о том, какие функции остаются в этом случае за человеком.

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

• Во-вторых, за человеком остается ответственность. Человек проверяет результат, выбирает дату релиза, объясняет решение пользователям и исправляет инциденты.

• В-третьих, лидерство ^[21] также остаётся пока за человеком. В конечном счете он формирует повестку дня. Он защищает на условной трибуне перед другими людьми свои идеи, бюджеты и стратегию. Именно он объединяет вокруг себя других людей с которым эта стратегия будет воплощаться в жизнь.

Давайте теперь перейдем от сравнения процесса цикла разработки ПО к отраслевым сигналам и их последствиям. Это поможет нам увидеть важные мутации, чтобы понять зачем рынку нужны такие новые специалисты, как Продуктовый Инженер / Product Engineer.

Переходный период. Предпосылки больших изменений.

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

Меняются структуры команд — прямо сейчас мы видим изменения в структуре организаций. Сегодня для многих специалистов ИИ стал со-пилотом и помощником. Но есть мнение от инженеров OpenAI ^[22], что в обозримом будущем структура может претерпеть радикальные изменения. К примеру, ИИ станет полноценным коллегой. Любопытная точка зрения, поэтому не сдерживайте себя — выскажите свои мысли в комментариях.

Идет развитие автономных ИИ агентов. В этом году сильный толчок получила система скилов / SKILLS.md. Они позволяют превращать агентов в специализированных помощников, наделяя их рабочими инструкциями, памятью ^[23] и сценариями поведения ^[24]. Скорее всего дальнейшее развитие автономных ИИ-агентов приведет к тому, что со временем мы увидим автономных агентов-специалистов. Это могут быть агенты-дизайнеры, агенты-юристы, агенты-программисты, агенты-тестировщики, агенты-врачи и т.п. Признаться, я уже сегодня в своей работе использую пакет скилов ^[25] от Гарри Тана — CEO Y Combinator, который частично заменяет мне команду разработки и демонстрирует зачатки автономности.

Развиваются фреймворки для оркестрации ИИ-агентов. Сегодня уже есть CrewAI, Google ADK, OpenAI Agents SDK, Claude Agent SDK. Энтузиасты и соло-разработчики пытаются строить пайплайны и прототипы компаний будущего. А бигтех и компании по меньше уже встраивают их в свои процессы и в продукты для сопровождения документации, для работы службы поддержки, для разработки и тестирования, для рекрутинга.

Так что если что-то можно описать алгоритмами и спецификациями, то это рано или поздно имеет высокие шансы стать автономным ИИ-агентом.

Рост T-shaped и Slash специалистов. На рынке всегда был дефицит Fullstack-разработчиков, но с появлением ИИ эта проблема сокращается. Более того, сегодня всё больше появляется специалистов, которые владеют навыками из разных, даже не связанных, областей. К примеру, теперь каждый разработчик может получить дополнительные навыки: художника, бизнес-аналитика, маркетолога, юриста или копирайтера. В действительности, спектр ограничен только собственной любознательностью и целеполаганием.

Отказ от раздутых штатов. Бигтех сокращает штаты. Так Oracle, Amazon, Dell, Cisco, Atlassian ^[26] и другие в сумме уволили сотни тысяч сотрудников, объяснив это оптимизацией штата. Другими словами крупные компании как-будто всё больше теряют интерес ^[27] к специалистам, кто продолжает механически набирать код или выполняет работу, которую сегодня можно переложить на плечи ИИ. Чем-то напоминает первую промышленную революцию, когда ручной труд начал заменяться фабричным проийзводством.

Переходный период. Рождение новой роли.

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

Это будет специалист-универсал

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

Обладать ИИ-толерантностью

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

Иметь навык делегирования задач

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

Уметь договариваться

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

Видеть через призму маркетинга

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

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

Проектировать продукты, а не код

70 лет назад все писали на ассемблере. С тех пор на смену ассемблера пришел язык C и C++. Позже появился Perl, Python, а после JavaScript и PHP. На этом пути появлялись новые парадигмы создания кода, а также видоизменялась сама среда разработки (речь про IDE ). Сегодня происходят куда более радикальные изменения — IDE превращается в чат с ИИ, разработчики перекладывают ручное кодирование на агентов, поэтому первостепенной задачей современного разработчика становится мыслить не просто классами и моделями, а архитектурами и целыми продуктами.

Выводы

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

Востребованность специалистов

В первую очередь я ожидал бы спроса на таких специалистов в небольших командах и растущих ИТ-компаниях. Я говорю про стартапы. Именно там в первую очередь требуются люди, которые способны как провести разговор с потенциальными пользователями, так и набросать код чтобы собрать прототип. Полагаю скоро наши отечественные акселераторы последуют примеру Y Combinator и сформируют запрос на подобных специалистов по рынку.

Бигтеху такие люди тоже важны. Ведь несмотря на раздутый штат внутри известных нам компаний, внутри этих компаний зачастую люди сгруппированы вокруг пилотов и существующих продуктов, а не только по функциональным навыкам. К примеру, когда в 2020 году я запускал новые продукты в социальной сети — Магазин 2.0 и Маркет ВКонтакте, то у нас в команде продукта было примерно 10 человек с формально разными ролями, но вовлеченные глубоко в сам продукт. Для сравнения в то же самое время в зрелом продукте Юла было что-то около 600 специалистов.

Всё, что я хочу сказать этими сравнениями, что несмотря на размер бизнеса, потребность ^[28] в небольших кросс-функциональных командах и специалистах нужна в любом случае всем. Это всё еще дефицит на рынке.

Дефицит универсальных специалистов сохранится

Ежегодно российские учебные заведения выпускают примерно 130 000 ИТ-специалистов. При этом по данным Минцифры всё еще существует дефицит опытных кадров. Если принять во внимание ^[29], что продуктовый инженер — это T-специалист которому потребуется время на созревание, то дефицит в ближайшее время сохранится.

Развитие продуктовых навыков

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

• я бы рекомендовал в первую очередь посмотреть лекции от Яндекса ^[30] по этому направлению;

• очень рекомендую для ознакомления книгу Алекса Остервальдера “Разработка ценностных предложений” ^[31];

• дальше советую знакомиться с разными концепциями и продуктовыми фреймворками: https://gopractice.ru/ ^[32], https://productlab.ru/blog ^[33]

Желаю всем нам с легкостью проходить этапы трансформации и быть востребоваными на рынке!