Кейс: как мы сделали lowcode-сервис для нетворкинга на гибридном мероприятии

Провести конференцию в онлайне довольно просто, но что делать с профессиональной выставкой? Спикеров вообще может не быть, трансляция не нужна, а вот естественное общение само в интернете не начнётся.

Кейс: как мы сделали lowcode-сервис для нетворкинга на гибридном мероприятии

Мы в компании Ratio занимаемся веб-разработкой и недавно помогли организовать International Business Travel Forum & MICE Geography Show 2020. Вот официальный сайт.

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

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

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

Не спешите программировать

В Ratio сильные разработчики, но мы всегда ищем способ обойтись без программирования. Дело в том, что написание кода — самая длительная и самая дорогая часть разработки веб-проекта.

Когда у клиента горят сроки, программисты не способны решить его проблему чисто физически — просто не успеют.

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

Большинство мелких задач можно выполнить совсем без программирования (no-code) или с минимальным участием разработчиков (low-code).

Чтобы проверить, решается ли ваша проблема без кода, пройдите по этому списку:

  1. Посмотрите, что уже есть на руках. Прототипы, наработки прошлых лет — возможно, вам не понадобится разрабатывать новый сервис, достаточно будет улучшить старый.
  2. Составьте схему сервиса. Не забудьте учесть внешние расширения — календари, звонилки и так далее. Подумайте о технической поддержке: где будете общаться с пользователями и какие данные в базе нужно будет менять вручную.
  3. Продумайте типы пользователей, их возможности и ограничения. Узнайте, нужно ли будет менять что-то на ходу.
  4. Поищите готовые решения. Если кто-то уже изобрёл велосипед до вас, будет выгоднее оплатить подписку на сервис, чем разрабатывать похожий продукт самостоятельно.
  5. Если готовый продукт не получается найти, посмотрите платформы для разработки без кода. Сначала no-code, потом low-code.
  6. Начинайте полноценную разработку. Вы сделали всё, чтобы обойтись без программирования, но задача слишком сложная или нетипичная. Не забудьте предупредить заказчика, что дело может затянуться.

Такой подход экономит время и страхует от лишних трат на разработку. В начале проекта трудно предсказать его результаты — возможно, вложения никогда не окупятся. Поэтому я советую всем запускать первые версии цифровых продуктов на no-code или low-code решениях, даже если сразу понятно, что потом понадобится собственная разработка.

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

Что было в начале

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

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

Прототип можно было допилить вручную, но нам не хватало времени. Пришлось искать другие варианты.

Составляем схему сервиса

Мы расписали базовые возможности сервиса, которые бы позволили провести мероприятие:

  • Список участников. Это основное рабочее пространство: байер видит всех экспонентов и выбирает тех, кто ему интересен.
  • «Моё расписание» и календари других участников. Чтобы не затягивать встречи и не создавать очередей, мы разделили календарь на таймслоты по 15 минут.
  • Уведомления. При бронировании таймслота и за 5 минут до встречи байер и экспонент получают уведомления на почту. Внутри есть ссылка на созвон в сервисе Jitsi Meet.
Кейс: как мы сделали lowcode-сервис для нетворкинга на гибридном мероприятии

Техническое задание и баглист мы сделали в Notion, техподдержку организовали через Telegram и почту (потом добавился WhatsApp). Для рассылки писем с логинами и паролями использовали собственный скрипт.

Продумываем типы пользователей

У каждого пользователя в нашей системе указаны тип и статус.

  • Тип: байер или экспонент. Экспонент может предложить встречу, но байер должен подтвердить согласие. При желании байер может сам назначать встречи экспонентам — подтверждение от них не требуется.
  • Статус: онлайн или офлайн. В первый день выставки пользователи с разными статусами не должны пересекаться: офлайн-посетитель не может назначить встречу в онлайне. Перед началом второго дня статус всех пользователей мы меняем на «онлайн».

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

Всего байеров было около 200, а экспонентов — 50.

Пробуем готовые решения

