Женя Селиверстов · Product Ops x AI

Как я две недели познавал новый мир ИИ

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

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


Первым MVP, которое я затеял, был AI-трекер для JIRA. Зачем он нужен?

◦ Заранее видеть срывы сроков и управлять зависимостями между задачами и командами;
◦ Проставлять задачам и эпикам «светофор» рисков по срокам;
◦ Вести актуальную карту зависимостей между инициативами и командами;
◦ Делать еженедельный дайджест с триггерами и рекомендациями: что мешает, где нужно включиться, на что обратить внимание.

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

В своей идее я ориентировался на JIRA Cloud, у которой есть похожий функционал, но в России он, так сказать, не особо доступен. В коробке для закрытого контура его точно не развернуть.


Какие инструменты я попробовал для реализации MVP:

◦ Claude Code, Codex, Cursor (просто пробовал разные, пока не понял, что проблема во мне) + кучу всяких обёрток для разработки, тестирования и выкатки;
◦ n8n, платформу OpenAI, десяток решений с коннекторами и вагончик разных API;
◦ В саппорте у меня были: Gemini 2.5 Pro (режим Deep Thinking), ChatGPT (Pro модели), Manus, Claude и Google AI Studio;
◦ Локальная LLM Gemma, раскатанная на ноуте;
◦ Разные подходы к базам данных, памяти и маршрутизации;
◦ Советы друзей и коллег, которые в теме.

В общей сложности на эксперименты с этим MVP за неделю я потратил 30–35 часов (не спать до 2–4 утра – уже привычка).


Какие выводы я сделал?

Начнём с плохого:
◦ Если нет железного терпения, критического мышления, стойкого желания разобраться и по 150 раз в день безуспешно пробовать разные решения – лучше этим не заниматься.
◦ Если нет понимания, что в 90% случаев LLM выдаст херню (полностью или частично) и всё придётся перепроверять по 10 раз – лучше не лезть.
◦ Если вы не понимаете принципы написания кода – лучше сначала этому научиться и сделать пару простых проектов ручками, потому что искать проблемы и делать отладку на глюченных советах LLM – такое себе развлечение;
◦ Если вы плохо понимаете предметную область, которую автоматизируете, – сначала разберитесь и сделайте вручную, а уже потом подключайте ИИ-инструменты.

Теперь хорошее:
◦ Если всё выше вы готовы пройти и выжить – создать самостоятельно можно всё, что угодно.
◦ Когда-нибудь всё станет проще и доступнее, но не сегодня.


Итог этой недели:
У меня есть вполне рабочее MVP, которое нужно еще доработать, понимание фундаментальных принципов Python, Java, SQL, JSON + я научился писать простые решения без ИИ.

Стоило ли оно того? Однозначно да.

–

Что я сделал не так?
Мне все настойчиво советовали начать с простого: один-два шага, потом постепенно расширять функционал. А я, как обычно, полез сразу собирать звезду смерти. Не надо так делать:)

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

Вайбкодинг и чему учить детей

На прошлой неделе на конференции Boost в Сколково девушка задала вопрос: «Мой муж работает в Силиконовой долине и говорит, что вайбкодинг покоряет мир, поэтому учить ребёнка программированию смысла не имеет».

Давайте разберём.

Как сказал Влад Плющев (ВП Сбера по IT розницы): «Люди в ближайшем будущем будут делиться на тех, кто потребляет технологии, и тех, кто эти технологии создаёт».

Да, вайбкодинг (вайбдизайн и вайб-что-то-ещё) – это действительно круто:
– можно пробовать разные языки программирования без глубокого погружения, расширяя кругозор;
– быстро собирать прототипы и проверять их на пользователях;
– запускать лендинги и простые приложения, заметно снижая косты на разработку/дизайн простых решений и MVP.

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

Как и во времена промышленной революции, когда появились станки и машины, труд стал гораздо более интеллектуальным – людям пришлось больше работать головой.

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

Чему учить ребенка в 2025+, если хочется не только «пользоваться», но и создавать:
1. Системную инженерию и системное мышление: как части системы взаимодействуют и где узкие места. Прекрасно для этого подходят ТРИЗ или Школа системной инженерии Анатолия Левенчука.
2. Логику и алгоритмику: декомпозиция, причинно-следственные связи, тестирование гипотез.
3. Язык программирования (любой «живой»): как инструмент мышления и автоматизации.
4. Данные: модели, простая статистика, как мерить результат и работать с цифрами.
5. Работу с ИИ: постановка задач, проверка вывода, сборка простых «агентных» связок.
6. Проектную практику: маленькие, законченные проекты «от идеи до результата». Поэтому я люблю школы, где детей учат чему-то через реализацию проектов, в том числе в команде.

Итог: вайбкодинг и ИИ – отличные ускорители. Но будущее создают те, у кого есть основа: системное мышление, данные, код как инструмент и привычка доводить проект до результата. А еще насмотренность:)

