Alfa, Beta и Стоп-кран! Подход к повышению качества курсов.

Автор: Павел Безяев
Наверное, многие из тех, кто разрабатывают курсы сталкивались (или обязательно еще столкнуться) с тем, что или Заказчик сам не понимал до конца цель электронного курса или эксперта назначил такого, что увёл совсем не в ту сторону… Особенно ярко проявляется ситуация, когда вроде и с заказчиком несколько раз Цель прояснили и с экспертом концепт проработали и сценарий согласовали со всеми, а когда сделали первую версию курса всех словно «прорывает» — дали не то и не тем, не так и не тогда и «вообще, мы поняли теперь что хотели». Если вы работаете с внешним заказчиком, то такая ситуация может означать конфликт с заказчиком, затягивание сроков сдачи, работу себе в убыток и штрафные санкции. Если это внутренний заказчик, то это может, например, ударить по доходам разработчиков, когда производительность жестко зашита в KPI (или планы отдела). Понятно, что такие ситуации не очень хорошо сказываются и на мотивации команды. Инстинктивное желание сделать всё, что бы обезопасить себя – не делать лишних шагов (самой разработки), пока цели, задачи и сценарий не согласованны на 150%. Многие так и делают – формализуют отношения с заказчиком, через хитро продуманные заявки на разработку, протоколирование интервью, регламентированные согласования. Спору нет – такой подход поможет доказать, что курс сделан в соответствии с договорённостью, но не гарантирует, что это тот курс, что нужен в данный момент целевой аудитории и заказчику. Почему? Потому что есть ситуации, когда что бы увидеть Цель ясно надо начать двигаться, даже если есть большая вероятность, что движешься не совсем в идеальном направлении. Мне сегодня привели хороший пример – например, ты находишься в огромной захламленной комнате и совершенно не представляешь где выход, можно сколько угодно планировать, как выйти из этого лабиринта, но все это будет лишь гипотезой, пока ты не сделаешь несколько шагов и случайно не увидишь комнату с такого ракурса, который покажет направление к выходу. Вот и с курсами – можно сколько угодно применять красивые методы для выявления потребностей заказчика и продумывать методические подходы для реализации, но первый же просмотр или пилот может показать «дверь» совсем в другом направлении. Если у нас «прикрыты тылы», то можно конечно оставить всё как есть, но мне видится что глобальная Цель того, кто делает Настоящие Курсы не в этом. Варианты? Пока мы придумали схему, как действовать с внутренними заказами (при условии, что нет чрезмерно сжатых сроков – чей-то «пожар» это отдельная тема). Необходимо ввести систему Alfa и Beta версий курса. Alfa версия это некий набросок курса, который увидит узкий круг людей – заказчик, эксперты, методисты, коллеги и который может открыть совершенно отличный путь или даже показать несостоятельность заданной Цели. Разработчики уже знают, что это будет не их провал и выполненная заря работа, а очень важный этап в создании действительно ценного курса. Beta версия это версия которая выходит на пилот – на небольшую группу представителей целевой аудитории, которые дают первую обратную связи и позволяют определить чего не хватает для полноценного релиза или подтверждают полную готовность курса.   И тогда в плане отдела дистанционного обучения уже можно указывать не просто количество курсов, которое надо сделать за месяц (или квартал), а количество версий курсов. Кажется это уже мелочь, но как это всё меняет. Например, мы хотим сделать идеальный курс по продажам, включаем его в планы, а после на пилоте понимаем, что ушли не туда (сами понимаем, но легко можем убедить заказчика). Вариантов у нас два – оставить все как есть и получить премии, но недовольных сотрудников (что всегда вернётся, но чуть позже) или остаться без премий и еще два месяца «доделывать» курс, как некий долг отдела. Получается некрасивая история со всех сторон, но уверен, что во многих компаниях часто так и выходит. А если мы бы сразу договаривались о версионности и закладывали в план на месяц сначала Alfa, а потом уже Beta версию и релиз, то вся история гораздо интереснее для всех. При этом никто не отказывается от идеального варианта, когда Alfa-версия становится релизом, но при этом без вынужденного обмана.

Кстати, на поиск этой идеи я вдохновился после очередного участия в клубе «Хорошее время читать». И снова впечатлила книга о Японских подходах к менеджменту, но на этой раз докладчиком был не я.  В книге «Дао Тойота» рассказывается об основных принципах менеджмента ведущей компании Мира. Есть там принцип №5 — «Сделай остановку производства с целью решения проблем частью производственной культуры, если того требует качество». Этот подход позволяет любому (любому!) сотруднику остановить весь конвейер, когда он замечает какой-то брак (у них есть для этого специальные копки). Для нас это может звучать дико – как можно доверить остановку производства субъективному мнению одного человека, а если ему просто показалось? Но практика показала, что это гораздо выгоднее, чем выпустить целую партию бракованных изделий, пока вопрос об остановке будет согласовываться с руководством. Есть и другие плюсы, но это отдельно. В общем, вчера я понял, что нажму «Стоп-кран» и остановлю «конвейер» по производству интерактивных курсов пока не поправлю вопрос качества. Остановил, подумал, посовещался, услышал идеи и теперь можно запускать снова, но уже совсем другой конвейер! :)

Удачи в поиске качества!
Источник