Книга: e-learning: Как сделать электронное обучение понятным, качественным и доступным
Назад: Глава 14. Завершение проектирования, планирование разработки
Дальше: Эпилог
Глава 15

Разработка — реализация — оценка

picture

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

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

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

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

Коротко о главном

• В разработке используются итеративные циклы, очень похожие на циклы проектирования.

• Предусмотрено четыре цикла:

  • построение
  • производство
  • проверка
  • корректировка

• Каждый цикл дает соответствующий релиз для анализа и обеспечения качества:

  • пробный дизайн
  • альфа-версия
  • бета-версия
  • финальный курс
picture

Цикл построения и пробный дизайн

Цикл построения является первым крупным этапом разработки. Его результатом является пробный дизайн — намеренно неполный релиз, впервые объединяющий все части дизайна. Вы проверяете выполнение всех требований и работоспособность концепции в целом. Что более важно, пробный дизайн позволяет устранить проблемы в самом начале. Разработка контента и медиа ограничена, чтобы в случае изменения направления напрасным оказался минимальный объем работы.

Пробный дизайн обычно имеет следующие характеристики:

Псевдофункциональность

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

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

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

Разработка и использование моделей

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

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

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

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

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

picture

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

Разработка контента

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

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

picture

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

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

Оценка пробного дизайна

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

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

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

«Поздний ребенок»

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

Не беспокойтесь. В каждом плане последовательного приближения резервируются средства на случай подобных проблем и возможностей. Вы должны ожидать и планировать появление как минимум одного «позднего ребенка». Они почти всегда кажутся самыми ценными элементами, придуманными за весь проект. Обычно это не так, но это ваше детище! Иногда их качество бывает значительно выше среднего. Но оценить их в момент рождения, когда они такие свежие и привлекательные, трудно.

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

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

Пятеро!

Слишком много хорошего тоже плохо. Хорошие идеи могут возникать бесконечно. Чем ближе к завершению курса, тем больше новых идей рождается. Поэтому, когда «поздние дети» начинают появляться группами, вам не следует думать, что на этапе проектирования приняты неверные решения или неправильно использовали последовательное приближение. Это естественный ход событий. Но не стоит усыновлять всех «младенцев» подряд.

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

picture
picture

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

Цикл производства и альфа-версия

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

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

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

Внутренние изменения

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

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

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

Оценка альфа-версии

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

Управление исправлениями. Может существовать список известных проблем. Лучше, когда проблем нет, однако некоторые проблемы можно отложить, если их обнаружили незадолго до намеченной даты релиза альфа-версии. Если обнаруженные проблемы не слишком серьезны или не «фатальны» («фатальная» ошибка означает, что программа закрывается или делает что-то неприятное, например повреждает данные), то стоит продолжать заниматься альфа-версией, имеющей список известных проблем. Поскольку целью альфа-версии является всесторонняя проверка качества, не исключено, что будут обнаружены и другие проблемы. Откладывание выпуска альфа-версии из-за незначительных проблем замедляет процесс завершения проекта.

Оценка среды. Иногда из соображений безопасности или стоимости запуска курса в онлайн-сети альфа-версия реализуется только как тестовая сеть. Это плохая практика, так как проблемы могут оставаться невыявленными до тех пор, пока не будет поздно устранять их. В целом альфа-версия или специализированная версия должна использоваться для тестирования работы в сети и взаимосвязи с LMS, если она применяется. Если альфа-версия является частью смешанного решения, ее следует использовать в ходе занятия в аудитории в сопровождении всех дополнительных упражнений, а в контрольный лист следует добавить соответствующие пункты для оценки.

picture
picture

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

Цикл проверки и бета-версия

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

Внутренние изменения

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

Оценка бета-версии

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

Бета-версию нельзя объявлять финальным продуктом, пока не будет установлено, что в ней нет дефектов. После этого бета-версия готова к реализации и тестированию на указанной платформе и объявляется кандидатом № 1 на финальный курс.

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

Финальный курс

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

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

Финальная оценка

Но работа, конечно, еще не закончена. Процесс требует провести финальную оценку.

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

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

Улучшилось ли обслуживание клиентов? Увеличился ли объем продаж? Уменьшилась ли текучесть кадров? Повысилась ли прибыльность? Увеличилось ли количество учеников, поступивших в колледж? Нашли ли наши выпускники хорошую работу?

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

Уровни оценки

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

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

Ниже приведено краткое содержание этапов оценки согласно модели Киркпатрика.

Уровень 1. Реакция

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

Уровень 2. Обучение

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

Уровень 3. Поведение

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

Уровень 4. Результаты

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

Да здравствует последовательное приближение!

Вы справитесь. Наилучшие пожелания и удачи!

 М. А.

Назад: Глава 14. Завершение проектирования, планирование разработки
Дальше: Эпилог