Мы нашли два готовых сервиса:

  • Calendly — разбитый на таймслоты календарь с прикрученными email-оповещениями. По описанию именно то, что нужно, но разные типы и статусы пользователей он не поддерживает. С технической поддержкой тоже возникают трудности, там нет админки.
  • PINE Tool — комплексное решение для проведения онлайн-мероприятий. Есть нетворкинг, но нет возможности гибко настраивать права и проводить гибридные онлайн/офлайн мероприятия. Кроме того, в сервисе есть встроенная платформа для трансляций: у заказчика уже была договорённость с другим сервисом, а подружить его с PINE Tool без костылей нельзя.

Готовое решение использовать не получилось, при этом на доработку старого сервиса не хватало времени. Тогда мы начали смотреть в сторону nocode-технологий.

Пытаемся сделать без кода

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

Эксперимент с распознаванием речи, который IBM провели в 80-е. Пользователь слева думает, что компьютер распознаёт и переводит в текст его речь, хотя на самом деле этим занимается человек в соседней комнате
Эксперимент с распознаванием речи, который IBM провели в 80-е. Пользователь слева думает, что компьютер распознаёт и переводит в текст его речь, хотя на самом деле этим занимается человек в соседней комнате

Для нашего случая схема без кода получается такой:

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

Решение выходит довольно проблемным. За два полноценных дня на одного участника набегает 64 временных слота по 15 минут каждый. Если участников будет 250, операторам придётся вручную отметить 16 000 слотов — и крайне желательно не ошибаться.

Кейс: как мы сделали lowcode-сервис для нетворкинга на гибридном мероприятии

Вспомнив про сложности с типами и статусами пользователей, мы поняли, что nocode-решением точно не обойдёмся, даже если получится автоматизировать работу операторов. Тогда стали искать lowcode-платформы: решили самостоятельно разработать фронтенд, а на бэкенд время не тратить.

В качестве платформы выбрали Backendless. Бонусом получили страховку: если не получится собрать фронт на Vue.js, то сделаем его внутри платформы — там есть такая возможность.

Для создания дизайна мы использовали библиотеку готовых элементов Vuetify, а прототип собирали в Figma.

Запуск и первые проблемы

В последний день перед запуском мы уткнулись в стену: импорт в админке Backendless не выгружал данные пользователей с реальными регистрациями. Попытка сделать это вызвала подвисание всей платформы на час.

Мы узнали о проблеме в момент запуска сервиса на продакшн. В логах детализация ошибок не отображалась.

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

Ещё словили баг с часовым поясом. У участников из Сибири и с Кипра в системе отмечалось их местное время. Пришлось вручную передвигать встречи в админке.

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

Сервис получил пару десятков положительных отзывов
Сервис получил пару десятков положительных отзывов

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

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

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

Что получили на выходе

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

Чтобы больше узнать о возможностях MeetingPlanner, посмотрите лендинг в Notion. Если вам понадобится организовать общение людей на вашем мероприятии — свяжитесь со мной, контакты есть в лендинге.

Подписывайтесь на Telegram-канал

Я веду телеграм-канал @panfilovonline, в котором рассказываю про управление удалённой командой и наш подход к разработке. Подписывайтесь, чтобы быть в курсе новых статей и читать посты, которые больше нигде не появляются.

1414
4 комментария

спасибо, интересно. а что скажете про генераторы кода, CRUD генераторы?

1
Ответить

Максим, это тоже полезные инструменты для сокращения затрат на разработку. Используем, например, https://api-platform.com/docs/core/operations/ на Symfony — отлично подходит для простых сайтов. Сложнее, когда нужно выходить за базовый функционал и вводить кастомные операции.

С натяжкой можно под генератор подогнать FOSRestBundle (https://symfony.com/doc/current/bundles/FOSRestBundle/index.html) для Symfony, он конечно не полностью генерирует код, но содержит много абстракций, которые значительно ускоряют процесс создания API. В связке с FOSRestBundle, для генерации доки используем NelmioApiDocBundle.

Ответить

спасибо! очень полезно

1
Ответить

Аня, спасибо! :)

Ответить