Проектирование продукта для Freedom QJ League

Задача

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

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

Какие процессы охватит система

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

Как делали аналитику

Неделя 1

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

QJ League показали нам список конкурентов и – внезапно – игру Football manager, которая идеально отражает то, какую систему хотелось бы видеть на выходе. В игру мы втянулись. Наш директор по развитию провел несколько  бессонных выходных увлекшись  ее аналитикой. Это помогло разложить на кусочки процессы, которые мы фиксировали для создания будущих интерфейсов.

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

Неделя 2

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

Первой зафиксированной сущностью стал календарь с тренировками. Это основа интерфейса планирования тренировочного процесса.

Все, что мы обсуждали, закрепляли в документе, готовили какие-то вопросы заказчику, составляли идеи и декомпозировали процессы. В целом подходу, согласно которому мы работали, можно дать рабочее название «Ничего не понятно – все понятно». По такому принципу многоступенчатую аналитику проводить становится чуть понятнее и проще. 

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

Так получилось сформировать видение решения, нагенерировать идеи по функциональности решения.

Неделя 3

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

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

Недели 4 и 5

Финальные этапы проектирования – это валидация ранее сгенерированных гипотез, формирование User Story Map и определение той функциональности, которая войдет в первую версию системы. Кроме того, здесь мы уже приступили к планированию архитектуры решения и подбору технологий для реализации всей задуманной функциональности – не только для MVP, но и для дальнейшего масштабирования. 

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

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

Архитектура и технологии

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

Технологический стек: NodeJS, NestJS, React, Next.js, TypeScript, Serilog, NUnit. 

Результаты

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