Денис Опалинский — перестраиваю продуктовые организации через AI

8

команд и 75 человек — один общий план вместо восьми

60→82%

столько обещаний на квартал команды реально выполняют

−40%

меньше времени от старта задачи до пользователя

13+ лет

в продукте и Agile, из них 5 лет — коучинг команд

Обо мне

Перестраиваю продуктовые организации через AI

13 лет в маркетинге, продукте и Agile. Последние 5 из них — Agile-коучинг в Газпромбанке, Открытии, НПФ Сбербанк и Рамблере.

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

Работаю на уровне стрима: координирую поток сразу из нескольких команд как RTE. Прямых полномочий у меня при этом нет. Изменения идут через влияние — фасилитацию и то, что команды начинают видеть собственные цифры.

↗ Выстраиваю предсказуемый поток поставки на стриме из 8 команд
⚙ Внедряю AI там, где он сокращает время, а не добавляет ритуалов
◎ Преподаю в НИУ ВШЭ, наставник проектов «Стартап как диплом»

«Ни один директор не скажет совету директоров „не знаю“. Он называет дату, в которую сам не верит, и весь квартал живёт с этим обещанием».

Денис Опалинский

AI-трансформация · Agile-коуч стрима

С чем я помогаю

Где чаще всего ломаются обещания

Шесть направлений. В каждом есть метрика, по которой видно, сработало или нет.

AI

Успевать тем же составом

Внедряю AI-инструменты в реальную работу разработки, аналитики и менеджмента — там, где это сокращает время и держит скорость при меньших ресурсах.

Срок, который можно назвать

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

Проверить идею за неделю

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

Ответ на вопрос «почему эта задача вперёд»

Строим дерево метрик, где видно, как задача влияет на ключевые показатели. Приоритеты считаем по WSJF, и на вопрос «почему эта задача вперёд» есть ответ цифрами.

Статус без запросов по командам

Общая доска в Jira и дашборды, которые обновляются сами. Руководство смотрит статус и риски, не собирая их запросами по командам.

Спор, который заканчивается замером

Вместо спора «мне кажется» против «а мне кажется» — замеры и гипотезы с заранее оговорённым критерием проверки. Спорить становится не о чем.

Кейсы

Что меняется на практике

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

1

Открыть кейс →

Обещания на квартал стали сбываться

с 60% до 82% · предсказуемость поставки квартал к кварталу

Проблема

Стрим из 8 команд выполнял в срок лишь 60% квартальных целей. 40% работы переносилось — это создавало риски для бизнеса и подрывало доверие к разработке.

Что сделал

Ввёл единый стандарт работы и базовый/плановый уровень по Run и Change
Запустил дашборды, которые в реальном времени показывают задачи с риском просрочки
Внедрил сквозную приоритизацию по WSJF — фокус на ценности для бизнеса
Запустил ежеквартальные PI-планирования с подготовкой за месяц

Результат

Точность прогноза выросла с 60% до 82%. Бизнес стал точнее планировать инициативы, разрозненные команды превратились в единый скоординированный поток ценности.

2

AIОткрыть кейс →

Анализатор Jira: руководство видит риски само

Руководство решило внедрять в штатном режиме

Проблема

Руководство постоянно спрашивало «где зависла фича» и «когда релиз», а скрам-мастеры тратили часы в неделю на ручную сборку статусов из Jira. Отчёт устаревал раньше, чем был готов.

Что сделал

Построил анализатор на основе выгрузки Jira с AI-обработкой данных
Автоматическая подсветка эпиков и задач с риском просрочки — по возрасту, отсутствию движения и накоплению WIP
Расчёт реального Cycle Time / Lead Time и точек скопления задач в потоке
Автогенерация еженедельных дайджестов по командам — без ручной сборки

Результат

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

Как это выглядит

Сводка и алёрты по эпикам

Статусы задач и аномалии

Метрики потока по месяцам

Все задачи с фильтрами и рисками

3

Открыть кейс →

Руководство перестало собирать статус вручную

Решения на актуальных данных, без ручных запросов

Проблема

Руководство не видело статус ключевых инициатив: где зависимости и когда ждать поставку. Постоянные ручные запросы съедали время команд.

Что сделал

Создал единый источник правды — общую доску в Jira с зависимостями
Внедрил единый стандарт оформления эпиков, понятный от разработчика до топ-менеджмента
Сделал регулярную практику постановки целей по OKR и синхронизации команд вокруг них
Настроил оформление Jira так, чтобы было видно, что именно влияет на цель
Ввёл ежемесячные демо: команда показывает, на какую бизнес-метрику повлияла работа

Результат

Удовлетворённость стейкхолдеров заметно выросла. Руководство видит прогресс и принимает решения на данных, а не на ручных запросах.

4

Открыть кейс →

Команды увидели, на что влияет их работа

Time-to-market стал измеримым

Проблема

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

Что сделал

Определил единую топологию задач и эпиков для всех команд
Привязал каждый эпик к конкретным бизнес-метрикам
Приоритизировал бэклог от целей бизнеса
Внедрил чёткие критерии готовности (DoR и DoD)

Результат

Команды видят ценность своей работы и связь с общими целями. Time-to-market стал измеримым — сроки можно прогнозировать и управлять ожиданиями.

5

Открыть кейс →

Релизы из раза в месяц в каждую неделю

Теория ограничений: расшили ожидание тестирования

Проблема

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

Что сделал

Замерил поток и нашёл главное скопление WIP — этап «ожидание тестирования»
Разгрузил тестирование: автотесты и детальное описание ожидаемого результата
После — устранил следующее ограничение: ежемесячные релизы
Перевёл на еженедельные релизные окна и дал командам выкатывать минорные правки самостоятельно

Результат

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

Бесплатно · AI-инструмент

AI-партнёр по проверке гипотез

Загружаемая инструкция для Claude (или любой LLM): ведёт вас по фазам — распаковка риска → критерий успеха → самый дешёвый тест → данные → решение. Спорит и не даёт строить раньше, чем вы проверили идею.

«Не читай — загрузи и работай»

Забрать пак в Telegram

Напишите в Telegram — пришлю гайд (PDF) и скилл для Claude. Текст уже подставлен; если нет — он скопирован в буфер, просто вставьте в чат.

1 Распаковка риска

2 Критерий успеха

3 Самый дешёвый тест

4 Данные

5 Решение: строить или нет

Отзывы

Что говорят те, с кем работал

Предприниматель

Трекинг бизнеса · раскрутка продукта

Игнат Шестаков

CTO, CUBA IoT Platform · Казахстан, Астана

Благодарность НИУ ВШЭ

За преподавание и наставничество «Стартап как диплом», 2024

Сертификаты

Образование и сертификация

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

Growth CoachСертификация коуча роста

Certified Agile CoachingScrumTrek, 2024

Certified Lean Change AgentScrumTrek, 2025

PSM IProfessional Scrum Master, Scrum.org

ICP-ATFAgile Team Facilitation

Школа Agile-коучейГазпромбанк, 2022

Карта гипотез — Практик1 ступень, 2025

Certified Professional OKR CoachOKR Academy, 2026

OKR Coach (базовый)Управление по целям

Продуктовый подходАкселератор ФРИИ, 2023

Методология управления проектомGeekBrains

Методологии и фреймворки управленияGeekBrains

Публикации

Пишу для сообщества ChangeLeaders

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

Денис
Опалинский

Перестраиваю продуктовые организации через AI