Websoft

понедельник, декабря 29, 2008

Знания, умения, сырые помидоры и бритва Оккама

Нынешнее состояние дискуссии о предпочтительности курсов, созданных в средствах ауторинга или уникальных флешовых и 3D продуктов, с одной стороны, и о целесообразности разработки таких курсов силами аутсорсеров или внутри компаний, с другой, напоминает совет О. Бендера гражданину Корейко: «Очень прошу вас, не ешьте на ночь сырых помидоров». Остап Ибрагимович сумел продемонстрировать «заботу»о благополучии «клиента», но не взял на себя ответственности пояснить, к каким последствиям – позитивным и негативным - употребление таких помидоров может привести.

1. Требование объективности вынуждает признать, что ни одно мнение в упомянутой дискуссии не может расцениваться с позиций «правильно-неправильно» или «истинно-ложно». Здесь куда уместнее принцип «полезно-бесполезно» или «эффективно-неэффективно».
Пока никто еще экспериментально не доказал, что «стандарнтый» текстово-картиночный курс передает знания, умения и навыки хуже или лучше, чем анимированный или 3D'ешный. В этом случае уместно опираться на принцип экономии (бритву Оккама):
из нескольких альтернативных подходов выбирается наиболее простой.

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

Кстати, об этом говорит и практика. Факты подтверждают справедливость принципа Оккама: «стандартные решения» реализуются в десятки и сотни раз чаще штучных. Более того, эксклюзивные разработчики либо сами нещадно используют средства ауторинга, насыщая их флешем и даже 3D, или адаптируют свои уникальные продукты, «сделанные ручками» под требования LMS заказчика.

На практике же пусть цветут все цветы.

2. Присоединяюсь к предновогоднему ожиданию Ирины Деточки «А кто-нибудь в следующем году в компаниях предполагает не просто создавать контент, а развивать навыки и менять поведение сотрудников?» Сам того же жажду.
Однако одного желания маловато будет, поскольку не только наличие контента, но и факт обучения не ведут к автоматическому применению изученного на практике тотчас после «выпускного вечера». Электронное обучение, если оно даже успешно состоялось, не может, не способно по определению 100-процентно гарантировать выплощение изученного (практическую деятельность). Здесь нужны иные решения, часто организационные, а не сугубо учебные. Над поиском таких решений мы и работаем. И не столь здесь важно, покажем ли мы про то, как надо действовать сотруднику, супераховый мультик или скромное слайд-шоу, сделанное в средстве ауторинга. Собака зарыта в механизмах перехода - безразличных к способам создания и предъявления контента - от изученного к его применению на практике. Обучение способно обеспечить лишь потенциальную возможность последнего. А это "последнее"- прерогатива педагогического, а не визуального дизайна или эргономики, которые либо способствуют, либо мешают достижению нужных измененией образовательными средствами.

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

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

Желаю всем участикам процесса сосредоточиться на этом в наступающем году.

9 комментариев:

Дюсмикеев. МедиуМ комментирует...

Спасибо, Владимиру Валентиновичу за труд! Что касается меня, то интерес к обсуждению проблем "эффективно-неэффективно" :) пошел на убыль.. может потому что мы - ремесленники, а не художники ;)
Яну. Нужно развивать блог разработчиков.. В новом году приложим свои усилия!

Каллиников Павел комментирует...

Позвольте поздравить всех участников обсуждений на этом блоге с наступающим новолетием и Рождеством!
Всех вам (нам) благ :)
И побольше талантливых решений в среде e-learning!

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

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

Так что - таки да - пусть расцветает тысяча цветов.

Еще раз - с праздником!

Владимир Наумов комментирует...

to Павел Каллиников:
Избыточность избыточности рознь. Одна, действительно, обеспечивает устойчивость процесса и, главное, результатов обучения (и это тема для отдельного разговора), другая - напротив, уводит обучение от существа дела, о чем, в частности, в свое время писалось здесь: http://websoft-elearning.blogspot.com/2007/06/blog-post_25.html#links

andrey firsov комментирует...

