Как сделать лучший онлайн-курс

Всем привет!

В закладки

Меня зовут Никита Шультайс. Я руководитель небольшой онлайн-школы, автор нескольких дистанционных курсов по IT, профессиональный программист и преподаватель.

Осенью 2019 года мой курс по основам SQL занял первое место в конкурсе Edcrunch Award в номинации "Лучший онлайн-курс, размещенный на платформе". В этом посте я подробно опишу процесс создания образовательного продукта: от идеи до запуска. В первую очередь, это будет полезно тем, кто хочет сделать свой онлайн-курс, но не знает с чего начать.

История от первого лица и полностью описывает мой опыт, но вы можете рассматривать её как руководство.

Итак, запасайтесь терпением и временем, дальше будет много букв.

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

Зачем нужен еще один курс по SQL

Я не первый год обучаю программированию и в конце 2017 года у меня уже было 5 курсов по Python. Хотелось и дальше развивать серверные языки и на очереди стоял PHP 7.

Я начал проектировать программу обучения, писать сценарии и даже выпустил первые 6 уроков. Но когда дошел до баз данных понял, что без умения писать SQL-запросы пользы от PHP немного. Современный сайт без базы данных не сделать. Поэтому я поставил на паузу курс по PHP и решил сделать небольшое отклонение в сторону SQL.

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

Тогда я не подозревал, что новый курс обгонит по выручке курсы по Python и победит в конкурсе.

Цели и программа курса

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

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

Для курса по основам SQL педагогическая цель выглядит так:

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

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

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

Обычно я беру хорошую книгу и пробегаюсь по оглавлению. Оглавление книги – это программа курса готовая на 70-80%.

Некоторые преподаватели начинают курс с истории SQL и баз данных. Это увлекательно, но не ведет к конечному результату. Я же сразу объясняю, что такое SQL и таблицы, и как с помощью SQL получить информацию. В классическом обучении до первого SQL запроса может пройти пару часов. В моем курсе первый запрос студент пишет после первого урока - через 4 минуты 23 секунды.

В начале создания курса, я учился на программе "Система эффективных заданий в дистанционном и смешанном обучении" (доп. профессия для педагогов). Среди студентов было много преподавателей ВУЗов, из них трое также делали курс по SQL. Неплохая конкуренция. Мы обменивались идеями, и они не понимали, как можно давать практику уже через пять минут с начала обучения. Классические преподаватели мыслят другими категориями.

Две лекционных пары, а потом может и допустим в аудиторию с компьютерами.

В практическом обучению это не нужно.

Но вернемся к программе курса. За основу я взял самоучитель MySQL 5 Максима Кузнецова, 2006 года. Книга хорошая, но она скорее похожа на справочник, чем на самоучитель. Пробежавшись по оглавлению, я составил схему из 10 учебных блоков и 50 уроков.

Учебный блок – это законченный фрагмент курса, состоящий из нескольких уроков. Например, "Типы данных" в языках программирования или "Вложенные запросы" в SQL.

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

Для учебного блока про функции в SQL цель звучит так:

После прохождения учебного блока ученик должен:

  1. Уметь изменять полученные данные с помощью функций.
  2. Уметь использовать функции в условиях.
  3. Уметь многократно изменять данные с помощью вложенных функций.

Для отдельного урока про "Сортировку данных" цель такая:

После прохождения урока ученик должен:

  1. Уметь сортировать данные в прямом и обратном порядке.
  2. Уметь сортировать данные по нескольким столбцам.
  3. Уметь применять сортировку совместно с условиями.

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

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

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

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

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

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

Сценарии уроков

Как я сказал выше, курс состоит из 10 учебных блоков и 50 уроков. Каждый урок – это видео на 3-7 минут. Практика показала, что лучше всего писать сценарии сразу для одного учебного блока, то есть в работе всегда от 3 до 10 уроков.

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

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

Но вернемся к SQL. За один урок нужно раскрывать не более одной-двух новых для ученика тем, показать 4-5 примеров, напомнить о важном из прошлых уроков. На это как раз уходит от трех до семи минут или 2-3 страницы печатного текста. Более длинные уроки воспринимаются учениками тяжело, еще хуже вебинары.

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

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

Поэтому написание сценария – самая сложная часть работы, которая проходит в несколько этапов.

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

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

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

Когда все тексты готовы, начинается вычитка. Для этого я распечатываю сценарии, беру красную ручку, начинаю читать и исправлять сложные и непонятные места. Текст на бумаге воспринимается не так как на экране, поэтому важно вычитывать с листа. Иногда в процессе вычитки урок перерабатывается на 50-60%.

