📍 Этап 1 — Трансформация в e-commerce (Q2-Q3 2025)
Цель: Запуск первой продуктовой команды.
Перевод BA из IT в Управление электронной торговли. Закрепление через должностную инструкцию функциональное подчинение Руководителя службы веб-разработки с влиянием на его зарплату.
Перевнедрение Scrum, реальные церемонии, а не имитация. Переход на новый Product Delivery Flow, уход из Jira.
Делигирование функций Product Manager'a внутри Управления электронной торговли. Ввод отдельной роли в команду.
Описание e-commerce продуктов вместе с деревом метрик
Руководитель службы веб-разработки отвечает за delivery-метрики (Velocity, Cycle Time, Lead Time, Bug Rate) на уровне KPI.
Переработка Flow для кросс-доменных инициатив. BDM становится владельцем данного Flow.
Метрики успеха:
Внедрена культура подготовки Definition of Ready и Definition of Done. Полный контроль над разделением зон ответственности.
Product Manager работает отдельно, продукты выделены, дерево метрик готово
Начальник управления электронной коммерции занимает роль E-com CPO. Управляет стратегией домена и Roadmap. Product Manager - отвечает за тактику и контроль реализации.
QA работает строго по чек-листам на основе критериев приемки
Настроен общедоступный дашборд для визуализации продуктовых метрик
Настроен общедоступный дашборд для визуализации delivery-метрик
📍 Этап 2 — Трансформация в Управлении инициативами (Q2-Q3 2025)
Цель: Продуктовый офис полноценно управляет технологией Изменений в компании
Методология управления инициативами и WorkFlow (включая выбор инструментов управления задачами, этапами и документацией) переходит под контроль BDM (Продуктового офиса).
Часть Бизнес-аналитиков в продуктовом офисе трансформируются в Product Manager'ов. Отвечают за дискавери, согласования с бизнесом, суть и ценность инициатив. Обеспечивают чтобы бизнес получал то, что заказывает.
Проджект-менеджеры трансформируются в: скрам-мастеров (курируют инициативы от продуктового офиса) или PO и уходят в бизнес-команды.
Руководители направлений автоматизации занимают роль Delivery Manager'ов. Отвечают за общую доставку ценности (техническую реализацию), качество и сроки технической реализации. Delivery Manager инициативы определяется исходя из домена заказчика (выгодоприобреобритателя от внедрения инициативы).
Смена подхода к планированию инициатив с годового плана на более гибкий квартальный. (годовой план остается как обобщение вектора движения)
Появляется роль ProductOps: отвечает за внедрение и адаптацию продуктовых практик в бизнес-доменах. Обеспечивает прозрачность сбора и визуализации продуктовых метрик по всей компании.
Переработка Flow для кросс-доменных инициатив. BDM становится владельцем данного Flow.
Метрики успеха:
Подготовлена и продемонстрирована новая технология управления изменениями в компании.
Перенесены все будущие инициативы. Новые запускаются уже по новой технологии.
Е-ком команда полностью переведена из Jira и работает в Кайтен по новому Product Delivery Flow.
Проведены первые церемонии по управлению инициативами.
📍 Этап 3 — Трансформация IT (Q2-Q4 2025)
Цель: Превращение централизованного IT в сервисную платформу.
Создание команд: Platform, Enablement&Support.
Определение иных продуктовых команд (КЦ, Розница, Сервис), бизнес-функций, программного обеспечения
Техдолг: Планирование вывода из корпоративного монолита (напр. CRM из УТ для КЦ, PIM для MDM)
Полный цикл внутренней разработки остаётся для стабильных (инертных) направлений (HR, финансы, бухгалтерия, юриспруденция) с возможностью отделиться в будущем.
Выделение/найм Delivery manager'ов для координации кросс-доменных инициатив
Метрики успеха:
Вместо общего "отдела автоматизации", созданы локальные службы с техническими специалистами Dev+QA для каждой продуктовой команды (Например: служба автоматизации логистики).
Функциональными владельцами ресурсов технических специалистов являются Руководители доменов/PO. Они определяют "что делать и когда". Тех. лиды доменов - "как делать?".
Нельзя изнутри IT просто взять и поставить задачу (лично, в почте, в мессенджер) технической команде минуя PO. Только через бэклог, согласовав с PO.
Нельзя просто взять и "переназначить/перевести" специалистов из одной команды в другой домен/проект и команду "для усиления, потому что сроки горят", ТОЛЬКО по согласованию с PO и исключительно в экстренных случаях!
CTO управляет стеком технологий, архитектурой, тех. долгом, delivery-процессами, инфраструктурой
За каждой кросс-командной инициативой закреплены Product manager, который отвечает за суть и ценность инициативы, и Delivery manager, который отвечает за доставку инициативы.
📍 Этап 4 — Масштабирование-1 (Q2–Q4 2025)
Цель: Создание новых продуктовых команд в динамичных департаментах.
Discovery в доменах: логистика, маркетинг, коммерция
Discovery в программных продуктах, обслуживающих домены. Планирование вывода в отдельные сервисы при необходимости
Обучение среднего/высшего менеджмента доменов продуктовому подходу, Scrum и Kanban
Подбор/перевод персонала новых команд в бизнес-департаменты
Создание архитектурной гильдии (Tech Lead'ы всех команд+ PO + CTO)
Метрики успеха:
Еще 3 команды работают в Scrum/Kanban
Назначены PO на продукты: WMS, TMS, CDP, NPS-сервис
PO и ключевые лица обучены Discovery и CustDev
Запущен продуктовый фреймворк: HEART (или аналог)
Настроены дашборды для визуализации продуктовых и delivery-метрик
OKR используется как система постановки целей и координируется BDM
📍 Этап 5 — Масштабирование-2 (Q4 2025 – Q2 2026)
Цель: Вывод оставшихся продуктовых команд: Колл-центр, Розница и Сервис.
Идентификация программных продуктов и бизнес-процессов: PIM (MDM), CRM/OMS/Melissa (колл-центр), POS/Приложения продавца (Розница), ELMA (Cервис)
Назначение PO из бизнес-подразделений, обучение их Discovery и CustDev
Формирование команд и выход из централизованного IT
Внедрение Kanban в процессах, где работа поточная (КЦ, Сервис)
Внедрение Scrum для итерационных поставок ценностей в программных продуктах
Интеграция с ранее выделенными платформенными командами
Метрики успеха:
Назначены PO и выделены команды под все продукты
Продукты описаны, выявлены ключевые метрики (обращения, SLA, скорость возвратов и т.п.)
Минимум 3 новых команды запущены, работают в Scrum/Kanban
Созданы карты процессов и backlog'и по каждому направлению
📍 Этап 6 — Финансовая трансформация и KPI (Q1-Q2 2026)
Цель: Финансовая ответственность и оценка эффективности продуктовых команд.
Модель бюджета на команду продукта, а не на проекты
Публичные бэклоги и дашборды эффективности команд
Расширение роли ProductOps, трансляция единых продуктовых практик внутри компании
KPI продукта напрямую финансово влияет на мотивацию PO (бизнес сфокусирован генерировать максимально ПОЛЕЗНЫЕ фичи)
Delivery-метрики напрямую влияют на мотивацию ответственных из IT (IT сфокусировано на КАЧЕСТВЕННОЙ разработке)
Метрики успеха:
Финансирование по продуктам, а не проектам
Портфель и ресурсы команд публичны и прозрачны
Бизнес и delivery-метрики отслеживаются
📍 Этап 7 — Стратегическая трансформация (Q2–Q4 2026)
Цель: Делегирование операционки, фокус на стратегии и росте продуктов.
Формирование Digital Board (Стратегический комитет) — ежемесячная встреча для стратегических решений по цифровым продуктам, инвестициям и приоритетам
Проведение QBR (ежеквартальные обзоры результатов продуктовых команд): анализ достижений по метрикам, обновление стратегических приоритетов, возможность пересмотра бюджетов
Делегирование day-to-day на уровень ниже
Обучение управленцев Discovery, BA, PM
CTO — владелец delivery-системы
Рост PO из среднего звена, закрепление продуктовой культуры
Метрики успеха:
Топ-менеджеры полностью вовлечены в стратегию
Средний менеджмент — Владельцы продуктов (PO) и реальные операционные лидеры
Продуктовая модель работает устойчиво без внешней поддержки
🚧 Потенциальные риски трансформации
Сопротивление высшего руководства из-за непонимания своей новой роли, страха потери влияния, контроля и привычной зоны комфорта
Сопротивление среднего звена при смене ролей и перераспределении ответственности
Формальное внедрение Agile без глубинных изменений культуры и процессов
Недостаточное вовлечение топ-менеджмента в стратегические инициативы
Перегрузка ProductOps и CTO без выстроенной поддержки со стороны доменов
Отсутствие прозрачных инструментов для оценки бизнес-ценности фичей и продуктовых решений
Конфликты между бизнес-заказчиками и техническими командами при расфокусировке целей
✅ Меры по снижению рисков
Создание "Комитета по трансформации" с полномочиями к действию. Комитет отвечает за координацию этапов, устранение конфликтов между подразделениями и контроль исполнения плана трансформации
Проведение обучающих сессий и фасилитируемых стратегических сессий с участием топ-менеджеров для переосмысления их роли
Постоянная коммуникация целей трансформации и пользы новой модели на уровне всей компании
Внедрение системы "Change Agents" — амбассадоров трансформации в каждом департаменте
Использование пилотных проектов как доказательства ценности продуктового подхода