To be or not to be продуктовому подходу в DIY-ритейле

В российский ритейл, в отличие от технологических компаний, продуктовый подход пришел сравнительно недавно. И если для технологических компаний продуктовый подход чаще всего стандарт работы, то для ритейла это эксперимент со множеством неизвестных. О том, как на него решиться и стоит ли это делать, я расскажу в статье. Меня зовут Дмитрий Сукновалов. Я являюсь директором продукта «Леруа Мерлен».

Когда ты приходишь работать менеджером продукта в IT-компанию, ты, как правило, заранее знаешь, как будет устроен процесс работы над продуктом. Да, сам продукт для тебя будет новым, но подходы и принципы работы, а также организация команд будут такими же, как и в большинстве IT-компаний на рынке. Можно сказать, что ты находишься в зоне комфорта и просто работаешь на результат. Когда ты приходишь работать менеджером продукта в ритейл, ты, как Алиса Льюиса Кэрролла, ныряешь в нору за кроликом в жилете и с карманными часами.

Использование IT-технологий в ритейле — это уже не обозримое будущее, а каждодневная стратегия выживания. Невозможно бесконечно строить новые магазины в попытке дотянуться до покупателя. Нужно постоянно изучать его поведение, менять формат офлайн-магазинов, нужно ловить покупателя в интернете. Поставщики товаров тоже зачастую выбирают для сотрудничества сети, с которыми проще, быстрее и удобнее работать, и это, как правило, технологически развитые сети. Проблема в том, что нет проторенной дорожки, ведущей от обычной к digital-компании, — каждый игрок на рынке ритейла прокладывает свой путь. И если с продуктовым, фэшн-ритейлом и даже с бытовой техникой все более или менее понятно (всегда можно «подсмотреть» успешный западный пример), то российские сети магазинов товаров для строительства, ремонта и обустройства дома должны сами придумать, как совместить высокие технологии с «перламутровыми пуговицами».

В «Леруа Мерлен» долгое время практиковался проектный подход, когда за определенный бюджет сторонними компаниями создавались необходимые IT-решения. И до определенного момента это неплохо работало. Также в компании был классический IT-департамент, в который внутренние заказчики тоже обращались с какими-то задачками по автоматизации. Со временем задач становилось все больше, росло количество сотрудников, вендоров, усложнялись коммуникации, фактическая скорость изменений была далека от желаемой. Появилась потребность в гибкости, которая является, пожалуй, основной ценностью продуктового подхода. К пандемии компания подошла с IT-департаментом в 400+ человек и пониманием, что нужно основательно меняться, чтобы не захлебнуться в собственном бэклоге.

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

У каждого домена есть зафиксированные бизнес-показатели, за которые он отвечает. Это могут быть показатели, связанные с товарооборотом, маржинальностью, качеством (оценка нас нашими партнерами-поставщиками или покупателями), с типом логистического потока, по которому товары идут от поставщиков и попадают в наши распределительные центры и магазины и т. п. Операционные и продуктовые команды внутри домена сообща работают на то, чтобы повлиять на свои бизнес-показатели.

Принцип «есть выделенный бюджет — давайте сделаем продукт, а то наш бюджет сгорит» сменился принципом «давайте поймем, какие проблемы пользователей или бизнеса мы хотим решить, рассмотрим различные возможные решения и оценим, как эти решения повлияют на бизнес-KPI». Можно сказать, что с появлением продуктовых команд в доменах изменился образ мышления.

Для продукт-оунера это идеальная среда для погружения в саму суть бизнеса. Так ты видишь не одну отдельно взятую проблему, которую тебе спустили сверху с невнятным ТЗ и зачастую с нереальным дедлайном, а весь клубок причинно-следственных связей и, что особенно важно, можешь влиять на происходящее. Операционная команда не ставит задачу, а делится своей болью. Как лечить эту боль, продуктовая команда решает самостоятельно. Также можно работать на опережение, замечая бутылочные горлышки, инициировать создание новых продуктов, экспериментировать. Очевидно, что продуктовый подход позволяет успешнее адаптироваться к быстро меняющейся внешней среде.

