Часто планирование разработки курса происходит следующим образом:
Мы понимаем, что на разработку курса нужно, допустим, три или четыре месяца и назначаем дату релиза, иногда анонсируем это обучение в нашей корпоративной СДО или на портале.
Но на самом деле у нас еще не выбран способ разработки, формат курса или провайдер, нет концепции курса.
Это создает ситуацию, когда к нашему сроку разработки, который в принципе вполне рационально был запланирован, прибавляется еще три-четыре месяца.
Производство - это только часть плана.
Есть очень большая часть процесса, которую нужно запланировать до производства, и большая часть мероприятий, которые необходимо сделать после того, как курс из производства вышел.
До производства
Точную дату лучше назначать после того как:
- мы поняли, какой курс мы хотим, определили идею, концепцию, проверили, что располагаем необходимыми ресурсами;
- провели встречи с ключевыми людьми:
- эксперт. Давайте не забывать, что материалы создаются экспертом. Нужно понять, какие возможности у него есть: не уходит ли он в отпуск как раз во время нашего проекта, насколько он загружен сейчас по своей основной деятельности, сколько времени он сможет посвятить нашему проекту
- бизнес-заказчик: необходимо выяснить, сколько у него есть времени для нашего проекта и на каких этапах потребуется его участие и согласования
- исполнители: внутренние разработчики или подрядчики - с ними определяем, сколько времени занимает качественный продакшн.
Производство
Мы в компании каждую неделю разбираем созданные нами же самими курсы. Сразу можно сказать, какой курс делался быстро, а на какой курс было достаточно времени.
Курсы, которые быстро сделаны - плохо читаются, у них происходит нарушение структуры, потому что над структурой надо подумать, в них может быть больше технических сбоев.
Концепция, которая придумывается на бегу, первая, которая в голову пришла, - редко бывает лучшей и самой правильной.
Если мы делаем быстро, в спешке - мы делаем скучные курсы, курсы, которые не учат.
Один из аргументов, почему так бывает, это отсутствие времени и очень большое давление на исполнителя - неважно, внешний исполнитель, внутренний, или эксперт. Излишнее давление приводит к серьезному снижению качества.
Особенно важно планирование микропрограмм - они еще более зависимы от условий, в которых мы их создаем. Модули должны быть между собой связаны, внутри должен быть материал согласован, у них должна быть общая архитектура. Создать ее - значит “поиграть”, подумать, посмотреть разные варианты. На это нужно время. Если этой архитектуры нет, получается не микромодульная программа, а набор не связанных между собой кусков.
После производства
Пилот
По опыту что можно запустить без пилота?
Стандартный базовый продуктовый курс.
Стандартный курс для вашей компании, если он создается по той же схеме, что и несколько десятков в год других.
Курс по программному обеспечению.
Но если мы делаем курс по ценностям компании или курс по бережливому производству в тот период, когда наша компания масштабно внедряет бережливое производство - такие курсы без пилота запускать нельзя:
- Во-первых, надо технически проверить, что реально сделанный продукт заработает у всей целевой аудитории - в регионах, удаленно, с мобильных устройств.
- Во-вторых, с содержательной точки зрения, мы должны проверить, что не слишком усложнили или упростили материал.
- В-третьих, нужно понять, сколько времени будет уходить на прохождение. Особенно для микромодульных программ это актуально.
Пилот должен быть запланирован как большая вдумчивая активность: кто вошел, когда вошел, когда проходили, в какое время, в какой день назначения, сколько времени потратили.
Чем больше влияние курса на компанию, тем больше внимания необходимо уделить пилотному проекту:
- Нужно обязательно, кроме формального анкетирования, запланировать телефонные звонки тем, кто проходил пилот курса.
- Нужно согласовать курс с руководством. Часто бывает что именно на финальных стадиях запуска курса мы показываем его кому-то из топ-менеджмента, и там возникают новые вводные.
- Нам нужно время, чтобы обработать собранную информацию и принять решение: что мы будем править сейчас, что оставим для второго релиза курса, что оставим как есть.
- И нужно понимать, что правки будут, и на них нужно время.
20-25 процентов времени нужно закладывать на форс-мажор. Это особенно актуально, когда у вас проект связан с технически сложными решениями.
Когда надо срочно
Есть ситуации, когда надо срочно, такое бывает. Тогда надо исходить из этой реальности. Если нам надо что-то срочно, тогда давайте делать так, чтобы это было возможно сделать в эти сроки.
Никто не отменял статьи - хорошо сверстанные, хорошо написанные. Никто не отменял текст и тесты - базовую разработку: она не будет плохой. Никто не отменял использование внешних ресурсов: тот же самый курируемый контент - вообще прекрасная штука.
Если нужен большой, сложный, интерактивный курс, мы можем запланировать его разработку, а в это время начать обучение с простых форматов: с серии лонгридов и короткого видеообращения директора по этой теме. Дальше через месяц запустим модуль курса. Потом - серию мини-игр или тренажеров. Таким образом, мы начинаем быстро и дальше по нарастающей будем усложняем.
Это хороший прием во всех смыслах:
- Во-первых, повторение и закрепление материала.
- Во-вторых, дополнительная практика.
- Плюс - охватили тех, кто еще не был охвачен.
- Ваши модули превратятся в курс - как траекторию, направление обучения, а не отдельный модуль.
- Это agile - все можно поменять, очень много моментов, в которых можно легко то-то подправить.
Многие форматы, которые мы выбираем сегодня для электронного обучения, сами по себе электронному обучению противоречат. Они не гибкие. Когда создавались авторские средства - их задачей было, чтобы не технический специалист мог быстро сделать курс и быстро вносить правки.
В курсах, которые мы делаем, чаще всего поменять ничего нельзя. Если есть история, в истории ничего не меняется. Если мы снимаем дорогое сложное видео - видео вообще не меняется.
Нужно всегда задавать себе вопрос - насколько решение гибкое и насколько быстро его можно модифицировать. Чем больше таких возможностей есть, тем проще сроками манипулировать.
Дата сдачи курса - это не дата запуска курса.
Чем больше люфты, тем меньше нервов.
Чем меньше нервов, тем лучше продукт.
Если вы понимаете что у вас динамичная среда, выбирайте гибкие форматы, которые можно быстро поменять.
Потери от некачественного курса обходятся намного дороже, чем выпустить курс на два месяца позже.