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

Меня зовут Юра, я Delivery Manager в Сравни. Сегодня расскажу вам, как мы делали конструктор для запуска и управления тематическими разделами на нашем маркетплейсе.

В Сравни мы помогаем людям получить финансовые, страховые и образовательные  услуги – так, чтобы было быстро, просто и честно. Пользователи могут сравнивать предложения от разных компаний по выбранной тематике: займы, кредитные карты, ОСАГО и другие продукты. Раздел маркетплейса, посвященный одной теме, мы называем витриной. Если посмотреть на Сравни как на супермаркет финансовых и страховых услуг, то витрина – это тематический прилавок.

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

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

Добавление новых фичей или правки могли занимать до 2-3 месяцев (и вряд ли меньше недели). На запуск новой витрины могло уходить до полугода.

Ещё из минусов:

• архитектура: код витрин наследовал архитектуры нескольких эпох – с вытекающими отсюда “внезапными” багами;

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

Мы решили это изменить. 

Новый подход к витринам: конструктор 

Задачу мы сформулировали так:

• ускорить разработку: переиспользуем готовые решения между витринами;

• унифицировать дизайн: делаем единый UX на всех витринах с помощью дизайн-системы;

• добавить масштабируемости: упрощаем создание новых витрин.

Ключевая идея изменений была в том, чтобы сделать единый сервис, в котором витрины собирались и редактировались бы не разработчиками, а бизнес-аналитиками. Срок на разработку – 1,5 месяца, так договорились с бизнесом. Мы взялись за констуктор витрин.

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

Создание первой версии заняло у нас месяц: запустили на проде четыре новые витрины.

Во второй версии мы первым делом переехали с Google Sheets на нормальную базу данных. Расширили функциональность, добавили ещё витрины.

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

Что под капотом у конструктора: JSON для всего 

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

Внешние сервисы – SEO, реклама, аналитика, UI – снова через JSON.

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

Отсюда вытекает важное требование для коммуникаций в команде: когда Product Owner какой-то витрины придумывает новую фичу, важно как можно раньше рассказать о ней всем, кто отвечает за другие витрины – чтобы они с минимальными правками могли переиспользовать её у себя.

Кто все эти люди: команда 

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

В команду входят:

• 4 инженера

• 3 бизнес-аналитика

• 1 дизайнер

• 2 продуктовых аналитика

• 1 продакт-оунер

Зачем столько бизнес-аналитиков? Тут важная идеологическая штука про конструктор: тотальный JSON для всего задумывался, чтобы большинство задач аналитики могли решать без участия разработчиков, путем редактирования конфигов. Сейчас доля таких задач – примерно 90%. Те доработки, которые до конструктора занимали два месяца, теперь требуют двух дней (а иной раз 20 минут).

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

В зону ответственности бизнес-аналитиков входят:

• логика работы витрины; 

• инициирование доработок, взаимодействие с дизайнерами, разработчиками, продактами;

• JSON-конфигурация (технические скиллы нужны аналитику в этой части).

Первым бизнес-аналитиком в команде стал наш коллега из команды SEO, затем мы взяли двух выпускников Бауманки. “Технические навыки бизнес-аналитика” – может прозвучать страшно, но на деле вполне реально.

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

Границы применимости конструктора: что может пойти не так 

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

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

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

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

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

Унификация, но с оговорками: чему нас научил опыт с конструктором витрин

Результаты, которые принёс нам конструктор, можно сформулировать так:

• кардинально сократили время на создание новых витрин: вместо 4-8 недель целой команды – в среднем 2 дня одного аналитика;

• в уже запущенные витрины можно вносить изменения без разработчиков;

• сделали общий дизайн, за которым довольно просто присматривать;

• используем единую кодовую базу (одни и те же бандлы для всех витрин); имеем довольно быстрое и простое обновление пакетов;

• одна фича – одна задача; за счёт этого больше прогнозируемости по доставке на прод.

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

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

На новых витринах мы наблюдаем прирост трафика:

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

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

Так что мы на этом не останавливаемся: делать новые витрины ещё быстрее – точно можно. Продолжаем экспериментировать.