Пайплайн не бесконечен

После релиза можно заниматься поддержкой продукта или его развитием. А можно посмотреть на путь пользователя и увидеть идею для создания нового продукта. Для второго в ритейле очень много возможностей. В нем есть длинная цепочка от производителя/поставщика до конечного пользователя, с физическими магазинами и сайтом, а в некоторых случаях — послепродажного сопровождения и сервисного обслуживания. Есть возможность разрабатывать продукты b2b, b2c, для внутренних пользователей в финансах, логистике, HR, управлении товарным предложением, е-коме.

В «Леруа Мерлен» эту спираль можно раскручивать до бесконечности. Все потому, что домен — это структура, в которой есть достаточно ресурсов для решения задач в своем периметре. Но всегда существует множество сквозных задач, которые связывают несколько доменов, в том числе и продуктовые команды в них. Так происходит взаимодействие для создания единого пути клиента (поставщика / внутреннего сотрудника / клиента офлайн и интернет-магазина). Есть и определенный стандарт взаимодействия в рамках таких задач. Архитекторы разбивают существующие процессы на ABB (architecture business blocks), для каждого из которых есть блок решений — SBB (solution business block). Чем больше взаимосвязей с другими доменами, тем выше уровень ответственности для менеджера продукта, но и тем проще осваивать новую предметную область. Внутренняя мобильность и переход из команды в команду — нередкая практика.

Кроме того, трансформируется бизнес-модель «Леруа Мерлен». Сначала это была географическая экспансия, потом доступность онлайн, следом — омниканальность. Новая амбиция — стать платформой по обустройству дома, с которой клиент может реализовать любой проект под ключ: от еще не оформившейся идеи до коврика перед входной дверью после окончания ремонта. Она будет объединять и поставщиков сети, и мерчантов маркетплейса, и множество сервисных компаний разного профиля. Для ее реализации практически нет готовых продуктов и решений, но на то она и амбиция!

Продуктовая аналитика

При разработке наших продуктов мы всегда опираемся на данные и много общаемся с нашими пользователями. Пользователи для нас — это поставщики «Леруа Мерлен», внутренние сотрудники и наши покупатели. Каждый тип пользователей, в свою очередь, может быть разбит на сегменты. Сегменты отличаются своими уникальными особенностями и потребностями, которые важно учитывать при проектировании продукта. Например, поставщикам маркетплейса важна скорость онбординга в сеть и простота листинга своих товаров, а крупным поставщикам строительных материалов скорость входа в сеть не так важна, но при этом важна гибкость логистики и объемов поставок.

Иногда мы приходим к пользователям лично и разговариваем, также регулярно рассылаем опросники и собираем обратную связь через различные доступные каналы (сайт, саппорт, мероприятия) — это качественные данные для аналитики и подготовки продуктовых гипотез. В некоторых случаях мы напрямую не общаемся с пользователем, но постоянно делаем количественные замеры внутри продукта, исследуем конверсии и воронки, смотрим на метрики, проводим a/b-тесты.

Продуктовая команда

Продуктовая команда состоит из двух дополняющих друг друга частей — discovery team и delivery team.

В discovery team обычно есть product owner (менеджер или руководитель продукта), дизайнер и аналитик. Product owner отвечает за формирование видения продукта, его бэклога и за сроки реализации. Также он организует работу discovery-части продуктовой команды по сбору и оценке гипотез и отвечает за delivery (т. е. за конечную реализацию продукта). Аналитики чаще специализируются либо на бизнес-, либо на системном анализе. Но самые опытные из них в равной степени обладают этими компетенциями — поэтому для любого аналитика важны hard skills — например, знание языков программирования или навыков работы с машинным обучением.

Discovery-команда также может привлекать внешних экспертов: бизнес-архитекторов, юристов, маркетологов и других специалистов, которые нужны для проработки гипотез, для формирования видения продукта или для его реализации.

