Дистанционное образование (EdTech) — изобретение далеко не вчерашнего дня. Прообраз современных образовательных платформ — популярный в 2005–2007 годах тренд — записи видеоуроков и лекций, выложенные на Youtube. В настоящее время EdTech развилась в мульти-миллиардную индустрию, обслуживающую миллионы людей ежедневно. Пандемия, поневоле запершая человечество в четырех стенах, а также лишившая многих стабильного заработка, только подтолкнула провайдеров услуг дистанционного образования к поиску новых технологий, процессов, форматов и рынков. Естественно, возросла и конкуренция образовательных платформ.
Несмотря на то, что EdTech продукты для B2B и B2C разрабатываются по общепринятым фреймворкам и методикам программирования, в этой присутствует своя специфика, требующая решения целого ряда задач по выявлению потребностей, способов их реализации и расчету прибыли, выстраивания процесса разработки и сопровождения. От успешности решения этих задач владельцами продуктов (product owner), проектными менеджерами и бизнес-аналитиками будет зависеть развитие продукта и его жизнеспособность.
За последние несколько лет команды Ауриги выполнили несколько крупных проектов по разработке и поддержке высоконагруженных образовательных портальных решений. Основываясь на своем опыте, мы решили адресовать эту статью для руководителей проектов и владельцев продукта, и начать ее с описания тех задач, с которыми обязательно придется столкнуться всем заинтересованным сторонам. Мы надеемся, что собранная нами информация поможет в выборе правильных приоритетов, выработке способов решения проблем и выстраивании процесса разработки с учетом требований к продукту.
Шаг #1: Бизнес цели и целевая аудитория
Определение целевой аудитории (ЦА) имеет первостепенное значение для компании, которая задумывается над созданием EdTech платформы. В настоящее время на рынке представлены продукты для широкой аудитории — от обучающих систем для школьников и студентов, до онбординг решений для сотрудников компаний и пользователей сервисов. Таким образом, формирование четкого представления о своей ЦА — это приоритет номер один. После того как вы определите, кто ваша ЦА, в какой сфере они учатся, работают или ведут свой бизнес, необходимо задуматься над их проблемами, понять, что они хотят, каких знаний им не достает, и чему они хотели бы научиться? Кроме того, изучите, какие у них есть возможности и какие препятствия мешают им использовать эти возможности. Следующим приоритетом является постановка ваших бизнес-целей: какие выгоды вы ожидаете получить от образовательного проекта. Вы должны определить критерии и метрики, которые позволят вам считать проект успешным. Достижение ваших целей должно быть связано с уровнем привлечения к проекту ЦА и их удовлетворенности результатами обучения. От решения перечисленных задач прежде всего будет зависеть выбор форм контента обучения и формирование технических требований к продукту.
Шаг #2: Определение метрик
После формулировки бизнес-целей необходимо выбрать метрики, которые будут применяться для анализа и оценки задач, идей и поведения пользователей на основе полученных данных.
Обычно выделяются следующие группы метрик:
- Бизнес-метрики, которые измеряют влияние пользователей на выручку (продажи) или другие бизнес-цели (выручка, прибыль).
- Метрики привлечения (маркетинговые) — метрики оценки траффика пользователей, которые позволяют измерить эффективность канала привлечения посетителя (цена за клик, цена за платящего пользователя).
- Метрики удержания — метрики, измеряющие как пользователи повторно используют продукт (коэффициент оттока, вероятность повторной покупки)
- Поведенческие метрики, которые позволяют зафиксировать характер и частоту взаимодействий посетителя с продуктом (записался на курс, выполнил тестовое задание).
Метрики каждой группы можно рассматривать отдельно, но ключевые для EdTech проекта важно организовать в иерархии, демонстрирующие зависимости одной метрики от другой. Так, поведенческие метрики оказывают влияние на продажи, а метрики привлечения – на расходы, и обе группы метрик сказываются на показателях бизнес-метрики «Выручка». Как правило, иерархия метрик определяется владельцем продукта и командой индивидуально для каждого проекта (рис. 1). Однако, если создание собственной иерархии вызывает затруднения или проект должен стартовать как можно быстрее, можно обратиться к общепринятым шаблонам, применимым для большинства разрабатываемых систем. Свою полезность на наших проектах доказали такие иерархии как HEART (Happiness-Engagement-Adoption-Retention-Task Success) или AARRR (Acquisition-Activation-Retention-Referral-Revenue).
Считаем нужным отметить, что если бизнес-метрики, а также метрики привлечения и вовлечения стандартны для многих продуктов, то поведенческие метрики в EdTech проектах имеют свои особенности. В качестве поведенческих метрик для продукта, направленного на обучение пользователей, могут служить количественно-временные характеристики, связанные с взаимодействием с контентом (рис. 2):
- Количество пользователей начавших и завершивших обучение (курс или другую контентную единицу).
- Количество пользователей, просмотревших контент за определенный период времени.
- Количество пользователей, выполнивших задания или тесты.
— Время просмотра контента.
— Время прохождения заданий.
— Время ответов на тесты.
Шаг #3: Типы контента
От современных EdTech платформ пользователи ожидают разнообразного и интересного образовательного контента. В настрйщее время мы наблюдаем три основных тренда, оказывающих наибольшее влияние на успешность той или иной образовательной системы:
- Геймификация и общая направленность на создание более мотивирующего контента;
- Агрегация контента из различных источников и формирование персонифицированных подборок наиболее релевантного материала (с учетом текущего уровня знаний, целей обучения, наилучших методов восприятия информации и др.).
- Адаптация обучающих систем и контента не только под использование на стационарных компьютерах и ноутбуках, но и для мобильных устройств (планшеты и смартфоны), что накладывает определенные технические требования на их разработку.
Эти тренды необходимо учитывать заранее, еще при выработке требований к продукту. За последние годы мы разработали несколько образовательных систем для наших клиентов, рассчитанных как на внешних пользователей, так и на сотрудников компаний. Исходя из этого опыта, мы готовы перечислить те типы контента, которые наиболее востребованы у пользователей:
- Обучающие видеокурсы с дополнительными материалами для верификации усвоения знаний.
- Короткие видеоролики с фокусом на раскрытии конкретного вопроса.
- Вебинары как средство взаимодействия с аудиторией онлайн.
- Тематические статьи (руководства, инструкции и другие методические материалы) на наиболее востребованные темы.
- Истории успеха в качестве элементов подтверждения эффективности сервисов.
Борьба за внимание пользователей не ослабевает на на минуту, и EdTech продуктам приходится конкурировать с развлекательными порталами. В связи с этим классические академические материалы желательно сразу переработать с элементами геймификации. Мы пришли к выводу, что наиболее полезным инструментом в этом процессе оказался фрэймворк Octalysis (рис. 3).Этот фреймфорк позволяет достаточно быстро, но не в ущерб качеству, учесть восемь основных поведенческих факторов, которые стимулируют пользователя наиболее эффективно выполнять поставленную перед ним задачу, повышают вовлеченность и удерживают пользователя за счет учета базовой мотивации пользователей и персонализации.
Если наложить этот фреймворк на модель психотипов Ричарда Бартла (рис. 4), то адаптация контента и игровых механик под разные когорты пользователей внутри продукта проходит наиболее быстро и эффективно, а результат позволяет уверенно говорить, что созданные материалы будут удерживать и стимулировать пользователей к достижению целей на основе собственных предпочтений.
Шаг #4: Технические требования к платформе
После определения бизнес-целей, ЦА и форм контента, наступает время формирования технических требований к продукту.
Процессы исследования требований в большей мере зависят от конечных пользователей продукта:
- Если продукт разрабатывается для внутренних сотрудников, то работа будет сводиться к анализу внутренних документов организации (процессов, регламентов), работы с заинтересованными сторонами и встраиванию нового продукта в IT-ландшафт организации.
- Если продукт разрабатывается для внешних пользователей на конкурирующем рынке, то в процессе необходимо адаптироваться под конъюнктуру рынка и слышать «голос клиента», выявлять наиболее предпочтительные формы взаимодействия продукта с пользователем, на основе чего формировать гипотезы по росту продуктовых метрик.
В результате формируется функциональная архитектура продукта (рис. 5), которая соответствует метрикам продукта, удовлетворяет потребностям пользователей и бизнес-подразделений. Она эволюционирует в компонентную архитектуру решения, которая и становится основой для разработки компонентов конечной платформы.
На этом этапе важно не забыть про определение нефункциональных требований к продукту по безопасности, производительности, языковой поддержке и прочее. Эти требования могут существенно повлиять на качество предоставляемого сервиса и на архитектуру решения, переделка которой на поздних этапах разработки или в процессе эксплуатации может существенно повысить инвестиции в продукт.
Шаг #5: Какой подход к разработке выбрать
Разработка на проекте может вестись как по Agile, так и по Watefall методологии. Выбор того или иного подхода, в итоге, зависит от ряда факторов. Если постоянная коммуникация со стейкхолдерами отсутствует или затруднена, а толерантность к рискам изменения требований нулевая, то для создания продукта мы рекомендуем использовать классический предиктивный (waterfall) подход. При всех своих преимуществах (прозрачность и прогнозируемость процесса), данный подход имеет ряд недостатков, одним из которых является долгое время реакции на изменения. Поэтому, если заказчик образовательной платформы не уверен в том, как должен выглядеть продукт на этапе релиза, или, если для принятия решений о развитии продукта, необходима обратная связь от пользователей в том или ином виде, то стоит рассмотреть вариант применения Agile фреймворков.
Проект, в котором Аурига принимала участие в последнее время – разработка новой, геймифицированной версии устаревшего образовательного портала для бизнес-пользователей, – пришлось стартовать в условиях, когда концепция взаимодействия пользователя с продуктом постоянно менялась владельцем. Соответственно, требования к минимальному функционалу системы (MVP) для его первоначального запуска тоже претерпевали существенные изменения. Для этого проекта нами была выбрана Agile-методология с двухнедельными спринтами и частыми релизами продукта. Для ускорения процессов интеграции и запуска, были внедрены также DevOps и CI/CD подходы. Уже на старте портал был рассчитан на нагрузку в более, чем 150+ пользователей ежедневно.
На другом нашем проекте по поддержке и развитии уже существовавшего корпоративного портала обучения для нескольких тысяч сотрудников, наш заказчик довольно точно знал, какой функционал требуется внедрить, так что необходимые требования были собраны заранее, и разработка продукта велась по Waterfall.
Вне зависимости от выбранного подхода процесс разработки сводится к следующим стадиям:
- Уточнение требований и постановка задач на изменение компонент решения;
- Разработка компонент решения;
- Тестирование;
- Установка компонент в продакшн.
Специфика образовательных продуктов также требует отдельно выделить задачи на создание контента и обучение сотрудников для работы с продуктом. Этим можно заняться как параллельно с процессом разработки, так и после релиза продукта.
Выводы
В данной статье мы вкратце перечислили наиболее важные приоритеты и задачи, которые необходимо решать бизнесу, если принято решение о создании собственной образовательной платформы. Показали, как важно уже на начальном этапе правильно определить целевую аудиторию, бизнес цели и построить метрики, а также какие формы контента целесообразно выбирать и почему.
Учитывая специфику задач, разнообразие и особенности EdTech платформ, становится очевидно, что разработку новой платформы лучше доверять компаниям, которые уже имеют наработанный опыт в этой сфере. Тем самым вы сможете минимизировать риски и запустить успешную образовательную платформу. Исходя из многолетнего опыта Ауриги, задачи по системной аналитике, разработке, поддержке и развитию образовательных платформ, безопаснее всего доверить надежному поставщику. Но даже самый продвинутый разработчик ПО не сможет вам помочь, если владелец продукта не может определится с бизнес целями, выбором ЦА и типов контента – эти шаги необходимо пройти самому заказчику.
Однако, мало разработать хорошую образовательную платформу. Не менее, а возможно, и более важно спланировать последующее сопровождение и развитие образовательной платформы таким образом, чтобы увеличивать ее привлекательность и рост бизнес-метрик. Для достижения этих целей может быть внедрен продуктовый подход, который был подробно описан в статье Зачем компаниям продуктовые аналитики.
