Добрый день, коллеги 👋🏼

С вами Осипов Михаил.

Когда мы говорим «давайте проектировать опыт», то сразу создаём то, что на этот опыт и влияет: кейсы, проекты, симуляции, интерактивы и т.д.

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

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

Оба — они друзья.

Но если если сначала делать форму, не зафиксировав систему, мы попадаем в «красиво и интересно, но непонятно — чему научили».

Почему?

Причин несколько 👇🏼

1. Без методологии вы не проектируете обучение — вы проектируете активности

Учебная активность сама по себе не равна обучению.

Интересный тезис, не так ли?

На уровне научной логики это различие между тем, что мы загружаем (например, контент) и то, что в итоге получаем (например, новые знания).

И если мы не формализовали то, что загружаем, то любая активность может выглядеть «успешной» только на уровне продуктовых метрик (NPS, СOR, CSAT и т.д.), но при этом слабо связанной с тем, ради чего программа вообще делается и какой, например, был запрос у заказчика, бизнеса и т.д.

Методологический этап (до проектирования опыта) нужен, чтобы ответить на базовый вопрос:

какое изменение в обучающихся является целевым и как мы это определим?

Полезный источник в пользу аргумента: Understanding by Design (Grant Wiggins и Jay McTighe)

2. Обучение — это работа с конструктами, а не с темами

Тема «управление проектами», «аналитика данных», «критическое мышление» и т.д. — это просто ярлык.

Мы обучаем не ярлыку, а конструктам: конкретным ЗУНам или компетенциям.

Если сперва в программе не определить конструкт (и уровень его освоения), то довольно сложно:

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

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

Научный подход очень прост:

каждую активность надо проектировать как проверяемую.

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

Если этого не сделать, образовательный опыт легко превращается в «дизайн ради дизайна», то есть становится непонятно чему именно научились обучающиеся и почему. А когда изначально существует методологический каркас учебной программы, опыт становится точным инструментом: каждое занятие и задание служит конкретному результату, даёт понятную демонстрацию прогресса и позволяет улучшать программу на основе данных.

Коллеги, а как у вас в проектах❓
Вы сначала выбираете модель учебной программы, а уже потом наслаиваете образовательный опыт — или чаще начинаете с форматов и «упаковки»?

Бизнес-клуб Опора

Друзья, на днях познакомился с основателем бизнес-клуба Опора Ильей Крамником. Очень вдохновило то, что он делает!

У Опоры фокус на молодых предпринимателей с выручкой 10-30 млн в год. Попадая в клуб, предприниматели оказываются в окружении тех, кто находится на том же этапе развития, имеет схожие проблемы, а также общие ценности. При этом второй основатель клуба сильный предприниматель с опытом - это Денис Сметнев (сооснователь Skyeng).

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

Оставить заявку на участие в клубе и почитать про него подробнее можно в боте: @opora_bc_bot

Павел Безяев и команда сообщества Digital Learning

#инфопартнёры

ИИ на твоем компьютере: что это дает e-learning?

Уже сейчас можно купить ноутбук за 1000$, на котором комфортно будет работать достаточно «умная» языковая модель. Да, это не будет топовая модель уровня OpenAI 5.1 (далеко не будет), но её будет достаточно для выполнения базовых задач.

Конечно, редкая компания может похвастаться офисными ноутбуками у сотрудников за 1000$+, но стоимость вычислений постоянно снижается (закон Мура все еще работает, пусть и не так резво, как 60 лет назад). Вполне можно ожидать, что то, что сейчас стоит 1000$, через 5 лет превратится в «обычный офисный ноутбук».

Мы вполне можем сравнивать топовые процессоры 15-летней давности за 1000$+ с современными ультрабюджетниками за 10-20$, и по многим параметрам современная техника будет принципиально эффективнее (а еще 1$ в 2011 году — это примерно 1.5$ сейчас).

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

Так что это значит для e-learning?

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

1. Никаких проблем по линии ИБ
Персональные данные в облако отправлять нельзя, чувствительные — тоже (а именно их, чаще всего, и хочется туда отправить). С локальными вычислениями все эти вопросы снимаются — отправляй все что хочешь.

2. Снижение стоимости масштабирования
Один запрос в ChatGPT стоит копеек. А если у нас будет не 1 пользователь, а, например, 10 000, и если каждый сделает не 1 запрос, а целую кучу? Получится круглая сумма. Локально — все бесплатно*. Как с обычными SCORM-курсами. Хочешь, на 100 человек назначь, хочешь на 10 000 — никакой разницы.
*Конечно, облачные вычисления тоже становятся дешевле, следовательно, и развернуть ИИ внутри контура со временем будет проще, но в любом случае это будет дефицитный ресурс.

3. Bye-bye, согласования бюджетов
Использование облачных API — это всегда «счетчик»: за каждый запрос, за каждый токен нужно платить.
Сколько пользователи сделают запросов? Какой будет их средний размер (тут еще нужно разделять размер запроса и размер ответа)? Ну… можно посмотреть на прошлый опыт и «поводить вилами по воде».
С локальными вычислениями все проще: методист считает, что интеграция с ИИ будет полезна — методист делает интеграцию с ИИ.

4. Работа без интернета
Это скорее бонус, а не общая боль всего e-learning. Если у вас есть специалисты, которые работают где-то, где с интернетом проблемы, — облака им могут только сниться. Локальная модель снимет проблему плохого интернета.

5. Новые возможности персонализации
Звучит как тема для отдельного поста. Если коротко: для персонализации нужны данные. А где их брать? Ваша личная модель может (а скорее, будет) знать о вас все и сама поможет подстроить контент под вас.

6. Рождение новых инструментов
Почему в конструкторе курсов, который вы используете, нет блока* «ИИ-проверка ответа на открытый вопрос»?
*Да, я знаю, что за последний год появились новые игроки, которые сделали такой функционал киллер-фичей своего продукта. Чаще всего это формат LMS+конструктор.

Казалось бы, элементарная функция, которая пишется за вечер (ну, может, немного утрирую, конечно). Но вендоры её не делают. Почему? (Фраза: «Могли бы уже 1000 раз сделать» в данном случае не является гиперболой).

По причинам №1 и №3. Совершенно непонятно, как вы затянете себе все это великолепие в контур и в каком формате будете оплачивать.

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


Итог: ИИ в e-learning перестает быть стратегическим ИТ-проектом, а превратится в обычный методический инструмент. А значит, скорость внедрения вырастет не в разы, а на порядок.

Алексей Миляев и команда сообщества Digital Learning