среда, 20 июня 2012 г.

Техническое задание на разработку электронного курса

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

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

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

Владимир Наумов отметил две проблемы тендерных заданий:
1. основываются на "шаблонах", не учитывающих специфику учебного процесса;
2. учитывают в основном "техническую" составляющую, которая вводит разработчиков в состояние неопределенности и ведет к непониманию сути запроса инициатора тендера.


В процессе обсуждения нам хотелось представить, если бы у нас был шаблон типового тендерного задания, как бы он выглядел и какие проблемы он смог бы решить?

К сожалению, сразу представить шаблон не удалось, зато «всплыли» проблемы и идеи:
- в ВУЗах всё определяет используемая СДО, а не тендерное задание (академ.сектор);
- не очень понятно, как система может определять выбор (корпоративный сектор);
- хорошо бы увидеть пример(ы) тендерного задания;

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

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

Что нужно знать заказчикам е-курсов:


"Вы покупаете не товары, сырье, материалы, комплектующие, оборудование и даже не услуги в полном смысле слова. Вы заказываете процесс, системообразующим ядром которого является е-курс. Процесс изменения имеющегося сейчас поведения работников на более уместное и оптимальное организационное поведение (академическое образование - процесс формирования готовности к такому поведению)." (Владимир Наумов, источник)

То есть понимание должно быть с обеих сторон — и разработчика, и заказчика. Возможно, тут шаблоном ТЗ не обойтись.

Ранее в Сообществе, обсуждая проблему выбора подрядчика, участники задавали такие вопросы:
- какую информацию должен предоставлять заказчик, чтобы можно было корректно оценить объем работы над курсом?
- на что обращают внимание подрядчики при оценке проектов?
- от чего зависит стоимость и срок разработки различных типов курсов и их элементов? (источник)

Несколько ценных идей и мнений о выборе подрядчика, тендерах и построении взаимоотношений заказчик - провайдер, которые родились в результате дискуссии:
- От недостатка информации для корректной оценки проекта страдает не только подрядчик, но и сам заказчик (Андрей Колоденский)
- Единственный способ сделать качественный курс - проводить подробный анализ ситуации, который может занимать в некоторых случаях несколько месяцев и быть довольно-таки трудоемким (Михаил Протасов)
- Заказчики часто принадлежат к другой профессиональной группе и не понимают нас (разработчиков) в полном объеме (Alexey Kalmykov)
- Пока вы считаете, что возможна внешняя разработка курса - все эти проблемы и будут постоянно возникать, причем решить их не будет никакой возможности, увы... (Постников Сергей)
- Логично сформировать команду провайдеров - самых лучших для нас с читаю такой путь более эффективным, чем "тендерить" на каждый отдельный проект (Тимур Ермаков)
- Необходимо подтвердить проблему неясности задачи с одной стороны и необходимости предоставить точную стоимость и срок реализации, с другой. (Дюсмикеев Андрей)
- ТЗ и Сценарий - это не просто формальный документ для отчетности, это - самостоятельный продукт, которым заказчик может распорядиться по своему усмотрению. Если, например, заказчика не устраивает стоимость разработки, которую выставляет исполнитель, то он может передать ТЗ и Сценарий другому исполнителю, который, по его мнению, может выполнить эти работы дешевле или лучше. (Марина Унгер)
- Если заказчику нужен простой слайдовый курс мы сразу просто предлагаем купить артикулейт (не обязательно у нас) и разработать курс самостоятельно. (Yan Fedyanin)
- Если ранжировать все трудности, с которыми сталкиваюсь при оценке проектов, то на первое место я бы выдвинул проблему отсутствия информации об объеме материала и его статусе: он есть, его нет , его надо собирать из различных источников, есть только презентация и т.д. (Андрей Колоденский)
- Мы обычно просим заказчиков предоставить "первичку" - контент (текст, иллюстрации, тесты, видео,  и др.), смотрим на качество предоставленного материала и оцениваем необходимость и степень его доработки. Кроме того, мы обязательно спрашиваем их пожелания? "Каким Вы себе представляете Ваш будущий курс? (Елена Ходак)
- В 90% случаев, каждый курс реально уникальный. Теперь представьте: есть у вас победитель, представивший лучшую цену за реальный курс. Вы даете ему новый заказ. Ну все равно он будет другим. (Тимур Ермаков)- Предлагай максимальные сроки и максимальную стоимость в расчете на достижение максимальной эффективности (цели проекта). Конечно, такая ценовая модель отпугнет заказчиков временных, но с заказчиком, который сможет смотреть в будущее, получится наладить тесное и продуктивное сотрудничество.  (Дюсмикеев Андрей)
- Лучшее, что может сделать провайдер: 1) показать разработанные ранее курсы, озвучив их примерную стоимость и 2) предоставить прайс-лист на свои работы, объяснив, из чего складывается цена курса, на чем можно сэкономить, а без каких работ обойтись нельзя. (Марина Унгер)
- Хорошо бы поработать над типовым ТЗ на разработку курсов, которые можно отдавать заказчику, над неким механизмом расчета сроков (чтобы заказчик мог ориентироваться при постановке задачи), возможно стоит вместе сделать Code of practice и всем подписать. (Елена Тихомирова)


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

