Продуктовый инженер — это не продакт, который научился кодить

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

Тогда я пошёл смотреть, что этим названием уже называют.

По-русски оказалось не пусто: например, подробная статья на DOU вышла ещё в 2019 году.¹ Но общего определения всё равно нет. Где-то product engineer — разработчик с продуктовым мышлением, где-то почти продакт с редактором кода, а в свежих текстах к нему добавляют ещё и управление агентами.

В англоязычных компаниях термин уже добрался до штатного расписания. В вакансии Senior / Staff Product Engineer Linear ждёт от инженера умения формулировать проблему, а не только реализовывать готовое решение.² У PostHog есть отдельный хендбук по роли.

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

Сначала — чем это не является

Продуктовый инженер остаётся инженером. Он пишет, читает, выкатывает и поддерживает код. Если человек иногда собирает прототип в Cursor, но его основная работа — стратегия, бюджет и согласование интересов, это по-прежнему продакт-менеджер с техническим инструментом.

С фулстеком различие другое. Full stack описывает технический охват: фронтенд, бэкенд, иногда инфраструктуру. Product engineer описывает не набор технологий, а участок работы, за который человек отвечает. Можно дойти от React до PostgreSQL и всё равно остановиться на закрытом тикете.

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

Разница — в единице ответственности

Если совсем коротко, продуктовый инженер — это software engineer, в чью работу входит продуктовый результат, а не только технический артефакт.

Это не значит, что обычному software engineer безразличны пользователи. Инженер может отвечать за надёжность сервиса, дежурить по нему годами и знать бизнес лучше половины компании. Различие не в добросовестности человека, а в договоре роли.

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

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

PostHog формулирует контраст жёстче: software engineers «владеют» написанным кодом, а product engineers — продуктом и его успехами и провалами.³ Это определение конкретной компании, не отраслевой стандарт, но единицу ответственности оно показывает хорошо.

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

Роль старше ИИ. ИИ только сделал её заметнее

Product engineer не появился вместе с ChatGPT. О разработчиках, которые участвуют в выборе продукта и следят за его результатом после релиза, писали задолго до нынешней волны генерации. В 2019 году Gergely Orosz называл их product-minded engineers: они хотят понимать, почему принимаются решения, как люди пользуются продуктом и что показывают данные.⁴

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

ИИ не придумал эту роль. Он усилил экономику в её пользу.

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

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

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

Где он стоит относительно агентов

У Кифа Морриса есть полезная рамка про место человека в цикле разработки с агентами.⁵

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

Человек внутри цикла. Он проверяет каждый артефакт и каждую строчку. Контроль честный, но скорость упирается в человеческое внимание.

Человек над циклом — у Морриса это on the loop. Вместо ручного исправления каждого результата человек меняет механизм, который этот результат производит: спецификации, проверки и правила работы. Эту обвязку Моррис называет harness, а практику её построения — Harness Engineering.

Само положение on the loop ещё не делает человека продуктовым инженером. Так может работать платформенный инженер, архитектор или специалист по безопасности. Разница начинается в том, какие решения человек зашивает в harness.

Что считать правильным поведением пользователя? Какой отказ допустим? Когда система должна повторить попытку, а когда честно остановиться? Какая задержка терпима именно в этом сценарии? Это уже не свойства кода сами по себе. Здесь инженер переводит продуктовое решение в исполняемое ограничение.

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

Что он делает руками

Формулирует проблему и спецификацию

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

В мире генерации особенно хорошо видно старое правило: то, что не сформулировали, агент восстановит по наиболее правдоподобному варианту. Иногда угадает. Иногда получится дорогая почти-правда.

Пишет и выпускает код

Руки из реализации никуда не исчезают. Product engineer собирает прототип, меняет систему, разбирает сбои, выкатывает и откатывает изменения. Он может делегировать агенту большую часть набора кода, но не делегирует решение о том, что именно можно выпускать.

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

Определяет способ проверки

Каждое существенное требование должно иметь пример, на котором оно ломается. Иначе это пожелание, а не ограничение.

Для обычной логики это тесты, контракты, мониторинг и проверка полного пользовательского пути. Агент, который пишет обычный CRUD, ничего здесь не меняет: код сгенерирован, а проверяется он теми же тестами, что и раньше. С ИИ-функциями сложнее: один и тот же запрос может дать разные, но одинаково приемлемые ответы, поэтому сравнить результат с единственным правильным значением не получится.

