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

Привет! Я Алина Бриленкова, руководитель онлайн-направления в ивент-агентстве NIGHT STREET. В 2022 году я взялась делать игровую платформу для онлайн-тимбилдингов, марафонов и конкурсов без опыта в IT. Думала, что разработка — это спринт: сделал и выдохнул. Оказалось, что это миф, и на самом деле этот процесс вообще не заканчивается.

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

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

Что за онлайн-тимбилдинги и игровая платформа PLAYFORMA

Сегодня онлайн-тимбилдингами называют всё подряд — карточные тесты, викторины в Zoom, простенькие головоломки. Всё перечисленное почти всегда работает одинаково: вопрос, ответ, подсчёт баллов, победитель.

Не нужно работать в ивент-сфере, чтобы понять, что этого недостаточно для сплочения. Людей объединяет совместный процесс — возможность договориться, распределить роли, найти коллективное решение. Поэтому компании ищут форматы с сюжетом и командной логикой. В NIGHT STREET мы делаем именно такие игры — и именно их считаем онлайн-тимбилдингами.

К 2022 году мы уже несколько лет активно развивали их в Телеграм-ботах. Пандемия ускорила адаптацию бизнеса к онлайну и помогла диджитал-тимбилдингам прижиться и стать частью рынка. Поток проектов не прекращался — мы были в восторге! Где-то в этот момент и стало понятно, что нам нужна альтернатива Телеграм-ботам — собственная платформа для квестов и игр. Рамки мессенджера начали ограничивать развитие:

Ограничения в логике и механиках. Телеграм как инструмент диктует, каким может быть сценарий, а не наоборот.

Бот живёт внутри мессенджера, а значит, конкурирует за внимание с личными чатами, рабочими каналами, новостями и уведомлениями. Удерживать фокус участников сложнее.

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

Не хватает гибкости в брендовой части. Клиенты хотели, чтобы их мероприятие выглядело как полноценный продукт под их брендом: с фирменными цветами, логотипами, собственным доменом и ощущением «это сделали для нас».

Во многих странах Телеграм просто не используют, а значит, мы автоматически сужаем потенциальную аудиторию.

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

Техническое задание: как формулировали требования

Когда мы взялись создавать собственную платформу, полноценной продуктовой команды ещё не было. Ни аналитика, ни UX-дизайнера, ни тестировщика.

Зато я хорошо знала тимбилдинг «#АКТИВАЦИЯ», который мы решили в первую очередь перенести на платформу, потому что сама его проектировала и проводила десятки раз. Поэтому я понимала, какие функции нужны в первую очередь: где администратору должно быть удобно редактировать тексты и картинки, какие метрики нужно видеть в реальном времени.

Фактически мы начали с инвентаризации боли: составили список из того, что уже использовали в Телеграм-ботах и того, чего нам не хватало. Этот список стал базой первого ТЗ: 

1. Настройки и запуск игр. Администратор создаёт игры сам — с уникальной ссылкой и типом прохождения (командное, индивидуальное, гибридное). Задания могут открываться либо последовательно, либо в свободном порядке, либо по расписанию / дням / периодам.

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

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

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

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

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

7. Интерфейс и брендинг. Предусмотрена версия для ПК и мобайла, разные визуальные темы. А ещё опция добавления фоновых изображений, логотипов заказчика. В интерфейсе должно быть всё привычное для всех, кто играет в подобные игры (список заданий, чат, таймер, правила), но с возможностью настроить под конкретный проект.

Также я выписала, какие типы заданий должны поддерживаться:

• с потенциалом на использование синонимов: если игрок напишет «утка», «уточка» или «кряк» (да, и так креативят), система должна засчитывать это как один правильный ответ;
  — «олимпийка»: задания, где нужно попарно соединять слова, пока не останется одно финальное;

• многошаговые цепочки: когда ответ складывается из нескольких этапов, например, игрок проходит пять локаций-панорам, находит предметы и по ним определяет итоговое слово. 

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

От схем к документам

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

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

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

Как я формулировала требования к админ-панели: 

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

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

• работать с участниками: добавлять по одному вручную, загружать списком, проверять, кто уже зарегистрировался и в игре, а кого ещё ждём;

• отслеживать ход игры в реальном времени — кто прошёл задание, сколько набрал.

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