Фото сценариев из курса по SQL не сохранилось, но осталась фотография где я работаю над сценарием для курса по Алгоритмам:

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

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

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

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

Вычитка в слух также делает текст разговорным, как будто вы объясняете его другу. Но без слов-паразитов.

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

Запись и обработка звука

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

Для записи я соорудил небольшую студию: повесил на стены акустический поролон, купил микрофон Rode Podcaster с поп-фильтром.

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

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

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

Микрофон я ставлю на расстоянии 20-30 см от себя. Текст читаю с монитора, с бумаги неудобно, приходится постоянно переворачивать страницы, а это лишние действия, высокая вероятность добавить лишних шумов. Микрофон улавливает любой шорох.

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

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

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

Запись звука – физически сложный процесс.

После записи начинается обработка. Обычно на следующий день. Запись и обработку я делаю в Adobe Audition. Сперва звук выравнивается по громкости, а потом пропускается через стандартные фильтры для удаления шумов:

На обработку звука для 5 минутного урока уходит 20-30 минут времени, итого 30-40 минут с учетом записи.

Большая часть времени тратится на вырезание "циков". Не уверен, что это правильное название, но смысл в том, что во рту образуется пузырек из слюней, который лопается и микрофон фиксирует звук, похожий на "цик".

"Цик" на звуковой волне.​

На самом деле, ученики обычно циков не замечают, ведь им приходится следить за происходящим в видео, а так как ~70% информации мозг воспринимает через визуальный канал, то на такие недочеты они не обращают внимания. Думаю, мозг, в принципе, фильтрует "цики", но это не точно. Тем не менее я заморачиваюсь и чищу звук.

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

После записи и обработки звука я перехожу к видео.

Запись и монтаж видео

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

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

Записываю на iMac с в программе ScreenFlow, в ней же и монтирую. Для демонстрации SQL-кода использую SequelPro.

В SequelPro выставлен шрифт Monaco в 20pt, чтобы ученики лучше видели код. Когда найдете оптимальный формат, не забудьте сохранить конфигурацию. Иначе при переустановке ОС придется подбирать параметры заново, пересматривая уроки. Я такой этап проходил, мало приятного.

Перед записью урока я переключаю разрешение на 720p, это по-прежнему HD, но видео получается крупнее и его можно спокойно смотреть на планшетах и больших мониторах.

Как только всё настроено, я надеваю наушники, включаю записанный звук, ставлю экран на запись и повторю всё то, что написал в сценарии.

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

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

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

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

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

1. Замедление видео. Например, вы резко дернули мышкой и курсор проскочил мгновенно. Замедлили в 3 раза - выиграли секунду, да и студенту понятней.

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

3. Разбивка звука. Если видео отстает, то нужно резать звук и сдвигать вправо. Например, я могу сказать: "Запустим SQL-запрос. Как видите в таблице данные выведены в обратном порядке", а в ролике курсор только двигается к кнопке запуска. Тогда я дроблю аудио дорожку и синхронизую звук.

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

Стандартный монтаж урока (изначально и видео- и аудио-дорожки записываются одним потоком, потом всё режется и синхронизуется):

Для запуска кода лучше использовать кнопки в интерфейсе программы, а не клавиатурные шорткаты. Это в работе можно запускать код с клавиатуры, а в обучении это не всегда понятно. Если и использовать шорткаты, то надо говорить: "Запустим код" и вставлять картинку клавиатурного сочетания, предварительно рассказав ученику об этом шорткате.

И не забывайте, что курс смотрят в разных ОС, а клавиатурные сочетания в MacOS отличаются от Windows, да еще и могут меняться при обновлениях программы. Запуск же через интерфейс, как правило, работает одинаково везде. К тому же, такая вынужденная пауза дает ученику время подумать и "сохранить" информацию в мозг.

По необходимости я добавляю в видео дополнительный текст, стрелки, слайды и переходы. ScreenFlow для этого содержит все необходимые инструменты. Слайды я делаю отдельно в KeyNote. Для курса по SQL их было около 15, а вот в более теоретическом курсе по алгоритмам 1150 слайдов и 100 анимаций, и это только половина. На подготовку слайдов уходит в 2-3 раза больше времени, чем на запись и монтаж скринкаста.

Как я сказал, курс записывается в MacOS, но 95% учеников работают в Windows. И в этом нет никаких проблем. Разве что приходится добавлять отдельные уроки про установку MySQL и клиента. И тут главное пройти по всем сценариям установщика и понажимать на разные кнопки, чтобы понять, где возникают ошибки. Установка MySQL одна из самых сложных задач при прохождении курса.

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

Так я определяю, насколько понятным получился урок. На этапе сценария или записи звука это не всегда удается определить, видео – не текст. Иногда урок получается сложным, и его приходится удалить и начать процесс заново – с написания сценария. Так было 5-7 раз.