Здесь и нужны evals — сокращение от evaluations, то есть оценки. Берём набор типичных и специально сложных запросов, заранее описываем, что считать хорошим и плохим ответом, а затем прогоняем через него каждую новую версию. Часть критериев проверяет код, часть — человек или другая модель. В результате вместо ощущения «кажется, стало лучше» появляется повторяемая проверка, на которой видно и улучшения, и регрессии.

Владеть evals в одиночку product engineer не обязан. ML-инженер или дата-сайентист лучше построит статистику и инфраструктуру оценки, доменный эксперт заметит содержательную ошибку, поддержка принесёт реальные сбои. Критерий успеха должен задавать человек, который понимает предметную область и пользователей. В минимальной схеме оценки Hamel Husain и Shreya Shankar прямо предлагают выбрать одного такого domain expert как человека, принимающего решение о качестве.⁶

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

Держит путь пользователя целиком

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

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

Смотрит, что произошло после релиза

Сколько людей дошло до результата? Где ушли? Стали ли возвращаться? Во что обошёлся один успешный сценарий? Без этого фраза «пользователь решил задачу» остаётся мнением.

Именно здесь продуктовая ответственность отличается от расширенного чек-листа перед merge. После релиза работа не заканчивается, а получает данные, которых до релиза не существовало.

Роль существует только вместе с полномочиями

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

Организационно ближе всего здесь stream-aligned team из Team Topologies: стабильная команда отвечает за поток изменений до живой системы и пользователя без передачи работы другой команде.⁷

В той же рамке ориентир для стабильной команды — 5–9 человек, а не магические три или четыре. Размер сам по себе ничего не гарантирует. Важнее, помещается ли участок продукта в коллективную голову команды и может ли она довести изменение до результата без очереди из согласований.

Полномочия, без которых роль не складывается:

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

Если ответственность выдали, а этих полномочий нет, новая должность ничего не меняет. Меняется только число встреч — вот оно растёт стабильно.

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

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

Продуктовая ответственность при этом не обязана упираться во внешнего пользователя с кредиткой. У платформенной команды пользователи тоже есть, просто они сидят этажом ниже. Её работа заканчивается там же, где у продуктовой, — на результате: другие команды стали выкатывать быстрее и перестали спотыкаться о документацию. В Team Topologies это сказано прямо: платформенная команда считает остальные команды разработки своими клиентами и ведёт платформу как продукт.⁸

Чего это стоит

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

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

Третья — риск стать неглубоким во всём. Продуктовая ширина работает, пока у человека остаётся инженерная вертикаль, по которой он способен отличить правдоподобное решение от правильного.

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

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

Как понять, что название уже про тебя

Не по стеку и не по числу созвонов.

Ты считаешь задачу законченной после merge — или после того, как увидел её результат у пользователя?

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

Если выяснилось, что фича не нужна, у тебя есть право остановить работу — или остаётся только аккуратно реализовать её?

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

Название не главное

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

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

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

Источники

1. Product engineering — способ повысить свою ценность как инженера, DOU, 2019 — «Product Engineer — понятие, которое наряду с software engineer все чаще встречается как на Западе, так и у нас». ↩

2. Senior / Staff Product Engineer, Linear — «Comfortable working without heavy PM overhead; you can help to shape the problem, not just implement a solution». ↩

3. Product engineer vs software engineer, PostHog — «Product engineers […] “own” the product and are responsible for its successes and failures». ↩

4. The Product-Minded Software Engineer, Gergely Orosz — «They want to understand why decisions are made, how people use the product, and love to be involved in making product decisions». ↩

5. Humans and Agents in Software Engineering Loops, Kief Morris — «The collection of specifications, quality checks, and workflow guidance that control different levels of loops inside the how loop is the agent’s harness». ↩

6. LLM Evals: Everything You Need to Know, Hamel Husain и Shreya Shankar — «Use one domain expert who understands your users as your quality decision maker». ↩

7. Team Interaction Modeling with Team Topologies — «A key aspect of Stream-aligned teams is that they have end-to-end responsibility for a flow of change to the live services/systems, with no hand-offs to other teams»; команда определяется как «a stable group of 5 to 9 people working towards a shared goal as a unit». ↩

8. What are the core team types in Team Topologies? — «they see other development teams as their customers effectively. They run the platform as a product or service». ↩