RTPlatform: запуск маркетплейса в сфере услуг

Денис Гордиенко, генеральный директор Bright Mobile, о разработке коробочного продукта для запуска маркетплейса услуг.

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

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

— возможность размещения заявки определённой категории;

— список заявок, доступный исполнителю и отсортированный по типу его деятельности;

— возможность отправки предложения заказчику услуги;

— каталог исполнителей с профилем и возможностью оставить им сообщение;

— отправка сообщения в собственном месенеджере приложения или же связь по телефону;

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

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

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

Техническая платформа

Для кросс-платформенной разработки мы взяли Ionic и Firebase. На Ionic приложение работает намного быстрее, чем WebView, на котором был Сервис ПИ. Немало ушло времени на реализацию быстрого переключения экранов в Сервис ПИ — нативные переходы вызывали серьёзные затруднения. Зато в результате была достигнута существенная экономия: благодаря тому, что экраны делаются в HTML, а логика прорабатывается на Angular, дорабатывать проект проще, чем делать натив с нуля: готовый результат работает и на Android, и на iOS.

Выбор в пользу Firebase также имел определённые причины. Первая — серьёзная нагрузка, которую способна выдержать эта база от Гугла. Бесплатная версия позволяет получить пакет в сотню бесплатных подключений — в среднем, около тысячи установок приложения (хватит чтоб проверить идею проекта). А по скромной цене среднего VPS-сервера в $25 можно получить уже 200 000 подключений — то есть около 20 миллионов установок. Такая устойчивость Firebase позволяет запустить проект и даже не переживать о том, выдержит ли оно нагрузки у клиента. Вторая причина вытекает из первой: заказчикам попросту не требуется сервер, а приложения работают с базой данных по REST API. Казалось бы, совершенно не важный пункт, однако только за два года у нас было порядка десяти заказчиков, которые потеряли проекты только из-за того, что забыли о продлении сервера.

REST API. Хочу также уделить пару слов интерфейсу взаимодействия Firebase. К нему можно подключить не только приложения, но также любую другую внешнюю систему, например, вебсайт или CRM и осуществлять двухстороннюю передачу данных.

Специфика продукта

Вкратце пройдусь по ряду особенностей нашего решения и объясню, по какой причине они выполнены именно таким образом. Цель — упростить запуск первой версии приложения с идеей маркетплейса услуг, как YouDo, Profi.Ru и подобные.

Платформа в реальном времени. Для большей части наших заказчиков во главе угла стоит скорость работы приложения, поэтому мы решили реализовать платформу по принципу Real Time. Технически это сделано путём соединения по сокету и подписки на топик. То есть при изменении сама БД сообщает моментально обо всех изменениях в приложение.

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

Список и биржа. Вряд ли когда-нибудь прекратятся споры по поводу того, какая реализация удобнее: по типу Яндекс.Услуг (когда заказчик выбирает исполнителя из списка) или по типу YouDo (когда пользователь оставляет заявку, а исполнители отзываются на его проект). Мы предпочли сохранить оба варианта, чтобы клиент сам выбрал, что считает нужным. Так как софт — это в первую очередь заготовка, то, в зависимости от типа проекта, программист сам отключает не нужный раздел или вносит изменения в идею.

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

Развитие

При создании Сервиса ПИ была проблема — в коробку закладывались любые клиентские пожелания. Нам казалось, что чем гибче будет проект, тем лучше. Это очень сильно нагрузило архитектуру и сделало поддержку проекта очень затратным делом.

В RTPlatform мы решили пойти иным путём — в ядро закладываются только те изменения, которые были нужны минимум трём клиентам при интеграции. При таком подходе за год появились следующие изменения:

1. Монетизация подписок мастеров (по умолчанию Яндекс.Деньги)
2. Переработано разделение функционала компонент и сервисов. Не вдаваясь в технические детали удалось увеличить скорость работы приложения до уровня натива.
   
3. Подписка на Push-уведомления перенесена на сервер для лучшего контроля подписки, теперь в мобильном приложении нужно только сохранить подписку — это удобно для программистов поддержки, которые далее развивают проекты клиентов.
   
4. Серверные функции переписаны на TypeScript и благодаря строгой типизации ошибок до сборки будет выявляться больше. Опять же, для программистов поддержки важно в паблик выложить проект без багов.
   

В дальнейшем планируем внедрить админку (сейчас проходит тесты на первых клиентах) и возможность фильтрации по полям заявок и исполнителей прямо из коробки.

Для кого мы это делаем?

На мой взгляд, наше решение пригодится двум категориям клиентов:

— Основатели собственных проектов, которым нужно протестировать свой продукт: решение «заказчик — задание — исполнитель» станет для них максимально быстрым и дешёвым.

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

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

За год было запущено 4 проекта в режиме тестирования идеи (ядро с минимальными доработками) и 10 проектов, где идея проверена и требуется реализовать первую стабильную версию, часть уже запущено, часть в процессе внедрения.