Поиск по этому блогу

пятница, 27 марта 2020 г.

Дышите глубже. Box Battle проезжает Сочи.

Box Battle отработал уже год и отправился в командировку на Чёрное море в Адлер - Сочи. Где попал к одарённым подросткам в образовательный центр Сириус.

С 04 марта по 11 марта дети проводили бои по темам: Финансовые технологии, Кибербезопасность, Инновации в платежах.

Вопрос в другом. Чему нас научил этот кейс, и как он заставил нас смотреть на аналитику Box Battle другими глазами.

Аналитический бэкграунд.

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

К концу года было проведены успешные запуски Box Battle в нескольких компаниях:

  • Hoff (знание товарных линеек)
  • HILTI (знание технических особенностей профессиональных инструментов)
  • Pernod Ricard (знание истории компании, брендов и гибких навыков)
  • РГС Банк (знание банковских продуктов)
  • Монетный двор (финансовая граммотность)

Проведены турниры на различных массовых мероприятиях:

Но мы не оставили в стороне и свох коллег. В Лабмедиа за год прошло 3 игровых сессии на темы:

  • WebTutor (наш первый запуск Box Battle)
  • Английский язык (для проверки уровня владения английским языком среди сотрудников)
  • Вёрстка HTML (первый шаг в сторону аттестации по средствам Box Battle)

По итогам года, на момент написания статьи, у нас была собрана следующая выборка данных:

  • 2429 уникальных пользователей
  • 11107 сыгранных боёв
  • 6461 вопрос в базе данных
  • 48 уникальных компаний

Переходим к самому интересному, какие выводы мы сделали из всего этого массива информации.

Нужно больше вопросов! Или всё-таки нет?

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

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

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

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

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

Но вопрос в другом, мы хотим увеличить частоту входов игроков или увеличить эффективность обучения?

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

Как это было в Сириусе?

С 04 марта проводилось ежедневное информирование участников о мероприятии в общих чатах месенджеров и группе мероприятия вконтакте.

Кроме того, в общедоступных местах был вывешен постер с объявлением о проводимом чемпионате.

Данная статистика нам говорит не более того, что такой вид информирования участников отлично достигает своей цели.

Но дальше - интереснее.

После регистрации более чем 80% всех игроков, мы видим резкий скачок на графике количества игр.

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

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

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

  1. Высчитываем необходимое количество вопросов на весь период обучения.
  2. Дробим весь период обучения на "сессии" исходя из правила - (100 вопросов/20 человек/2 рабочих дня).
  3. На каждую новую сессию готовим мотивирующую рассылку с информацией о появлении новых вопросов в игре.

"Да это же жулики!"

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

Или не то чтобы "нечестно", а *спойлер* тактически продуманно.

Анализируя два верхних графика одновременно вас может смутить резкое падение количества ответов 8 марта по сравнению с 6 марта, но с сохранением прежнего значения очков. Возникает вопрос, как такое может быть?

Что мы должны в такой ситуации проверить при подозрении на использование какого-то стороннего скрипта?

Если пункт проверен и с ним всё хорошо, то двигаемся на следующий.

  • Очки начисляются только за бои с реальным противником - делаем запрос на количство боёв, где не участвут бот.
  • Определяем, какие бои прошли в эти дни и какое реальное количество ответов было дано
  • Выборка вопросов по их сложности
Таким образом у нас получилось, что 08 марта игроки стали чаще выбирать сложные вопросы, стремясь победить как можно больше противников в сжатый срок.

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

Что мы можем сделать, для того чтобы использовать этот абуз себе на пользу? Есть две опции:

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

На этом всё. До встречи на полях сражения!

вторник, 3 марта 2020 г.

Грабли. Мазь от синяков

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

В самом начале, когда мы понимаем, что будем работать над новым курсом или курсами, команда вспоминает свой прошлый опыт. Это позволяет нам предусмотреть риски и не наступить на грабли, которые уже встречались на пути раньше. Сложности возникают практически всегда, и важно всегда быть готовым к ним.   
Самые частые из них – эти:
1.     Нарушение коммуникации в команде.
2.     Создание новых возможностей курса в середине пути.
3.     Изменение объёма информации, которую нужно проанализировать и включить в курс.

Рассмотрим каждый момент с позиции сложность-решение. Речь пойдёт о том, как предусмотреть сложности и не искать вместе с заказчиком способов увеличить сроки разработки.

1. Нарушение коммуникации в команде.

Как правило, каждый проект начинается с заряда бодрости – каждый участник хочет сделать курс эффективнее, интереснее, современнее и т.д. Но в какой-то момент любой проект превращается в рутину. Для кого-то раньше, для кого-то позже. Но каждый участник со временем это ощущает. Как результат – снижение продуктивности, которая была в начале, и нарушение коммуникации с другими, потому что «всем всё и так понятно (сейчас закончу свою часть и пойду домой)». И если первое следствие рутины – естественный процесс, то второе – сознательная прокрастинация или отсутствие менеджмента. Как раз второе и нужно предусмотреть в начале разработки.

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

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

На собраниях каждый высказывается о своих трудностях, о новых идеях, о той же рутине (при этом часто находятся решения от коллег, как её избегать). Как показывает практика, на собраниях, где, вроде, «и обсуждать нечего», участники засиживаются ещё больше, предлагая новые пути достижения результата или корректируя процесс разработки. Короче говоря, главное правило – поддерживать регулярное проведение собраний команды. Как много времени нужно на каждое собрание – смотреть по ситуации, как правило, это 30-60 минут, раз в неделю.

2. Создание новых возможностей курса в середине пути.

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

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

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

3. Изменение информации, которую нужно проанализировать и включить в курс.

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

Решение – это «резиновый скелет», на который можно надеть любое мясо – контент. В нашем случае это компоненты – утверждённые в самом начале элементы вёрстки, которые не меняются по ходу всего проекта. Бывают исключения, но они точечные.

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

Мы заранее ставим себя в рамки определённого набора компонентов/интерактивов, и кажется, что это плохо – потому что всё будет одинаковым. По факту же выигрывают все: команда разработки быстро собирает курс или вносит коррективы, а заказчик сходу понимает, из чего он строится и каким он будет – демонстрация прототипов со всеми компонентами этому способствует. В сухом остатке, смысл в том, чтобы с самого начала договариваться о некоторых рамках разработки. То, что выходит за рамки, обсуждается отдельно.

___
Три сложности, о которых я рассказал, не исчерпывают весь список сложностей, с которыми мы сталкиваемся. Однако они так часто встречаются, что, уверен, с ними сталкиваются и наши коллеги из других компаний.
Если у кого-нибудь есть свои решения разнообразных сложностей в разработке, обязательно поделитесь. Будем помогать друг другу по мере возможностей. J

P.s.
Безусловно, вещи, о которых я рассказал, закрываются разработкой по эджайл, и могут показаться сами собой разумеющимися. Однако опыт подсказывает, что эджайл в чистом виде – как написано в манифесте – очень часто неосуществим, его нужно подстраивать под собственный контекст. Сложности и решения выше – это наш контекст. Именно в нём мы, хочется думать, конструируем и собираем нужные и результативные обучающие продукты.