Какие ошибки вы допускали при разработке и запуске онлайн-курсов?

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

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

Ошибка 1: Не заведена роль PM.

Ситуация 1: думалось, что это неважная роль и ребята сами могут встречаться с заказчиком. Выяснилось, что методист и разработчик  - роли больше интровертные. А встреча с заказчиком и экспертом - дело важное.

Решение: Если хотите возложить на эти роли переговоры с заказчиком (интервью, брифование) - обсудите это с кандидатами на этапе приемки, научите их это делать правильно (создайте чек-лист для интервью, например). В противном случае, будьте готовы делать эту работу самостоятельно, в этом тоже нет ничего плохого, но на это нужно время.

Ошибка 2: Методист и разработчик могут вполне заменять друг друга, принцип взаимозаменяемости, так сказать, чтобы они обе могли делать курсы - параллельные конвейеры. 

Ситуация 2: Методиста я нашла в базе выпускников курса "Разработчик курсов", рекомендую, кстати. Разработчика обучила с 0 из соседней со мной команды. Итого - у меня два сотрудника в команде с навыками разработки курсов. Почему бы не сделать 2 конвейера вместо одного, чтобы каждая из них могла тащить проект с 0 и работать с дизайнером. Чтобы разработчик и методист были профи в своей области, обязательно каждой роли надо держать руку на пульсе и общаться со своими сообществами. Когда на 1 роль я наложила двойную работу: и методист и разработчик курсов, сотрудники вынуждены были держать себя в боевой готовности сразу по двум направлениям - и разработка кура (отслеживание новинок в iSpring) и в методической деятельности (циклы Колба, метод обратного дизайна и т.д.). Оперативной памяти у одной из них не хватило и от этого одна из них выгорела и ее проект встал. 

Решение: Развести роли методиста и разработчика по разные стороны и устраивать командные мастермайнды на тему разработки курсов. Теперь методист отслеживает свою область и комьюнити, разработчик - свою. Введены общие брейнштормы 2х часовые до разработки курса (после получения ТЗ от заказчика) и после первой сборки. В них участвует вся команда - и дизайнер и переводчик, потому что как выяснилось, у всех разное видение - одна видит орфографические ошибки и сильна в этом, дизайнер понимает общую концепцию и что должен нести слайд (какой посыл и идея). Я мониторю логичность и соответствие контента задаче обучения. Разработчик смотрит глазами - как это оформить: интерактивность или анимация. Методист отвечает за разгрузку слайдов и ясность мысли.

Ошибка 3: Думать, что под любую ситуацию нужно обучение.

Ситуация 3: К нам вышел заказчик от одного из отделов, чтобы сделать курс по процессу установки модуля бронирования на сайт отеля, потому что руководителю команды прилетает много вопросов и 50% времени идет разъяснение, что и почему, при наличии регламентов. Во время брифования я решила копнуть дальше и понять - от кого такие запросы (какая ЦА), какие это именно запросы (сама формулировка) и почему регламенты не работают.

Решение: Увидев картину - мне стало понятно, что: вопросы задают ребята, не работающие с процессом установки модуля, такие задачи ставит другой отдел, и создавать задачу напрямую они не должны сами. Делают они это потому, что  ответственный отдел перегружен и берет такие задачи в течение определенного срока. Я собрала большую встречу между тимлидами команд, чьи ребята ставят задачи и чьи ребята не должны ставить задачи, но пытаются, вместе с заказчиком. В итоге -от курса мы отказались, тимлиды эту ситуацию проварили и все стало у всех хорошо и без нас. И это еще раз к вопросу, почему важна роль РМ в команде.

Ошибка 4: Работать без брифа и составления ТЗ, не обсудив загрузку с экспертом.

Ситуация 4: Свете надо курс, эксперт по курсу Иван. Мы Свете Окаем, что беремся за дело. Идем к Ивану, а Иван такой: "а у меня нет задачи на разработку курса в этом PI, идите в следующий PI". Мы к Свете - а она такая, а как мы тогда будем продавать новый продукт, если мы его не знаем?

Решение: Выходите на PI, будьте рядом с бизнесом и старайтесь быть на всех планированиях, чтобы понимать, какой продукт выйдет завтра и какие проблемы есть у бизнеса. Если у вас кто-то выступает экспертом - прежде чем Окнуть заказчику, обязательно убедитесь в том, что эксперт готов работать с вами, чтобы все было в срок и четко. Мы сделали бриф, который теперь каждый заказчик заполняет перед работой с нами и указывает фамилии всех экспертов и проверяющих.

Итого. Создание таких команд и работа в области разработки курсов - дело для российского рынка относительно новое и очень быстро меняющееся. Обязательно нужно быть с комьюнити и задавать вопросы, чтобы не повторять ошибки. Нет тут какого-то правильного регламента по работе, надо просто брать и делать, пробовать разные форматы и распределение нагрузки. Очень хорошо помогают разборы "Под капотом" - ты можешь за час- 2 посмотреть разные варианты курсов и развить свою надсмотренность. В разработке курсов надсмотренность - один из ключевых критериев, хорошо, что многие школы открыты и делятся экспертностью.