👋 Привет, я Лёша. Пишу про продуктовый дизайн, AI в рабочих процессах, найм дизайнеров, дизайн-лидерство и финтех-продукты для развивающихся рынков. Больше материалов: Telegram | Medium | LinkedIn | Портфолио
Недавно в нашей команде продакт-менеджеру понадобился рабочий прототип dashboard-панели для демо партнёрам.
Прототип должен был показать полный пользовательский сценарий: создание аккаунта, требования безопасности при регистрации, работу с несколькими сессиями, загрузку аналитики и базовые возможности сервиса.
В привычном процессе это легко могло бы занять несколько дней: уточнение требований, описание флоу, первые макеты, ревью, правки, ещё одно ревью и подготовка версии, которую уже не стыдно показать на демо.
В этот раз процесс пошёл иначе. Мы договорились о базовом сценарии на одной встрече, после чего с помощью Claude Code за несколько часов собрали рабочий прототип. Он не был production-ready. Он не был визуально идеальным. Но он был достаточно реальным, чтобы проверить сценарий, показать идею и продолжить обсуждение уже не на уровне абстрактного описания, а вокруг работающего артефакта.
Самое интересное было даже не в скорости. Интереснее было то, кто мог продолжить работу дальше.
После консультации с юристами продакт смог самостоятельно доработать прототип. Дизайнер при этом не исчез. Разработчик не стал не нужен. Продакт не превратился в профессионального дизайнера или инженера. Но первая рабочая версия больше не обязана была проходить через всю привычную цепочку передачи ownership.
Человек, который был ближе всего к задаче, смог быстро сделать идею видимой. А команда уже после этого могла проверить сценарий, оспорить допущения, найти ограничения и поднять качество решения.
Важно не романтизировать этот пример. У прототипа были очевидные ограничения. Ему всё равно нужны были ревью, дизайн-оценка, юридическая проверка и техническая валидация. AI ускорил создание первой версии, но не отменил ownership, критику и контроль качества.
И вот это различие кажется мне ключевым. Без него “AI-enabled collaboration” быстро превращается в ситуацию, где каждый что-то генерирует, но никто не отвечает за качество.
Этот кейс хорошо показывает более широкий сдвиг: AI не просто ускоряет продуктовую работу. Он меняет то, кто может сделать первый шаг.
А это уже меняет динамику всей команды.
Старые продуктовые роли появились не просто так
В продуктовых командах долго существовало достаточно понятное разделение труда.
Продакт-менеджер отвечал за проблему, бизнес-контекст, метрики, приоритизацию и принятие продуктовых решений. Дизайнер отвечал за пользовательский опыт, сценарии, интерфейс и качество взаимодействия. Разработчик отвечал за техническое решение, архитектуру, реализацию и поддержку.
Конечно, границы никогда не были идеально чистыми. Дизайнеры всегда влияли на продуктовую стратегию. Разработчики всегда влияли на продукт через технические ограничения и возможности. Продакты всегда влияли на пользовательский опыт через приоритеты, scope и компромиссы.
Но роли всё равно существовали не просто из-за бюрократии. У каждой роли были свои инструменты, язык, зона ответственности и глубина экспертизы. Дизайнер не мог просто так зайти в кодовую базу и собрать рабочую фичу. Продакт не мог мгновенно сделать убедительный интерактивный прототип. Разработчик не всегда мог заменить глубокую работу с UX, исследованием сценариев и качеством взаимодействия.
Разделение ролей было основано на реальных разрывах в возможностях. AI начинает эти разрывы сокращать.
Продакт теперь может быстро собрать интерфейсную идею, сделать прототип, написать базовый запрос к данным или исследовать сценарий. Дизайнер может проанализировать данные, набросать product spec, сгенерировать фронтенд-код и проверить технические гипотезы. Разработчик может собрать черновой интерфейс, сгенерировать тексты, пройтись по пользовательскому сценарию и оспорить продуктовые допущения.
Это не значит, что все внезапно становятся одинаково сильны во всём. Это слишком упрощённый вывод. Ремесло всё ещё важно. Насмотренность важна. Инженерная глубина важна. Продуктовое мышление важно. Опыт важен.
Но порог входа в соседние дисциплины становится ниже. И когда этот порог снижается, меняется вопрос. Раньше команда чаще спрашивала: “Кто владеет этой частью работы?” Теперь всё чаще возникает другой вопрос: “Кто сейчас лучше всего расположен, чтобы сдвинуть задачу с места?”
В хорошей команде это создаёт скорость. В плохой — тревогу.
AI усиливает сильные команды и вскрывает слабые
Представим небольшую продуктовую команду: продакт, дизайнер и разработчик.
Теперь представим, что у всех троих появился похожий уровень дополнительной execution-силы. Все трое могут быстрее исследовать проблему, собрать прототип, проверить гипотезу, описать сценарий, сгенерировать варианты решения и зайти на территорию, которая раньше сильнее принадлежала другой роли.
Что происходит дальше? В здоровой команде это создаёт leverage. Идеи быстрее превращаются в артефакты. Обсуждение становится предметнее. Продакту не нужно ждать несколько дней, чтобы визуально объяснить мысль. Дизайнеру не нужно ждать отдельного аналитического слота, чтобы проверить базовый вопрос по данным. Разработчику не нужен идеально подготовленный макет, чтобы быстро оценить техническую разумность сценария.
Команда начинает быстрее думать через продукт, а не только говорить про продукт. Но в нездоровой команде те же самые возможности создают тревогу. Люди начинают задавать себе вопросы, которые редко произносят вслух:
-
Я всё ещё нужен?
-
Моя роль становится менее важной?
-
Кто-то теперь сможет зайти на мою территорию?
-
Как мне доказать, что мой вклад всё ещё уникален?
-
Что будет, если компания решит, что ту же работу можно делать меньшим составом?
И вот здесь начинается настоящая проблема. Люди, которые чувствуют угрозу, редко становятся более открытыми к сотрудничеству. Чаще они начинают защищаться. Дизайнер может усложнять дизайн-процесс, чтобы доказать важность дизайна. Продакт может сильнее контролировать контекст и решения, чтобы оставаться центральной точкой координации. Разработчик может прятаться за технической сложностью, чтобы защитить ownership реализации. Обычно это происходит не потому, что люди плохие. Чаще потому, что им страшно. И когда людям страшно, они начинают защищать свой стул.
Проблема музыкальных стульев
Есть детская игра — музыкальные стулья. Люди ходят вокруг стульев, пока играет музыка. Стульев всегда на один меньше, чем игроков. Когда музыка останавливается, все пытаются сесть. Кто остался без стула — выбывает.
Многие разговоры про AI внутри компаний психологически похожи на эту игру. Команда вроде бы работает как обычно. Все продолжают ходить вокруг своих задач. Музыка ещё играет. Но где-то на фоне у людей появляется мысль: что будет, когда музыка остановится?
Что если одна из ролей станет менее нужной? Что если на команду теперь достаточно двух человек вместо трёх? Что если AI обесценит именно мою часть работы?
В такой среде границы ролей становятся политическими. Люди начинают защищать не качество продукта, а важность своей позиции. Вместо вопроса “как лучше решить задачу?” появляется вопрос “как мне сделать так, чтобы без меня это не работало?”
Для продуктовой работы это опасно, потому что лучшие решения обычно появляются не внутри отдельных ролей, а между ними.
Хороший продукт редко получается из идеально изолированной работы продакта, дизайнера и разработчика. Он появляется, когда инженер думает о пользователе, дизайнер понимает бизнес-ограничения, продакт уважает ремесло, а вся команда готова пересекать границы ролей без превращения этого в борьбу за территорию.
AI делает это ещё важнее. Если больше людей могут трогать больше частей процесса, качество командного взаимодействия становится важнее, а не менее важным.
Роль становится базой, а не забором
Одна из естественных реакций на AI — начать жёстче защищать традиционные границы ролей. Дизайнеры защищают дизайн. Продакты защищают продуктовые решения. Разработчики защищают реализацию. Иногда это действительно нужно. Границы дают ясность. Ownership важен. Глубокая экспертиза важна. Команда, где все делают всё без стандартов, ответственности и ремесла, быстро превращается в хаос.
Но есть разница между ownership и территориальным поведением. Ownership говорит: “Я отвечаю за качество этой области.” Территориальное поведение говорит: “Никто другой не имеет права сюда заходить.” AI делает эту разницу намного заметнее.
Дизайнер всё ещё должен защищать качество пользовательского опыта. Но это не значит, что каждая интерфейсная идея от продакта — угроза. Продакт всё ещё должен защищать стратегическую ясность. Но это не значит, что каждое продуктовое предложение от дизайнера — scope creep. Разработчик всё ещё должен защищать техническое качество. Но это не значит, что каждый технический вопрос от дизайнера или продакта — вмешательство.
Роль не исчезает. Роль становится не забором, а базой. У тебя всё ещё есть своё ремесло, свои сильные стороны и своя глубина. Но ты больше не заперт внутри своей территории.
Как это меняет найм
Я вижу этот же сдвиг в найме. Я руковожу продуктовой дизайн-командой в финтехе, работаю вместе с продактами и разработчиками и нанимаю дизайнеров. За последний год мне стало гораздо менее интересно смотреть только на то, может ли дизайнер делать аккуратные экраны.
Это всё ещё важно. Но этого уже недостаточно. Мне важно понять, насколько человек способен выходить за пределы узкого определения дизайн-работы:
-
может ли он разобраться в бизнес-проблеме за фичей;
-
может ли он быстро собрать рабочий прототип, а не только показать статичные экраны;
-
может ли он использовать AI, чтобы проверить допущения, найти альтернативы или понять ограничения;
-
может ли он объяснить, как его дизайн-решения влияют на продуктовый результат.
Это не значит, что каждый дизайнер должен стать разработчиком, аналитиком или продактом. Но дизайнер, который умеет только делать красивые макеты, становится менее конкурентным по сравнению с дизайнером, который может с помощью AI глубже исследовать проблему, быстрее сделать идею осязаемой и лучше взаимодействовать с соседними ролями.
При этом главный сигнал не в том, что человек “использовал AI”. Это слишком слабый критерий. Сильный сигнал — когда человек использовал AI, чтобы повысить качество своего мышления.
Слабое использование AI — это украсить работу, сгенерировать больше вариантов ради вариантов или быстрее собрать то же самое. Сильное использование AI — задавать более точные вопросы, находить скрытые ограничения, сравнивать альтернативы, быстрее прототипировать и приносить в обсуждение больше полезных данных.
Здесь же становится заметно low ego. Дизайнер с низким эго — это не человек без сильной позиции. Наоборот, сильная позиция нужна. Но он способен принять, что лучшая идея может прийти от продакта, разработчика, пользовательского интервью, данных или AI-assisted exploration — и не воспринимать это как снижение собственного статуса. Такие люди, на мой взгляд, будут становиться ценнее.
Что делают команды с высоким уровнем доверия
Самыми сильными будут не те команды, где все стали универсальными солдатами, а ремесло исчезло. Сильнее будут команды, где у каждого есть глубокая базовая специализация, но достаточно доверия, чтобы заходить в соседние области, когда это помогает продукту.
Для этого нужны несколько принципов.
1. Делать ownership явным, но не территориальным
Кто-то всё равно должен отвечать за продуктовое направление, качество дизайна и технические решения. Но ответственность не должна запрещать вклад со стороны других людей. Правильный вопрос не “кто имеет право иметь мнение?”, а “кто отвечает за quality bar?”
2. Поощрять общий контекст
Много командной политики появляется там, где контекст становится источником власти. Чем сильнее AI ускоряет execution, тем опаснее становится скрытый контекст. Команде нужно делать решения, ограничения, исследования, trade-offs и допущения доступными для всех участников процесса.
3. Нормализовать черновой вклад
Прототип продакта не обязан быть визуально идеальным. SQL-запрос дизайнера не обязан быть элегантным. Набросок интерфейса от разработчика не обязан быть красивым. Смысл не в том, чтобы заменить ремесло друг друга, а в том, чтобы раньше сделать мышление видимым.
4. Отделять критику качества от защиты статуса
В команде всё ещё нужно уметь говорить: “это решение недостаточно хорошее”, “требование неясное”, “эта реализация не масштабируется”. Но такая критика должна защищать продукт, а не чей-то статус.
5. Нанимать на low ego, а не на низкие стандарты
Low ego — это не отсутствие мнения. Это способность менять позицию, делиться ownership и признавать, что лучшая идея может прийти от другого человека.
Главный вопрос
Чем больше я думаю про AI-трансформацию в продуктовых командах, тем меньше мне кажется важным вопрос: “Заменит ли AI дизайнеров, продактов или разработчиков?”
Этот вопрос слишком узкий.
Более важный вопрос: какие команды становятся возможны, когда больше людей могут делать больше вещей?
А сразу за ним следующий: какие люди нужны в таких командах?
Мой текущий ответ такой: нужны люди с сильным judgment, сильным ремеслом и низким эго. Люди, которые не пугаются, когда кто-то заходит в их область. Люди, которые используют AI, чтобы расширить свой вклад, а не просто защитить текущую роль. Люди, которые умеют работать в неопределённости и не превращают каждую размытую границу в политический конфликт.
Потому что цель не в том, чтобы защищать свой стул.
Цель в том, чтобы построить что-то, ради чего вообще стоит садиться за стол.
ссылка на оригинал статьи https://habr.com/ru/articles/1050136/