Поучаствовал в конкурсе, который объявляло издательство "Директ-Медиа" на разработку электронных курсов. В призеры не попал. Но неожиданно познакомился с хорошим человеком - Юрием Николаевичем Белоножкиным. Он записал меня на свой курс по дистанционному обучению. Выяснилось, что по ходу дела надо написать эссе. Вот и пишу. Будет эссе для курса и черновик для статьи. Называется.
К методологии проектирования дистанционных курсов или грабли, на которые предстоит наступить.
Было дело. И мы руковаживали.
Лев. Шебаршин. "КГБ шутит".
Когда речь заходит о методиках проектирования электронных учебных курсов все толкуют про широко известную методологию ADDIE. Название происходит от первых букв: A (analyze), D (Design), Develop (develop), Implemen (применение), Evalute (оценка). Еще Кухаренко заставлял на ее учить - смутно помню, что сдавал по ней тест. Основная идея методики ADDIE в том, чтобы закончить каждый шаг, прежде чем приступить к следующему шагу. Таким образом, методология ADDIE с точки зрения управления представляет линейную (каскадную) модель разработки.
Засада первая.
Неопределенность в оценке трудозатрат. Это хорошо известный "конус возможностей".
Что тут нарисовано? Коридор ошибок, который имеет место быть на разных стадиях разработки программного проекта. Т.е. на стадии обсуждения базовой концепции решения ошибка в оценке трудозатрат будет составлять +-400%, потом она постепенно снижается на стадиях разработки концепции, утверждения требований.
Хороший пример - прошедший конкурс. Кто-то спрашивал с авторов концепцию курса, не говоря уж про согласование требований. (Концепцию, конечно спрашивали, но исключительно в авторском видении, что имеет мало общего с формализованным процессом разработки концепции). Вообще, есть у издательства какая-то внятная методология работы: шаблоны документов и прочее? То-то ...
Засада вторая
Методология ADDIE - линейная модель разработки. Проблемы с линейными моделями известны. Как всякая линейная модель управления методология ADDIE имеет следующие достоинства:
- модель хорошо понимают все неспециалисты в предметной области,
- проста и удобна в применения за счет того, что все процессы выполняются поэтапно,
- облегает процедуры контроля качества, планирования проекта
и следующие недостатки:
- трудно вернуться назад и исправить неверно принятое решение,
- заказчик (тьютор курса) слабо вовлекается в ход выполнения проекта,
- интеграция всех проектных решений происходит на конечной стадии разработки, в результате может появиться слишком много замечаний, которые трудно исправить задним числом.
В общем, если кто-то из разработчиков не поймет требований, то вернуться обратно будет трудно. Отсюда вытекает и засада третья
Засада третья
Засада третья
Управление требованиями - самая сложная область проектной деятельности. На самом деле мало кто вообще понимает, это про что. Особенно из всяких чтецов многочисленных курсов по управлению проектами, потому что даже профессиональные стандарты не сильно любят эту тему. Как-то это формализовано для ИТ. Дальше - все. Я даже разродился на эту тему статьей.
Но помимо требований, которые можно считать как чисто программные: требования к интерфейсу, к объему контента (количество видео, графики) есть еще педагогические требования. Возьмем для примера курс, где я записан. С интересом прочитал программу курса. Оказывается, что в результате освоения курса слушатель должен получить 11 обшекультурных компетенций и столько же профессиональных. Даже простой арифметический подсчет - 8 модулей против 22 компетенций, дает что в каждом модуле должно воспитаться 2,75 компетенции. Путем написания эссе по каждой теме и болтовни на форуме? Не смешите мои тапки. По идее, должна быть входная и выходная диагностика по каждой компетенции, должен быть ФОС - фонд оценочных средств, которые оценивают, насколько сформировалось компетенция. И вообще, почему я, когда пишу всякие учебные программы, потею над этими ФОСами, а Белоножкин - нет? Где социальная справедливость? В общем, все как обычно - бардак.
Но помимо требований, которые можно считать как чисто программные: требования к интерфейсу, к объему контента (количество видео, графики) есть еще педагогические требования. Возьмем для примера курс, где я записан. С интересом прочитал программу курса. Оказывается, что в результате освоения курса слушатель должен получить 11 обшекультурных компетенций и столько же профессиональных. Даже простой арифметический подсчет - 8 модулей против 22 компетенций, дает что в каждом модуле должно воспитаться 2,75 компетенции. Путем написания эссе по каждой теме и болтовни на форуме? Не смешите мои тапки. По идее, должна быть входная и выходная диагностика по каждой компетенции, должен быть ФОС - фонд оценочных средств, которые оценивают, насколько сформировалось компетенция. И вообще, почему я, когда пишу всякие учебные программы, потею над этими ФОСами, а Белоножкин - нет? Где социальная справедливость? В общем, все как обычно - бардак.
Засада четвертая
Она же самая большая. Засада в том, что при линейной модели разработки 70% процентов трудозатрат падает на стадию сопровождения продукта. Примерно так.
Имеются ввиду многочисленные изменения, которые надо вносить по ходу эксплуатации. По жизни это означает, что издательство, которое заключило с авторами договор на разработку курса, через некоторое время может обнаружить (если доживет), что проблемы еще и не начинались, т.к. заплатить надо в три раза больше. Это вообще хроническая проблема разработки программных продуктов. Заказчик - издательство встанет перед дилеммой, в уже готовом курсе без конца нужны какие-то изменения, и тьюторы курса на это усиленно намекают, мол не соответствует курс теперешним задачам, мол поправить надо бы, мол прогресс же не стоит на месте и новые плагины появились и дизайн бы надо подправить... Если так пойдет, и клиентов можем потерять. Заказчик (издательство) им намекает в ответ: а где деньги на это взять? А то и тролить начнет бедных тьюторов, мол скажите у кого из вас из зар.плату уменьшить - тут же изменения внесем.
Имеются ввиду многочисленные изменения, которые надо вносить по ходу эксплуатации. По жизни это означает, что издательство, которое заключило с авторами договор на разработку курса, через некоторое время может обнаружить (если доживет), что проблемы еще и не начинались, т.к. заплатить надо в три раза больше. Это вообще хроническая проблема разработки программных продуктов. Заказчик - издательство встанет перед дилеммой, в уже готовом курсе без конца нужны какие-то изменения, и тьюторы курса на это усиленно намекают, мол не соответствует курс теперешним задачам, мол поправить надо бы, мол прогресс же не стоит на месте и новые плагины появились и дизайн бы надо подправить... Если так пойдет, и клиентов можем потерять. Заказчик (издательство) им намекает в ответ: а где деньги на это взять? А то и тролить начнет бедных тьюторов, мол скажите у кого из вас из зар.плату уменьшить - тут же изменения внесем.
По-моему, нет особого смысла рассуждать про экономику дистанционного обучения. Так, поумничать, если кто захочет.
Чем лечить?
Пилюля первая
Внедрение технологий проектного управления, переход на проектный офис. Результаты значительно улучшаются. Вот слайд из моей книжки по управлению проектами.
Вот мои личные данные по трудоемкости на различных стадиях выполнения проекта. После внедрения проектных методов.
Видно, что трудоемкость перераспределилась. И это радует, потому, что планирование - это стадия разработки учебного курса. И если сместить на нее часть трудозатрат, то деньги будут расходоваться более эффективно (мы же помним, что заказчик лучше всего платит на стадии разработки). Но до конца эту ситуацию не улучшишь.
Пилюля вторая.
Называется управленческий учет. нужен управленческий учет в разрезе каждого проекта - точнее каждого курса. Больше того, не только в разрезе курса, но и разрезе стадии: разработка, эксплуатация. Но на это мало у кого хватает мозгов (а может терпения). Это позволило бы создавать и отслеживать бюджет каждого проекта. Но есть один большущий минус: надо с бухгалтерией рулиться - вы ее явно не обрадуете своими завиральными идеями.
Пилюля третья
Уход от линейной модели разработки курса к версионной, т.е модели при которой правка курса идет параллельно с его эксплуатацией. Плюс в том, что стадии эксплуатации и разработки идут параллельно и трудозатраты, как и деньги размазываются равномерно по производственному циклу. Компания Микрософт любит такие картинки, объясняя свой принцип работы.
В общем красиво. Но тоже не без проблем. Для версионной модели разработки продукта известны следующие достоинства:
- время разработки каждого цикла можно сократить, благодаря использованию типовых средств,
- возможность провести быстрый изначальный просмотр продукта, что особенно важно там, где требуется визуальное восприятие,
- уменьшаются затраты и риск, связанный с несоблюдением графика,
- заказчик (тьютор курса) постоянно вовлечен в процесс проектирования,
- есть возможность гибко отреагировать на требования заказчика (тьютора курса),
и следующие недостатки:
- необходимо постоянно использовать большое количество обученных и квалифированных разработчиков,
- при разработке требуются тьюторы - энтузиасты и разработчики, готовые работать в жестких временных рамках,
- процесс разработки имеет тенденцию затягиваться,
- требуется высокая квалификация руководителя проекта, который должен сотрудничать как с разработчиком, так и с тьютором, так и пользователем (обучаемым).
- для обеспечения быстрой реакции на пожелания пользователей необходима ускоренная разработка.
Пилюля четвертая
Где-то читал цифры,что несмотря на все ухищрения, доля по миру(!) ИТ-проектов, которые заканчиваются укладываются в бюджет и в график составляет где-то 33%. И не надо строить себе иллюзий. Нужна грамотная работа с рисками. Это по-умному, а по-простому многократное резервирование денег.
И последнее, самое обнадеживающее - все равно все издержки ложатся в конечную стоимость обучения.
PS
Недавно пообщались по скайпу С Юрием Николаевичем Белоножкиным. Поднятая тема оказалась актуальной. Но, увы, далеко не всегда понимаемой так, как я хотел сказать. Возможно тема даже поднята слишком рано.
Поэтому несколько уточнений. 1. По компетенциям. Оказалось, что в профессиональных стандартах компетенции тоже детально прописаны. Поэтому на вопрос о социальной справедливость "И вообще, почему я, когда пишу всякие учебные программы, потею над этими ФОСами, а Белоножкин - нет?" - ответ положительный. Социальная справедливость есть. Мы оба потеем )))
2. Про издательство. Издательство понимается исключительно как пример организации - заказчика. Без всяких претензий на то,что я не попал в число избранных на конкурсе.
Разработка учебных курсов еще далека от той рыночной стадии, на которой давно уже находится рынок программных продуктов. Хотя пост как раз про грабли, на которые предстоит наступить. Но будем считать что неудачливых предсказателей пруд пруди, если автор этого поста пополнит из ряды - никто и не заметит.
Комментариев нет:
Отправить комментарий