Что делать, когда сталкиваешься с «саботажем» от коллег

Бывает, что твои грандиозные планы кто-то стопорит. Просишь запустить фичу или новый процесс, но коллеги из соседней функции встают в позу: «риски», «инфраструктура», «ресурсы», «противоречит приказу».

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

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

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

2. Определить, где именно вы расходитесь.
Чаще всего упирается во что-то одно:
– цель (вы про разные результаты);
– задача (сформулирована неясно);
– приоритет (для тебя это «суперважно», а у коллег другой скоринг);
– сроки/ресурсы (ты хочешь «завтра», а у коллег уже расписан квартал);
– подход/метод (у вас разные представления о том, что такое хорошо и как правильно);
– риски (ты чего-то не знаешь или считаешь риск несущественным).

3. Собрать аргументы и факты.
Подготовь понятную позицию, привязанную к конкретным фактам и данным. Объясни задачу коллегам так, как хотел бы, чтобы объяснили её тебе.

4. Слушать, а не топить.
Дай “оппоненту” высказаться. Зафиксируй как есть. Не спеши отвечать – возьми паузу, спокойно разложи аргументы и точки расхождения.

5. Принести опции, а не «да/нет».
2–3 варианта с трейд-оффами обычно достаточно. Дели реализацию на итерации, проводи тесты, смотри на метрики, риски, нагрузку и результат. Это лучший аргумент для последующих изменений и масштабирования.

6. Эскалация – крайняя мера, а не стиль работы.
Если коллеги встали в позу и не идут на партнёрство, подготовь зрелую позицию: факты, риски, что пробовали, где и почему расходитесь, какие варианты на столе. Эмоциональная эскалация убивает экспертность. До похода «наверх» попробуй решить вопрос с коллегами на полступеньки выше – спокойно и уважительно.

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


Итог: выигрывает не тот, кто громче и убедительнее кричит (хотя, и такое иногда бывает), а тот, кто перевёл конфликт в системное русло: нашёл точку расхождения → принёс факты → предложил опции → зафиксировал границы безопасности и результата. Всё остальное – шум, который сильно раздражает.

Кто я и про что этот канал

У этого канала было много экспериментов. Честно — большая часть из них ни к чему не привела.
С завтрашнего дня он будет называться «Женя Селиверстов · Product Ops × AI» — просто потому, что так меня зовут и это то, чем я с удовольствием занимаюсь каждый день.

Что для меня "Product Ops × AI"?

Это о том, как сделать так, чтобы продуктовые команды внутри большой корпорации создавали больше ценности для пользователей и достигали целей бизнеса.
А ИИ — один из ключевых инструментов, который позволяет мне делать это быстрее, эффективнее и с меньшими затратами ресурсов. Пример: если бы я собрал команду из пяти человек и запустил масштабный аудит процессов, ушли бы месяцы и куча денег. А так — с одним человеком и ИИ я сделал то же самое за 1,5 месяца и получил тот же результат.

Немного обо мне

Я — Женя Селиверстов. Сейчас руковожу направлением Product Operations в Мегафоне.
В 2021–2025 я отвечал за продуктовую культуру в МТС — подробнее здесь.
С 2019 по 2021 работал в команде Product Vision, занимался продуктовым консалтингом, запускал стартап Assessty для оценки soft/hard skills.
В 2017 запускал B2C-сервис поддержки решений в ремонте и строительстве.
С 2011 по 2021 у меня была своя компания по комплектованию строительных объектов; параллельно занимался строительством, реконструкцией и реставрацией.
До этого было разное: MediaMarkt, ING Group, диджейский проект, написание музыки на заказ.

О чём буду писать

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

Отдельное спасибо Михаилу Грекову и его курсу «Инфостар» — благодаря ему моя история с телеграм-каналом наконец встаёт на рельсы.

Рад знакомству и спасибо, что читаете.

Лена прекрасный профессионал. И я очень рад, что именно она учит наши продуктовые команды пирамиде метрик:)

И снова прекрасный подкаст:)

Поболтали с любимыми пирожочками на интересную тему:)

19 июня был мой последний день в МТС.

Уйти, когда все проекты на пике успеха, – решение совсем не простое.

Причины выхода простые:

– Мне нужен новый вызов – сложный, непонятный, масштбаный, даже пугающий: «я вообще не знаю, как это сделать, но я это сделаю». Именно такой вызов у меня был 2,5 года назад, когда я принял предложение руководить продуктовой культурой в МТС.
– Вся моя команда сама способна вести и развивать проекты, а мои внезапные «гениальные идеи» стали больше мешать, чем помогать.
– Текущий амбициозный путь экосистемы МТС не давал мне нового вызова, а делать то же самое ещё год-два – ну такое.


Что удалось сделать за 2,5 года?