Закладываем поддержку разных типов контента: фото, видео, документы, ссылки и iframe-вставки.

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

Аналитика и поддержка пользователей. Можно отслеживать действия пользователей и команд, смотреть сводную статистику по баллам, времени и активности. А для связи с участниками — использовать встроенный чат, комментарии и систему уведомлений о сбоях.  

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

Какие варианты рассматривали и к чему пришли

Когда пришло время проектировать архитектуру, у меня на руках были:

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

2. Схема интерфейсов — визуальная логика пользовательской и админской части.

3. Рабочие заметки, которые я вела параллельно разбираясь в теме продуктовой разработки. Смотрела вебинары, читала статьи, чтобы понимать, как вообще должны выглядеть MVP, процесс тестирования и выкатки.

Сразу стало понятно, что возможных путей реализации несколько. Первый, который мы рассматривали, построить систему по всем правилам enterprise-подхода:

• микросервисная архитектура;

• отдельные базы под разные типы данных;

• сложные пайплайны деплоя и CI/CD;

• полное разделение фронта и бэка.

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

Красиво, масштабно? Ещё бы, но мы решили отказаться от этого варианта.  У нас не было двух лет — нам было важно запустить продукт уже в этом году. А значит, нужно было искать более быстрый и реалистичный путь. Такой подход бы давал гибкость и масштабируемость, но при наших сроках и объёме задач он избыточный. При этом no-code мы довольно быстро отбросили. Да, это быстро и недорого, но они бы не потянули и половину наших механик. Было понятно: нужен кастомный серверный слой с обработкой логики в реальном времени.

И вот тут начался самый болезненный этап — упрощение. Я постоянно возвращалась к ТЗ, пересматривала приоритеты, выкидывала то, что казалось первостепенно важным, и переносила это на потом.

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

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

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

В итоге к старту проекта мы пришли к такой архитектуре:

• frontend на Vue.js с компонентной системой;

• backend на PHP (Yii2) с WebSocket-соединениями для постоянного обмена данными;

• база данных на MariaDB/PostgreSQL с разделением игровых данных и пользовательских событий.

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

Как проходила разработка и первые тесты

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

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

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

Это оказался довольно болезненный, но важный этап. Я впервые в полной мере столкнулась с разрывом между ожиданием и реальностью. Мы всё лето обсуждали, как должен работать продукт, но в реальности почти во всех случаях он работал иначе.

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

И те вещи, которые казались мне базовыми и очевидными, на практике работали не так, как я предполагала. А значит, нужно было заново описывать логику: подробно объяснять, как именно должно работать то или иное действие и отвечать на вопрос «почему именно так, а не иначе».

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

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

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

Первая тестовая игра

На первую тестовую игру мы сразу пригласили наших реальных клиентов, сразу вышли в «боевой» формат. Это всегда серьёзные репутационные риски.

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

Подготовка была максимально напряжённой: я детально расписывала тест-кейсы, продумывала сценарии, пыталась предусмотреть всё, что может пойти не так.

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

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

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

Первый полноценный проект

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

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

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

Выводы

Колесо Сансары никогда не останавливается

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

В разработке продукта всё устроено иначе. Несмотря на то, что в IT все, казалось бы, живут спринтами, по факту разработка — это бесконечный марафон. Да, ты делишь его на этапы, но у него нет финальной точки. Не существует момента, в котором можно сказать: «ура, продукт готов». Всегда есть что доработать, улучшить, пересобрать. И даже если кажется, что сейчас всё классно и работает безукоризненно — тебе просто нравится очередная версия, но это  не финал.

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

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

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

Лучшее решение — первое

Ещё один важный и в каком-то смысле неожиданный инсайт. Когда мы выкатили платформу, я, конечно, порадовалась: появился рабочий продукт, мы начали получать фидбэк, и круто, что положительный. Я смотрела на результат и думала, какие у нас классные разработчики, как здорово всё получилось.

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

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

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

Но ещё важнее — вывод, который из этого следует. Главное: большие продукты невозможно делать без глубокой аналитики. Без этапа, где ты реально садишься и несколько недель думаешь, как это должно работать, как это устроено у других, и как пользователь будет проходить весь этот путь.

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

А дальше началось самое интересное: как работающий MVP платформы вырос в продукт, который мы продолжили развивать и масштабировать. Об этом — в следующем материале.