У меня есть две книги, которые сформировали моё понимание продукта: Inspired Марти Кагана и Gestão de Produtos Жоки Торреса, у которого мне ещё повезло побыть на менторстве. Годами эти две книги были моей картой: что такое PM, что такое product designer, что такое инженер, кто что делает. У каждой роли чёткий контур.
За последний год, глядя, как моя команда работает с ИИ в Prolog, я начал чувствовать, как эти контуры расплываются. Не то чтобы книги стали неправы: просто слой, на котором происходит каждая роль, поднялся выше.
В первом тексте серии я рассказал о том дискомфорте, который заставил меня начать перестраивать tech в Prolog, а во втором, что такое harness, инфраструктура, благодаря которой ИИ выдаёт результат. В конце первого я обещал раскрыть отдельную часть: как меняется работа каждой должности, когда строит уже ИИ. Об этом и пойдёт речь.
Работа не исчезает, она поднимается на слой выше
ИИ не стирает роль каждой профессии, он меняет слой, на котором она происходит.
Лёгкое прочтение, то, что продаёт страх, звучит так: «ИИ заменит должность X», но я видел не это. Я видел, как содержание работы меняет место: то, что раньше было делать, стало направлять и критиковать того, кто делает.
Инженер, который писал код, теперь проверяет то, что написал agent. PM, который писал spec, теперь оценивает прототип, вышедший из неё за считаные часы. Человек тот же, изменился инструмент у него в руках.
Когда я вернулся к Кагану и Жоке с этим в голове, всё сложилось иначе. Оба они аккуратно описывают исполнение каждой роли (конкретную задачу, результат, то, что выходит из твоих рук к концу дня), и именно это забирает ИИ. Человеку остаётся другая половина: решать, что стоит строить, находить дыру в том, что построено, иметь вкус, чтобы понимать, что хорошо. Суждение, а не исполнение.
Поэтому я сделаю то же, что сделал для себя: возьму определение каждой роли из книг и спрошу, что из него съедает ИИ и что остаётся (и становится дороже).
Команда из троих, по книгам
Прежде чем разбирать роль за ролью, стоит вспомнить, как книги собирают команду. Жока прямолинеен: успешный продукт должен быть желанным, жизнеспособным и осуществимым, и это задаёт «три функции, необходимые для создания успешного продукта» (гл. 2): UX-дизайнер, продуктовый менеджмент и разработчик, троица, которую он называет core team. Каган в Inspired описывает те же роли в открывающей главе, «Key Roles and Responsibilities».
Оба настаивают на мысли, к которой я вернусь в конце: это не отношения начальника и подчинённого. По словам Жоки, «продуктовая инженерия, продуктовый менеджмент и UX, это одна команда, между этими группами нет отношений подчинения» (гл. 31), а у Кагана та же мысль звучит так: PM и инженерия, это «равные, ни одна позиция не подчинена другой» (гл. 5, в моём переводе). И когда ИИ входит в середину этой троицы, именно это партнёрство меняется по форме сильнее всего.
Таблица: каждая профессия в tech поднимается на слой выше. Инженерия из производителя кода становится критиком агента; продукт, из spec writer архитектором итерации; дизайн, из производителя экранов дирижёром эксперимента; качество, из тестировщика строителем валидации.
Роль каждой профессии в tech
Та же роль, на слой выше
исполнение уходит к агенту · суждение остаётся у тебя: решать, критиковать, иметь вкус
Инженер: от производителя кода к критику агента
Для инженерии важно уже не то, сколько кода ты производишь: важно, насколько хорошо ты критикуешь то, что произвёл agent.
Определение Жоки настолько ясное, что сейчас его больно перечитывать: «продуктовая инженерия отвечает за разработку продукта и поддержание его в работе», и дальше, инженерия «строит продукт» (гл. 31). Строить, вот был глагол. Каган дополняет с другой стороны, говоря об отношениях с продуктом: «product manager отвечает за определение решения, но команда инженерии лучше знает, что возможно, и именно она в итоге это решение доставляет» (гл. 5, в моём переводе). Определять с одной стороны, доставлять с другой.
Теперь доставку первой версии делает agent. Что не изменилось и стало дороже, так это всё, что Каган приписывал инженеру как источник инноваций: «инженеры лучше всех знают, что возможно» (гл. 5). Знать, что возможно, находить дыру в плане, который предложил agent, видеть trade-off по производительности или безопасности, который он не видит, решать, когда вмешаться, а когда дать идти своим ходом. Это с каждым месяцем весит больше. Синтаксис по памяти, boilerplate руками, прочёсывание Stack Overflow, объём кода как личный трофей: это весит меньше.
В Prolog я сказал это команде прямым текстом: никого не будут оценивать по строкам кода. Тот, кто всегда был хорош в «поиске дыр», становится ценнее, а тому, кто отождествлял себя с «быстро произвести много кода», придётся перекалибровать, во что вкладываться. И это не принижает инженерию. Её ценность всегда была больше в том, чтобы понимать, что годится, чем в том, чтобы быстро производить, и теперь это просто становится явным.
PM: от spec-writer к архитектору итерации
PM чувствует это, когда прототип становится дешёвым: его работа перестаёт быть написанием документа и становится выбором, какая идея достойна времени команды.
Каган категоричен насчёт сердца работы: «кто-то должен обнаружить, каким будет решение, продукт, включая функциональность, пользовательский опыт и критерии запуска. Этот кто-то, это product manager, и эта задача, сердце его работы» (гл. 1, в моём переводе). Жока даёт широкий контур: продуктовый менеджмент, это «функция, отвечающая за все аспекты программного продукта на протяжении всего его жизненного цикла, от замысла до конца жизни» (гл. 2).
Заметь, что у обоих ключевое слово, это обнаружить, а не специфицировать. У Кагана есть целая глава, где он отстаивает, что работа, это discovery, а не «требования»: у софта две стадии, «обнаружить, что строить (правильный продукт), и строить (продукт правильным образом). В первой правит discovery, вторая, это исполнение» (гл. 12, в моём переводе). Это всегда было его посланием, а ИИ просто сделал его буквальным.
Потому что когда build схлопывается с недель до часов, узким местом перестаёт быть стройка и становится решение, что стоит строить. Длинный spec, вычитанный комитетом, закрытый квартальный планинг, статус-репорт как результат, диспетчеризация трафика между инженерией и дизайном: всё это весит меньше. Больше весит быстрый discovery (прототипировать, чтобы понять, а не специфицировать, чтобы построить), курирование гипотез (какая идея достойна времени команды) и решение, чего не делать, всё чаще. Некоторые компании уже называют такого PM «Редактором» или «Архитектором». Это не меньше PM: это другой PM, тот, кто курирует, кто решает со вкусом, кто задаёт направление. То, что было центральным в старом варианте, написание spec, как раз и стало лёгким.
Product designer: от производителя экранов к дирижёру эксперимента
В дизайне единица работы уходит от экрана к системе, которая производит экраны, и product designer начинает выбирать, какая вариация выживет.
У Жоки определение UX, это понять, чтобы спроектировать: «UX отвечает за глубокое понимание пользователя и проблемы, которую хочется для этого пользователя решить» (гл. 32). А поток, который он описывает, это ритуал, знакомый всем: бумажный прототип, потом wireframe, потом «визуальный UX-дизайнер начинает добавлять цвет и форму этим экранам». Каган делит роль надвое по той же логике: interaction designer «вырабатывает глубокое понимание пользователей и создаёт задачи, навигацию и поток», раскладывает это в wireframes и передаёт visual designer, который «наращивает мясо на wireframe» (гл. 4, в моём переводе).
Эта цепочка, понять, набросать, доводить экран за экраном, это как раз то, что ИИ укорачивает. Единица работы перестаёт быть «экраном» и становится «системой, которая генерирует экраны». Пять раз переделывать одну и ту же вариацию в Figma, специфицировать компонент за компонентом, pixel-perfect handoff как обряд: весит меньше. Прототипировать на скорости итерации (несколько вариантов параллельно, плохие выбрасываешь), задавать визуальную систему вместо каждого отдельного экрана и быстрая визуальная критика (увидеть, как ИИ что-то предлагает, и с ходу заметить, что это неверно, раньше, чем заметит пользователь): весит больше.
И здесь Каган ещё в 2008 году говорит вещь, которая защищает product designer от мысли, будто он превратился в нажимателя кнопок: его работа никогда не была только про красиво нарисовать. «Хороший продукт требует хорошего пользовательского опыта. А хороший опыт требует тесного сотрудничества продукта и дизайна» (гл. 4, в моём переводе). ИИ генерирует вариацию, а тот, кто решает, какая из них достойна дойти до пользователя, по-прежнему человек со вкусом.
QA: от тестировщика к строителю валидации
QA, это самый интересный случай, потому что это роль, которую книги почти не выделяли, и именно её ИИ трогает сильнее всего.
Заметь: в троице Жоки (дизайнер, PM, разработчик) и в ролях Кагана качество появляется размытым, как ответственность команды, а не как отдельное кресло со своим методом. Долго это имело смысл, но теперь уже нет, и причина простая: если agent строит быстро, а валидация остаётся ручной, ты просто произвёл технический долг на высокой скорости.
Тогда QA перестаёт быть тем, кто прогоняет тест-кейс руками, и становится тем, кто проектирует testing harness, систему, которая тестирует систему: настроить ИИ, чтобы он писал тесты для кода, который написал другой ИИ, ловить регрессию раньше пользователя, думать, где обычно появляется дефект. На практике это стало операционным вопросом, который мы приняли: каждый баг, который проскользнул, превращается в «как нам в следующий раз поймать это автоматически?». Исчерпывающее ручное тестирование известного потока, регрессия, прогоняемая руками к каждому релизу, QA как единственные ворота перед выкаткой: весит меньше. Валидация как система, а не как пас в конце конвейера.
Это роль, которая поднимается на слой выше сильнее всех именно потому, что была определена меньше всех. Там, где книги не вбили контур, ИИ рисует новый.
Константа: то, что книги и так называли самым важным
Есть одна вещь, которая не меняется, и она пряталась у всех на виду в обеих книгах: то, что они называют самой важной чертой, это ровно то, чего ИИ не делает.
Жока открывает главу о чертах хорошего PM без обиняков: «самая важная из всех, без всякого сомнения, это эмпатия» (гл. 4). Это не таблица функций и не результат: это способность встать на место того, кто пользуется. Каган со своей стороны тратит всю книгу на защиту discovery, taste и суждения выше процесса, и оба, каждый по-своему, говорили одно и то же: то, что отличает хорошего от среднего, никогда не было механической частью работы.
А механическая часть, это как раз то, что ушло к агенту. Написать spec, нарисовать экран, написать код, прогнать тест. Осталось, и стало дороже, критическое мышление, taste (понимать, что хорошо), суждение в условиях неоднозначности, любопытство, забота о том, кто пользуется тем, что ты делаешь. Если свести к фразе, которую я сказал команде: содержание работы меняется, человек, который делает, нет.
Двухслойная диаграмма. Сверху то, что осталось у нас и стало дороже: taste (понимать, что хорошо), суждение в условиях неоднозначности, эмпатия к тому, кто пользуется, решать, чего не делать, то, что книги и так называли самым важным. Работа поднялась на слой выше. Снизу то, что ушло к агенту: написать spec, нарисовать экран, написать код, прогнать ручной тест.
Осталось у нас · и стало дороже
то, что книги и так называли самым важным
работа поднялась на слой выше
Ушло к агенту
Чего это будет стоить (без клише)
Не хочу закрывать это слишком красиво, потому что красиво не выходит. Эта перемена требует конкретных вещей, и ни одна из них не комфортна.
Первое, это оставить позади привычки, копившиеся десятилетие. Тот, кто пять, десять лет живёт по-старому, несёт в себе паттерны, которые помогли добраться сюда, и именно эти паттерны мешают меняться. Короткого пути нет, и дискомфорт ожидаем.
Дальше, критиковать ИИ ровно столько же, сколько создавать вместе с ним: принять появившуюся подсказку, это не работа; найти дыру в плане, который он предложил, это работа. То, что всегда было дорого (критическое мышление, taste, суждение), становится дороже.
Есть ещё ошибаться командой, а не человеком. Мы не увольняем инженера за баг в продакшене, мы улучшаем review, а когда ошибается ИИ, мы укрепляем harness. Баг агента, это процесс, а не человек: обязательство, а не лозунг.
И самое неприятное: принять, что одни функции меняются сильнее других. Это создаёт дискомфорт у тех, кто до сих пор изменился мало, и делать вид, что всё по-прежнему, не выйдет. Что можно сделать, так это вынести это в открытый разговор.
И чтобы не звучать как человек, который уже дошёл: Prolog всё ещё в начале этого пути. Мы пока в режиме AI-assisted, с приростом на 10, 20%, а не в AI-first на 5x или 10x. Я рассказываю о направлении, которое мы строим, с попаданиями и с промахами, а не о победе.
Что я из этого выношу
Книги не стали неправы. Они описывали исполнение каждой роли с точностью, которую я по-настоящему понял только сейчас (написать spec, нарисовать экран, построить продукт, прогнать тест), и это исполнение теперь за агентом. А человеку осталась другая часть, судить, критиковать, иметь вкус, заботиться о том, кто пользуется, и это, возвращаясь к Кагану и Жоке, ровно то, что они с первой страницы называли самым важным.
Может, в этом и есть хорошая часть: работа, которую ИИ забрал у нас из рук, была самой рутинной, а то, что он оставил, всегда было самым трудным и самым интересным. Буду и дальше рассказывать, как идёт.
Источники
- Марти Каган, Inspired: How to Create Products Customers Love (1-е издание, 2008). Определения ролей взяты из глав 1 (Key Roles and Responsibilities), 4 (Product Management vs. Design), 5 (Product Management vs. Engineering) и 12 (Product Discovery). Переводы цитат мои.
- Жока Торрес, Gestão de produtos: Como aumentar as chances de sucesso do seu software (Casa do Código). Определения взяты из глав 2 (O que é gestão de produtos de software?), 4 (Principais características de um gestor de produtos), 31 (Engenharia de produtos e gestão de produtos) и 32 (UX e gestão de produtos).
- Прочтение о том, что роль поднимается на слой выше, опирает всю серию: OpenAI, Harness Engineering, и Питер Панг, CTO CREAO.