Также на этапе последнего просмотра исправляются мелкие ошибки: убираются разрывы видео, вставляются подсказки в сложных для понимания местах.

Если урок получился понятным и раскрывает педагогическую цель, то я экспортирую проект в mp4 видео. Настройки экспорта получил методом подбора – ролик получается хорошего качества и занимает 50-100 Мб. Такой урок быстро и недорого раздавать через CDN.

Базовые настройки экспорта для видео 720P в ScreenFlow:

Создание урока длиной в одну минуту, включая написание сценария, запись и монтаж звука и видео, занимает 1 час. То есть на один урок уходит день. В курсе 50 уроков общей продолжительностью в 240 минут – посчитать несложно. Первый курс по Python я делал после основной работы программиста, когда максимум мог выделить 2-3 часа по вечерам, поэтому на запуск ушло полтора года.

Распределение времени при создании урока. По данным Toggl:

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

Практика

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

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

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

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

Схема заданий к уроку выглядит так:

  1. Задание на основе знаний текущего урока.
  2. Здание на основе знаний текущего учебного блока.
  3. Задание на основе знаний всего пройденного материала.

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

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

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

Чтобы упростить работу, я написал скрипт на языке Python, который генерирует таблицы под разные бизнес-задачи: выборка заказов в интернет-магазине, анализ сделок в CRM, заполнение главной страницы музыкального сайта, поиск по базе ГИБДД и т.д.

Скрипт генерирует готовые SQL-запросы для базы данных, а также HTML-таблицы для вставки на сайт. Это сильно ускоряет создание заданий.

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

В этой статье я не буду описывать как создавал автоматическую систему проверки заданий. Это было непростое техническое решение, на программирование которого ушло от 60 до 80 часов. Если у вас нет ресурсов на такую работу, то можно воспользоваться готовыми системами проверки на Stepik или другой платформе.

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

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

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

Если задачу не получается решить даже с подсказками, то ученик может задать вопрос в комментариях и получить ответ от меня или других студентов. На ответ уходит до 24 часов, при этом ученик не тормозиться, а решает другие задания. Так достигается высокая скорость прохождения без задержек.

На создание одной задачи уходит 30-40 минут или ~150 часов на курс.

Поддержка

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

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

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

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

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

Ученик может написать, что курс говно, задача идиотская и сайт глючит, а на самом деле у него опечатка в запросе. Наша задача посмотреть решение и подсказать. А иногда переформулировать задание. В первые месяцы было много изменений и ученики, которые писали самые критичные отзывы стали нашими друзьями. Они делают курс "железобетонным".

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

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

В общении с учениками я стараюсь не употреблять слова "ошибка" или "вы неправы". Это грубые формулировки. Гораздо лучше: "вы почти справились с задачей, но есть небольшой недочет". Или просто указать на проблемное место.

На поддержку уходит 10-30 минут в день: небольшие сессии утром, днем и вечером. В выходные, праздники или в отпуске: только по утрам или вечерам.

Поддержка учеников за три часа до старта Амстердамского марафона из аутентичного голландского домика:

В новогодние праздники поддержкой занимается Дед мороз. Это помогает разнообразить ответы и добавляет настроения в комментарии:

Если вопрос задали 5 минут назад я не спешу отвечать, часто ученики сами доходят до решения после короткой паузы и чашки чая.

В целом, у нас отличные ученики, которые помогают развивать проект. За это им большое "СПАСИБО"!

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

Куда двигаться дальше

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

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

Я точно не замерял, но по ощущениям в течение 2-х лет курс обновился на 20-30%. Это относится как к видео, так и к практике.

Эпилог

Если сложить всё вместе, то на создание курса ушло более 470 часов:

  • ~240 часов на уроки: сценарий, звук, видео;
  • ~150 часов на практику: тексты и таблицы;
  • ~80 часов на программирование системы проверки заданий.

Еще небольшая сумма пошла на дизайн: лендинг и интерфейсы.

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

Любые вопросы пишите в комментарии. Постараюсь ответить на всё.

Материал опубликован пользователем.
Нажмите кнопку «Написать», чтобы поделиться мнением или рассказать о своём проекте.

Написать
{ "author_name": "Никита Шультайс", "author_type": "self", "tags": [], "comments": 0, "likes": -1, "favorites": 5, "is_advertisement": false, "subsite_label": "learn", "id": 111442, "is_wide": false, "is_ugc": true, "date": "Thu, 19 Mar 2020 17:24:51 +0300", "is_special": false }
0
Комментариев нет
Популярные
По порядку

Прямой эфир