1. «Продуктовый университет» (он же Product Support Platform)

Мы превратили оценку, обучение и развитие продуктовых команд в драйвер роста бизнеса:
– Чётко посчитали экономический эффект от нашей программы: за прошедший год – сотни миллионов рублей допвыручки и экономии, ROI – больше 300%, прямое влияние на ключевые нефинансовые метрики продуктов.
– Настроили прозрачную аналитику каждого шага – от снятия запроса с СРО до финального демо; понятная система работы и оценки результата для топ-менеджмента и продуктовых команд.
– Поработали с 67 продуктовыми командами: реализовано 75% целей СРО, подняли зрелость у 56% команд, бизнес-эффект показали у 11% команд в программе.

Спасибо моей команде Продуктового университета: Саша Пустовит, Алиса Грачева, Наташа Добрынина, Маргарита Драчева. Отдельное спасибо друзьям из T&D: Слава Карнаушенко, Оля Митрофанова, Настя Ковешникова – без вас не получилось бы ничего.

2. HR-бренд продуктовой экосистемы

– Вы вошли в топ-10 самых привлекательных компаний для продакт-менеджеров (исследование Product Sense 2024).
– Сделали интеграции с South Hub 24/25, Product Sense 24, People Sense 25, Product Camp 23, офлайнами #безвотэтоговотвсего. Особенно горжусь тем, что на South Hub 24 мы с «Самолётом» первыми сделали настоящую коллаборацию; в 2025-м устроили максимально крутую, масштабную и тёплую пятидневную коллаборацию с друзьями из Авито.
– Запустили собственные экспертные завтраки и бранчи с Т-Банком, Сбером и Альфой.
– Провели десятки космических внутренних демо (Тинги) с продакшеном уровня топ-конференций, объединив людей со всех уголков компании.
– Записали и выпустили внутренний подкаст «Культурно поговорили» про людей в МТС и коллаб-выпуски с make sense и #безвотэтоговотвсего.

Все эти активности дали главное – люди почувствовали ценность себя и коллег, начали коллаборироваться не только внутри, но и с другими корпорациями.

Спасибо моей команде продуктового HR-бренда: Иоанна Петш, Алиса Грачева, Даниил Бекетов. Мы доказали, что в такие проекты стоит инвестировать, и показали шикарный результат при очень ограниченных ресурсах.

А еще мы помогали другим функциям в компании настраивать процессы, строить методологии и искать компромисс там, где раньше все друг другу «показывали зубы».


Отдельные благодарности:

– Максиму Лаптеву («мой» вице-президент по цифровым продуктам) – за свободу, мотивацию, ресурсы и энергию.
– Ларисе Бодягиной (вице-президент по управлению персоналом) – за доверие, ресурсы и смелость запускать проекты уровня «никто так не делал, но будет круто».
– Маше Фаустовой – за видение, системность, экспертизу и приземление нас в реальность.
– Игорю Косолапу – за твою поддержку, вдохновение и неиссякаемую искру.
– Олегу Рогожину – ты стал для меня настоящим другом, который давал мне мудрость и тепло в самые трудные моменты.
– Андрею Бийчуку и Жене Бобкову – за открытость, идеи и поддержку. Мы с вами, пирожочки, еще свернем не мало гор.
– Сереже Паращенко – за бесценное наследство в продуктовой культуре МТС.

Ну и, конечно, десяткам, если не сотням других людей в и вне МТС, с которыми мы работали и творили магию.

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


Спасибо, МТС. Я был искренне счастлив пройти этот непростой пусть вместе с тобой:)

Экзестенциальный вопрос для всех, кто занимается корпоративной культурой и измнениями в корпорации:)

Все ли в организации зависит от лидера и его роли в организации, или, как это часто бывает, сама организация "выбирает" себе нужного руководителя для движения к своим зачастую отнудь не позитивным бессознательным целям?

Всё придумано до нас

Когда-то в древние времена я читал лекцию про Product Discovery и мне стало интересно, откуда ноги растут. Оказалось, что Product Discovery был придуманы ещё пару сотен лет назад, а первопроходцем в этом был Галилео Галилей. Тогда это называлость просто «научным подходом».

Метод включает в себя исследование феноменов, систематизацию и корректировку новых и ранее полученных знаний. Умозаключения и выводы делаются на основе правил рассуждения и эмпирических (наблюдаемых и измеряемых) данных об объекте, полученных через наблюдения и эксперименты. Чтобы объяснить наблюдаемые факты, выдвигаются гипотезы и строятся теории, на которых затем базируется модель изучаемого объекта.

То же самое происходит и с «продуктовой культурой», которую как только ни определяют. Ещё в 1968 году Мелвин Конвей описал в Harvard Business Review свой «Закон Конвея».

Если коротко, то:

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

(Привет всем любителям создавать плейбуки)


Если не коротко:

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

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

К чему всё это?

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