inВот наконец, вы в своих рассуждениях упомянули мою любимейшую филосовскую концепцию - лезвие Оккама, любимую с времени прочтения "Лезвие бритвы" Ефремова.
Но я всегда воспринимал его постулат в виде "не умножай сущностей", а не в виде "отрезай лишнее", а это, по моему мнению, не одно и то же...
Давно порывался написать, да все стеснялся, пока про Оккама не упомянули.
Вот Ян, к примеру, высказал мысль, что сложные проблемы не могут иметь простых решений. Я в корне с этим не согласен, хотя, возможно, сужу как технарь, а не как гуманитарий... Сложные проблемы могут иметь ТОЛЬКО простые решения. Это известно человечеству со времен гордиева узла. Утверждение доказывается хотя бы тем, что доказать, что последовательность шагов является решением, можно тогда, когда или задача, или решение является простым, т.е. алгоримизируемым, и проверка - процесс осуществляемый. Если ни проблема, ни решение не поддается анализу - то это чистая эвристика. Это не решение - просто некая последовательность шагов, приводящая к решению в данном конкретном случае - и не более....
Прошу прощения за смеш в следующем, но давно не писал - а хотелось.
Вот вопрос со средствыами быстрой разработки - нужны оли нет, вредны они или нет... А достаточно просто спросить, например, наших заказчиков - готовы ли они отказаться от опции поставки исходников заказных курсов? Один этот вопрос в состоянии изменить тон дискуссии...
И напоследок (прошу прощения, Ян, камень не в Ваш огород, просто в тему пришлось). Следуя вышеупомянутому принципу Оккама, при решении проблем следует выбирать соответствующие решения. Вот мы имеем курс по ПОД/ФТ (ФЗ-115 - дай Бог здоровья авторам закона - они сделали для российского корпоративного e-elerning'а гораздо больше, чем кто-либо еще :-) ) - я ничего не смыслю в педагогическом дизайне, возможно курс сделан безупречно с данной точки зрения, но... для кого он? Я не знаю ни одного финансового учреждения, кому бы был нужен такой курс... Система тестирования и учета результатов тестирования по ПОД/ФТ - да, она нужна. Автоматизация процесса назначения такого рода обучения и проверки его результатов - да. А вот именно сам курс, пусть даже безупречный с точки зрения педагогического дизайна - не знаю... Возможно это просто мой изъян, как практика - слишком узкий охват заказчиков...

Каллиников Павел комментирует...

Владимиру:
Если заранее знать какая избыточность полезная, а какая вредная, то это уже будет не избыточность, а вполне детерминированная информация, из которой в соответствии с бритвой Окамма вполне можно извлечь важные сущности, а остальное оставить за бортом.
Суть избыточности, на мой взгляд, в сознательно привнесенной хаотичности. Хаос - обоюдоострое оружие. С одной стороны, это беспорядок (что для нас - плохо), а с другой - потенциальная возможность выбора любого ДРУГОГО вида порядка. Вот этот потенциал - и есть спасательный круг в непредвиденных ситуациях.

Поэтому все сложные системы (включая наш мозг) избыточны.

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

Впрочем, это вряд ли удастся почувствовать на объеме одного курса. Хотя, библиотека из 100 курсов уже дает материал к подобным выводам :)
А еще лучше это чувствуется при создании объемной и масштабируемой электронной энциклопедии. Я не имею в виду Википедию - там все еще сложнее. Но у меня до сих пор болят шишки, набитые при разработке "Русского биографического словаря" и "Русской портретной галереи".:)

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

andrey firsov комментирует...

to Павел:
В том то и дело - нащ мозг избыточен, и тем не менее, используя от 1 до 10 процентов его потенциала (тут разные исследователи приводят цифры, отличающиеся на порядок - что само по себе показательно), мы в состоянии решать достаточно сложные задачи.
Моя трактовка лезвия такова: если систему можно описать, с некоторой погрешностью, n-ым количеством сущностей, то не надо не только анализировать, но даже искать n+1. На возражение о том, что потом в процессе оказывается, что погрешность была задана неверно и задачу приходится решать заново, есть ответ - легче два раза решить задачу с ограниченным набором входных данных, чем пытаться учесть то, что не поддается анализу...
Кстати, упомянутые тут где то, системы с обратной связью так и строятся - объект рассматривается как черный или серый (минимальное количество известных зависимостей) ящик. несмотря на миимум знаний об объекте получаются очень устойчивые решения...
...хотя иногда - и очень неустойчивые :-)

Каллиников Павел комментирует...

Андрею:

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

Что же касается антиокаммы, как принципа. То он тоже может иметь практическое значение (ИМХО).
Вот мы в своих курсах вводим контекстное обращение изнутри курса к внешним сервисам интернета. Т.е. чисто плодим сущности сверх необходимого. Обращение к статье Википедии по теме курса может ведь не только подтверждать мнения автора курса, но и противоречить ему.
Но методическая ценность (опять же ИМХО) такого приема заключается именно в развитии у студента способности сопоставлять разные факты, разные определения одного и того же.
Это пример, когда элементы хаоса играют полезную роль.

andrey firsov комментирует...

Павел, что касается педагогической и методической ценности - это не ко мне, это к Наумову :-)
Я в этих материях полный ноль....
Хотя по поводу Википедии могу сделать коммент - в корпоративном обучении это ни разу не пойдет (чистое ИМХО, конечно)... Во-первых - интернет, во-вторых - в корпоративке - как в армии: любят точность и однозначность формулировок...
Что касается невозможности решать проблему несколько раз, то мое мнение - это иллюзия чистой воды. я видел достаточно проектов, в которых пытались учесть столько всего, что ресурсов, которые тратились на выявление всех исходных данных, с лихвой бы хватило не то, что на два - четыре раза задачу решить... тем более, что даже после такого анализа решение во многих случаях на ходу корректировать все равно приходилось...

Каллиников Павел комментирует...

Андрей, я не имел в виду корпоративное обучение. По крайней мере, продуктовые курсы.

Что касается проектов и их повторного решения, то у нас, видимо, не во всем совпадающий опыт.
Есть, например, такие долгоиграющие гуманитарные проекты с мерцающим финансированием :) Т.е. такие проекты, где хаос заложен уже изначально.
Представьте, что надо сконструировать самолет, которому гарантированно хватит горючего только на взлет и набор высоты. А дальше он должен лететь с неизвестным (постоянно меняющимся, в т.ч. до нуля) расходом топлива.