Как мы разработали веб-платформу для обучения онлайн

Как всё началось

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

Тогда преподаватели перевели свои занятия в онлайн, однако здесь возникли новые трудности. Занятия приходится проводить в Zoom или Instagram Live, а обновлять расписание и вести запись в другом месте. К тому же необходимо организовывать оплату, которая возможна только в виде донатов. Очевидно, что с точки зрения бизнеса такая схема мало эффективна. С такими вопросами столкнулась предпринимательница и тренер по йоге Кейт. Это вдохновило её создать платформу для обучения онлайн, которая объединяет все эти функции. Кейт обратилась к нам за веб-разработкой, и уже через три месяца мы выпустили готовый продукт. Рассказываем, что у нас получилось, как организовали работу и что планируем делать дальше. 

Решение

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

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

Когда ученики покупают доступ к разовому занятию или подписку, их контакты появляются в Student List. Также учителя могут приглашать учеников начать пользоваться платформой и экспортировать данные, например, для email-рассылок.

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

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

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

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

Ученики выбирают подходящий формат оплаты — разовые занятия или подписка на определённый период. Отдельным блоком выделено ближайшее занятие.

В календаре преподавателю и студентам видно расписание ближайших онлайн и офлайн занятий.

Этапы проекта

Условно процесс разработки проекта можно разбить на 4 этапа: подготовка к проекту, веб-разработка, отладка и сопровождение.

Подготовка. В течение двух недель мы выбрали технологии, определили функциональность, утвердили формат управления требованиями и сторонние сервисы (сервис Stripe для приёма и обработки электронных платежей).

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

Отладка. Зафиксировали функциональность, тестировали и отлаживали в течение трёх недель. Готовили платформу к запуску.

Сопровождение. Отвечали на вопросы, правили мелкие баги.

Что помогло нам добиться нужного результата

Единое пространство

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

Результат: получился командный инструмент, который помогает упростить и ускорить коммуникации.

Управление фичами с помощью User Stories

Поскольку у нас был зафиксирован бюджет и срок, мы маневрировали фичами. Для управления выбрали формат User Stories. Описали их дискретно — чтобы каждая User Story не зависела от других. Это помогло гибко ими управлять. Поэтому когда требования менялись, мы были к этому готовы. Например, мы столкнулись с такой ситуацией, когда меняли схему платежа. В процессе разработки благодаря нашему итеративному подходу и регулярным демо заказчик осознал, что удобнее вести расчёты с клиентами по-другому. Это не застало нас врасплох — мы быстро актуализировали требования. В этом нам помог процесс изменения требований и, в частности, User Stories. 

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

Спринты были двухнедельные, но из-за интенсивной разработки приоритизировали фичи каждую неделю. 

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

Результат: прозрачное и гибкое управление User Stories позволило нам выявить и своевременно реализовать наиболее важную функциональность.

Адаптация процессов

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

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

Макеты по Agile

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

Результат:

• Макеты частично использовались как ТЗ, что помогло ускорить разработку. 
• При изменении требований потребовалось меньше доработок макетов. 

Регулярные демо  

Мы регулярно показывали клиенту результаты разработки веб-платформы. Даты демо зафиксировали в вики. Демо скрипты формировали в начале спринта и использовали их для тестирования.

Результат:

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

Daily notes в чате

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

Результат: митинги стали занимать 5-10 минут.

Что у нас получилось

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

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

Стек технологий

Server: PHP 7.3, PostgreSQL 12, Redis, Nginx, Laravel 7, Stripe

Frontend: Vue, vuex, vuetify, theoplayer, sockets.io, WebRTC, HLS, RTMP, Wowza