Вопросы, которые стоит задать поставщику технологий
1. Идеология инструмента: почему и зачем его создавали? Как разработчик понимает цель его использования? Эти вопросы помогут вам сформировать представление о компании-разработчике, о том, насколько она в курсе насущных вопросов обучения, и сформируют общее представление о том, как данный инструмент будет развиваться в дальнейшем.
2. Что разработчик предпринимает для того, чтобы пользоваться системой было удобно? Каким было последнее изменение? Это хитрые вопросы. В ответ могут прозвучать общие слова, а могут и конкретные примеры: «Была кнопка такая-то и там-то, людям было неудобно, и мы сделали так-то…» Нам важнее всего, чтобы пользователям было комфортно, так что нужно послушать, что на эту тему думает разработчик.
Далее, говоря про каждый инструмент, я буду отдельно отмечать необходимость его предварительно опробовать. Но сначала скажу в целом: не стоит приобретать что-либо, пока вы не «потрогали» его своими руками. Любой поставщик дает такую возможность: демоверсии, доступ к тестовой системе на сервере заказчика или какой-то иной вариант. Но попробовать нужно обязательно. И не просто посмотреть, как система/инструмент выглядит, а именно попробовать ее использовать: организовать небольшую тестовую группу, которая пройдет курс или тест и примет участие в вебинаре. Пусть это будет всего пять человек (вы в том числе). Часто систему – особенно это касается систем дистанционного обучения – просто изучают в сопровождении комментариев поставщика или делают пару снимков с изображением компьютерной части курса. Но в процессе эксплуатации все может оказаться не так просто, как показалось при беглом рассмотрении.
Так называемый пилотный проект нужно прописать, сделать сценарий, который формируется на основе ваших задач обучения и исходя из процесса, который вы планируете запустить. По сути, пилотный проект будет миниатюрой всего вашего будущего e-learning. Далее нужно полностью пройтись по сценарию, а потом по нему же собрать обратную связь от всех участников пилота – что и на каком этапе было удобно, а что нет. Хорошо, если все этапы сценария получат свой уровень значимости для проекта и что-то будет критически важным, а что-то нет. Тогда по итогам обработки полученной обратной связи вы легко увидите, есть ли что-то неудобное в самых важных функциях или нет. Те функции и возможности системы, которые не имеют особого значения, могут быть и не самыми удобными. Но то, что будет использоваться большим количеством людей и постоянно, должно работать корректно, быть комфортным и понятным.
