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

Всем привет!

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

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

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

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

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

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

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

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

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

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

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

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

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

Обычно я беру хорошую книгу и пробегаюсь по оглавлению. Оглавление книги – это программа курса готовая на 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 уроков.

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

Но вернемся к 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 часов на программирование системы проверки заданий.
  

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

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

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