Как сделать нишевый маркетплейс, чтобы конкурировать с гигантами рынка. Интервью с SOLOMA и Сибирикс, финалистами WDA 2024

865

В этот раз мы пообщались со студией, съевшей собаку на разработке маркетплейсов — scrum-студией Сибирикс. Ее команда разработала сайт — маркетплейс мебельных комплектующих SOLOMA, кейс по которому занял третье место в WDA 2024. Мы узнали у руководителей Сибирикс и SOLOMA о том, сколько сил ушло на создание продукта, как его поддерживать и развивать, а также как сделать свой маркетплейс прибыльным в столь высококонкурентной среде.

С нами пообщались:

Денис Фатеркин, начальник отдела электронной коммерции SOLOMA;

Владимир Завертайлов, генеральный директор веб-студии Сибирикс.

К интервью!

Здравствуйте, благодарим вас за участие в премии WDA и поздравляем с третьим местом в номинации «Сайты / E-commerce»! Довольны ли результатом?

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

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

Понимаем ваше недовольство, можем прокомментировать так: в участии в конкурсе всегда присутствует некий элемент везения. Итоговые оценки складываются из оценок членов жюри, которые по своим субъективным критериям могли поставить более высокий балл другой работе. И мы держим в голове, что в вашей номинации было много достойных работ. Так что считаем третье место очень крутым результатом :)
Значит, вы работаете над улучшениями сайта. Есть ли у вас беклог с идеями по обновлению продукта?

Владимир: На улучшения продукта уже затрачено более 2000 часов разработки. К конце года будет 2500+ часов. У продукта есть бэклог, где хранятся все запланированные задачи. Работаем по спринтам, классический Scrum.

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

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

Так выглядят страницы сайта SOLOMA — маркетплейса мебельных комплектующих

Понятно! Вы рассказали, что работали над сервисом спринтами — мини-проектами длиной в месяц. Вы работали в рамках фреймворка Scrum?

Владимир: Да, мы все клиентские проекты делаем по Scrum.

Про организацию процесса можно почитать в моей книге: «Настольная книга project-менеджера. Что нужно знать, чтобы управлять IT, digital и другими проектами с учетом российских реалий», либо у нас на сайте.

Надо почитать, пару раз ваша книга встречалась на просторах Телеграм-каналов, там ее хвалили. Тогда даже не знал, что ее написали вы :)
Правильно ли понимаю, что вы не оценивали крайние сроки работы над сервисом, если работали над ним, используя гибкий подход к разработке?

Владимир: На старте у нас была вилочная смета на MVP и диаграмма Ганта со сроками по всем этапам на MVP-версию.

При разработке MVP мы рассматриваем каждый этап разработки как отдельный спринт. Это предпроектная аналитика, прототипы, дизайн главной страницы, дизайн внутренних страниц, верстка, а также программирование. Этапы дизайна внутренних страниц, верстки и программирования также могут быть разбиты на отдельные спринты.

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

Аналитику мы всегда стараемся выносить отдельными спринтами. Задачи, требующие ресерча, сначала лучше разобрать-декомпозировать. Это позволяет в итоге более четко оценить стоимость и сроки, когда очередь дойдет до разработки.

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

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

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

Это дает заказчику массу преимуществ:

Понятные бюджеты и сроки на запуск первой версии продукта, для которого понятны бизнес-процессы. При этом первая версия будет полностью функциональной — туда можно вносить контент, пускать пользователей, тестировать гипотезы. Можно запускать рекламу и начинать поисковое продвижение.
Возможность проверить продукт на реальных пользователях и из их обратной связи приоритезировать все фичи, собранные в бэклоге. Много раз оказывалось, что пользователями вообще не востребованы фичи, которые заказчик очень хотел видеть в MVP и отложил с трудом. Зато оказываются нужны другие, о которых на старте проекта заказчик и не предполагал.
Возможность гибко реагировать на потребности рынка. Тут ситуация аналогична с тестированием на пользователях.
Возможность проработать бизнес-процессы на своей стороне, пока идет разработка MVP. На проекте SOLOMA заказчик проделал огромную работу по настройке бизнес-процессов параллельно с запуском MVP-версии сайта. Например им была внедрена PIM-система для создания единой базы данных товаров.

Сколько времени у вас ушло на разработку такого сервиса? Какие этапы в себя включала эта разработка?

Владимир: Первую версию продукта мы запустили меньше, чем за год. Шли по нашим стандартным процессам:

провели агрегацию требований и подготовили прототипы ключевых страниц;
разработали дизайн-концепцию главной страницы и уже в ее рамках отрисовали все другие страницы;
дальше запустили 2 потока параллельно: писали техзадание (в нашем случае это был набор подробных бэклогов на спринты разработки) и начали верстку проекта;
запустили программирование для первой версии проекта, которое заняло у нас 5 спринтов;
параллельно программированию разрабатывали протоколы интеграции и саму интеграцию с внешними системами.

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

Сколько людей состояло/состоит в рабочей группе? Верно ли понимаю, что вы собрали кросс-функциональную команду, выделенную специально под работу над этим сервисом, если вы действовали в рамках Agile-подхода?

Владимир: Кто был в проектной команде при разработке MVP:

руководитель проекта;
аналитик;
2 дизайнера и арт-директор;
верстка: 3 фронтэнд-разработчика + QA;
программирование: 3 разработчика + QA. Также проводилось ревью всего кода проекта техническим директором.

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