Delivery-команда включает разработчиков (бэкендеры программируют логику, а фронтендеры переносят ее в интерфейсы) и тестировщиков, отвечающих за то, чтобы система работала так, как задумано и описано в спецификации. Также есть несколько ролей, обеспечивающих связь между командами. Например, технический архитектор, или технический лид. Это инженер-разработчик, который отвечает за всю работу по разработке внутри домена, проектирует и описывает технические решения, является лидером-экспертом среди других инженеров, а также отвечает за наем и технические собеседования разработчиков.

Есть профессии, которые в силу определенной специфики нет смысла тиражировать и добавлять в каждую продуктовую команду, но иметь такого эксперта внутри домена нужно. Например, это позиция data-инженера. Мы активно работаем с данными, на основе которых можно проводить анализ и строить отчетность. У дата-инженера общий по всем продуктовым командам бэклог.

Также в некоторых командах есть роли application-менеджеров, которые обеспечивают бесперебойную работу существующих систем. Как правило, это наследие проектной работы, когда после сдачи подрядчиком системы ее кто-то должен поддерживать с нашей стороны.

Есть инфраструктурные команды, которые непосредственно к домену не относятся, но мы с ними взаимодействуем по определенным задачам, — например, админы и devops.

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

Продуктовое направление

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

Например, направление «Ценообразование», которое объединяет системы управления закупочными ценами и расчета себестоимости. Основная задача менеджера продукта, который отвечает за продуктовое направление, — работа с относящимся к его направлению бизнес-процессом и поиск возможностей его оптимизации за счет развития текущих продуктов и создания новых. Оптимизация в данном случае — это решение конкретных пользовательских проблем.

Так произошло, например, с продуктом, который мы называем «Управлением закупочными ценами». Мы подробно исследовали весь процесс взаимодействия сотрудников операционной команды с поставщиками по установлению закупочных цен. И пришли к выводу, что глобальная проблема пользователей (в нашем случае поставщиков и сотрудников центрального офиса) заключается в том, что не существует понятного обеим сторонам и прозрачного процесса работы с ценами. Поэтому первая итерация продукта была связана с созданием интерфейса для обмена предложениями по ценам. Ее цель — перенести коммуникацию с поставщиками по закупочным ценам из почты и мессенджеров в простой и понятный интерфейс, тем самым создать единое пространство работы с ценами, стандартизировать этот процесс и, как следствие, оптимизировать время на согласование цен.

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

Оказалось, что подобный продукт будет востребован не только в российском подразделении «Леруа Мерлен», но и в других бизнес-юнитах группы компаний Адео. В итоге у продукта появилась долгосрочная стратегия развития, которая включает стартовую точку (mvp) и будущие итерации с привязкой к маржинальности. Также появилась международная команда, которая будет работать над реализацией этой стратегии.

И все же быть или не быть?

Многие процессы в ритейле сегодня выстраиваются по ходу. Что-то перенимается из технологических компаний, какие-то best practices у западных коллег, какие-то велосипеды изобретаются самостоятельно.

«Леруа Мерлен» в этом смысле не стала исключением. Когда я приходил в компанию, у доменов были свои автономные цели, которые часто пересекались с целями других доменов. Не было единого процесса целеполагания, не было списка приоритетных продуктов. Прошло всего полгода, и вот у нас уже появился десяток важных направлений — приоритизированных, отскоренных по степени влияния на бизнес. Это своего рода продуктовое портфолио, внутри которого разные команды живут, получают ресурсы, отчитываются о результатах. Компания меняется на глазах.

Если ты приходишь из IT-сферы, где все процессы заранее структурированы и отлажены, то словно погружаешься в бурлящую горную реку со множеством подводных камней и порогов. Определенные процессы упорядочиваешь, на какие-то до поры до времени закрываешь глаза, но выдаешь результат! Чем сложнее порог, тем больше адреналина и азарта. Неподготовленного человека это может ввести в некоторое смятение, и нужно понимать, как с ним справиться. Тебе дадут лодку, весла. А вот куда и как ты будешь грести — решаешь только ты. Просто надо быть готовым, что в любой момент возникнет вопрос — почему ты гребешь именно туда.