О том, как сориентировать заказчика в стоимости курса: 

 
«Стандартная стоимость 1 часа простого анимационного курса, полностью озвученного - наиболее востребованный формат, который нам сейчас заказывают. Рассчитать объем материала для того курса несложно - он легко определляется в печатных листах. Если речь идет о симуляции или игре, то мы озвучиваем стоимость часа прохождения - эта стоимость одна для флеш-игры, и другая - для игры в 3d-окружении» (Yan Fedyanin)

О том, как сделать курс качественным при разработке внешним провайдером:

 
«В случае, если курс разрабатывается внешним подрядчиком, способа сделать курс качественным я вижу только два: 1. Отдельно оплачивать услуги по анализу ситуации, и только после их выполнения составлять задание на разработку курса.  2. Заказчику полностью брать всю аналитическую и методологическую работу на себя, на аутсорсинг вынося только техническую работу. Стоит отметить, что тот, кто может корректно сформулировать техническое задание, как правило, может и самостоятельно сделать всю работу.
Первым пунктом нужно смотреть, как заказчик формулирует цель. Если цель стоит - разработать курс, то можно либо заранее смириться с тем, что продукт будет некачественным, либо попытаться убедить заказчика изменить цель.» (Максим Протасов)

«Оптимально разбивать работу на 2 укрупненных этапа:
1) Анализ потребностей - Составление ТЗ - Составление сценария.
2) Техническая реализация курса
.
Часто технические требования накладывают ограничения на фантазию сценариста. И наоборот, пока у нас на руках нет сценария, сложно предусмотреть все технические нюансы.
Одна из важнейших задач сценария – оптимизировать бюджет проекта. Именно поэтому при разработке курсов мы достаточно много времени уделяем продумыванию сценария.
При хорошем сценарии без этой красоты можно запросто обойтись без вреда для обучаемых. Однако, именно благодаря внешней привлекательности курса у пользователей создается эффект ВАУ, или, по крайней мере не возникает мгновенного отторжения дистанционного курса.
Что влияет на стоимость технической реализации?
1) Уровень графики (дизайн интерфейса, дизайн самих слайдов/иллюстраций)
2) Каков объем курса (здесь разные параметры - количество исходного материала, итоговое количество слайдов, время на обучение)?
3) Сколько нужно иллюстраций?
4) Нужны ли персонажи? Сколько?
5) Нужна ли анимация? В каком объеме?
6) Нужна ли дикторская озвучка?
7) Нужны ли упражнения для отработки полученных знаний? Или достаточно тестов? Сколько?
Ответы на эти вопросы позволят разработчику указать диапазон стоимости курса» (Марина Унгер)

О том, как проводить отбор разработчиков курсов:

 
«На практике заказчик объявляет конкурс на право разработки курса и просит оценить сроки и
стоимость будущего проекта (не всегда, но чаще всего). Проблема отбора в том, что она происходит по цене и срокам, а не по цели. Идея: проводить отбор исполнителя имеет смысл на конкретных примерах курсов, когда заказчик присылает готовый модуль и просит оценить, какой бюджет и срок потребовался бы потенциальному исполнителю для создания точно такого же курса» (Андрей  Колоденский)

Об Ассоциации разработчиков курсов:

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

Марина Унгер  отметила:  «Основной целью Ассоциации я вижу развитие рынка e-learning. И, мне кажется, именно ради этой цели мы заводим обсуждения и пытаемся делиться своими знаниями и наработками на этом и других e-learning ресурсах. Я бы выделила 3 основных задач Ассоциации: 1) обучение и развитие членов ассоциации (и их команд); 2) обучение и развитие клиентов и 3) невключение недобросовестных провайдеров в Ассоциацию. Мне кажется, что на сегодняшний день, те задачи, которые я обозначила выше, могут решаться с помощью данного ресурса (Сообщество e-learning PRO) и без создания Ассоциации."



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


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

А что Вы думаете по этому поводу?

Комментариев нет:

Отправить комментарий