После завершения спринта команда может уйти на другой клиентский проект, если по первому проекту — пауза. Например, после разработки дизайна MVP-версии дизайнеры присутствовали на проекте только для авторского надзора. А после начала спринтов техподдержки они неоднократно возвращались к продукту для разработки дизайна новых фич и разделов.

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

Владимир: У нас есть несколько проектов с интеграциями сопоставимой сложности. Например — в интернет магазине для Империи сумок или Орматека. Орматек мы много лет развиваем в режиме технической поддержки: тоже по Scrum. Там, например, реализована площадка обменов с маркетплейсами, которых больше десятка. Для нее мы даже не написали пока отдельный кейс :)

Очень много интеграций в планировщике SingularityApp — нашем собственном продукте. Там всякое: начиная от импорта событий из внешних веб-календарей конкретного пользователя и двусторонней интеграции с Google-календарями, заканчивая модулями для миграции из заметочников, таких, как Notion.

Что было самого интересного в работе над SOLOMA?

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

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

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

Начали с базовой конфигурации для Ansible, отдали её заказчику вместе с кодом сайта, чтобы проверить работоспособность — специалисты «ФомЛайн» запустили конфигурацию, настроили сервер и развернули код — всё, пусть и не сразу, но заработало.

Ну и очень нравится, как развивается проект. Уже после конкурса, мы успели написать еще один кейс — про развитие проекта.

Хм, надо почитать! Что отличает проект для SOLOMA от работы над другими маркетплейсами?

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

Мы писали про возможные варианты решения, однако в общем виде полноценно такую задачу не решил никто. Вариант с мастер-каталогом оказался жизнеспособным.

Использование PIM-системы (Pimcore) позволило сделать гибкий и удобный каталог. Кроме того, сам Pimcore имеет открытый код и позволяет вести доработки, не привязываясь к вендору (это особенно важно в нынешних реалиях с импортозамещениями). Брокер сообщений Apache Kafka позволяет сделать надежную и масштабируемую систему и строить микросервисы.

Как считаете, какой самый ценный опыт вы вынесли для себя, работая над сервисом?

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

Очень интересная и неочевидная мысль! Если бы вам пришлось разрабатывать схожий сервис во второй раз, вы бы сделали его быстрее? Если да, то за счет чего?

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

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

И напоследок, наш фирменный вопрос: будете ли участвовать в новом сезоне WDA? Если да, то какие кейсы у вас припасены для взятия наград?

Владимир: Да! Кейсы еще выбираем, в этом году запустили несколько очень сильных проектов. На всякий случай: первый кейс SOLOMA у нас в блоге.

Большое спасибо за ответы! Теперь хотим пообщаться с Денисом, чтобы побольше узнать о самом бизнесе. Как вам пришла идея создать такой маркетплейс? Это была просто идея, которую вы решили протестировать или на рынке действительно была потребность в подобном сервисе?

Денис: Создание маркетплейса — это логичное продолжение развития бизнеса с учетом новых трендов на цифровизацию и электронную коммерцию. Прогнозы экспертов говорят, что к 2025 году объем онлайн-продаж в России увеличится на треть по сравнению с 2020 годом.

Результатом цифровизации для различных компаний являются разные проекты. Для одних — это интернет-магазин, для кого-то — закрытый b2b портал. Для ФомЛайн — это маркетплейс, который интегрирован в текущие бизнес-процессы компании, целью которого является замыкание экосистемы вокруг себя.

Маркетплейс Солома решает несколько задач:

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

Так выглядит первый экран маркетплейса SOLOMA

Если исходить из вашего опыта, насколько востребованы частные маркетплейсы в B2B? Думаем, что это хорошая идея для ниш, где много разных товаров и достаточно много производителей. Чем запрашивать прайс-листы у разных поставщиков по отдельности, проще воспользоваться услугами одного сервиса.

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

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

Да уж, с такими гигантами тяжело соперничать. Как вы продвигали маркетплейс среди потенциальных партнеров? Вы отправляли холодные КП или пользовались платными каналами продвижения?

Денис: В бизнес-модели маркетплейсов есть две целевые аудитории: клиенты и продавцы. Соответственно, привлечение и тех, и тех — две разные задачи.

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

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

Клиентов привлекаем классическим методами онлайн-продвижения: контекстной рекламой, таргетом, SEO, ведением тематических групп в соцсетях.

Настроили перераспределение входящих запросов на горячую линию ФомЛайн, в зависимости от типа клиента и объема заказа.

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

Денис: Такой статистики пока нет.

Какие у вас планы на развитие?

Денис: В данный момент мы делаем акцент на коммерческих показателях. Это рост оборачиваемости, количество заказов, повышение конверсии, частота возвратов, средний чек и другие ключевые показатели электронной коммерции.

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

Есть ли в вашем случае смысл выходить с таким продуктом за рубеж? Оценивали ли вы международную конкуренцию?

Денис: Сначала надо закрепиться на конкретном рынке в конкретном сегменте. Масштабирование — это следующий шаг, который зависит от большого количества производных. Пока рано об этом говорить.

Благодарим за ответы!

Небольшой анонс для читателей. Если вы являетесь представителем digital-агентства, спешите подать свои работы на Workspace Digital Awards 2025! Прием работ уже скоро закончится — 17 февраля 2025 года. Поучаствуйте в одной из самых престижных премий Рунета для веб-студий!

Как сделать нишевый маркетплейс, чтобы конкурировать с гигантами рынка. Интервью с SOLOMA и Сибирикс, финалистами WDA 2024

Переход на внешний сайт