Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Давайте вместо того, чтобы решать каждую продуктовую задачу по отдельности, сделаем инструмент, который поможет системно решать целый класс задач. Унифицируем, шаблониризуем и автоматизируем работу с похожими продуктами – и за счёт этого сможем запускать новые продукты за 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 витрины, которые были сделаны с помощью конструктора. Запуск последней – от обсуждения идеи до релиза на прод с готовым контентом – занял ровно две недели.
На новых витринах мы наблюдаем прирост трафика:
Но вместе с профитом идут и ограничения. За счёт конструктора витрины наследуют не только фичи, но и надстройки, не все из которых необходимы для каждой отдельно взятой витрины: бывает “балласт”. Все тематики разные, везде свои особенности – ряд продуктов перестают укладываться в шаблон.
Унификация, шаблонизация и автоматизация позволяет запускать и развивать новые витрины быстрее, это правда. Конструктор действительно помогает нам системно решать класс продуктовых задач вместо работы над каждым направлением по отдельности. Но не бесплатно и не безгранично. Классика: баланс решает.
Так что мы на этом не останавливаемся: делать новые витрины ещё быстрее – точно можно. Продолжаем экспериментировать.
