Парадоксы в статистике: парадокс Симпсона.
Парадокс Симпсона — это когда выводы из данных выглядят по-разному, если смотреть на группы отдельно и если их объединить.
Давайте разберем на примере (скрин №1). Мы сделали программу адаптации для продавцов B2C и продавцов B2B. После прохождения программы замеряем средний процент выполнения плана и видим, что продавцы B2B справляются с выполнением плана лучше (99.5% против 87%). Делаем вывод, что программа адаптации для продавцов B2B более качественная.
Но, если мы разделим наших новых сотрудников на тех, у кого был ранее опыт работы в продажах, и сотрудников без опыта, картина получится ровно противоположной (скрин №2). Здесь мы видим, что продавцы B2C как с опытом работы, так и без, после прохождения программы адаптации, делают более качественные продажи, чем продавцы B2B, следовательно программа адаптации для продавцов B2C более качественная.
Парадокс Симпсона показывает, как важно учитывать детали в статистике. Статистические данные могут вводить в заблуждение, если рассматривать их без учета всех факторов.
На конференции Digital Learning 2025 одной из самых обсуждаемых тем стали бизнес-метрики (ИИ они, конечно, не переплюнули, но в тройку тем точно вошли). В ходе обсуждения вспомнил несколько любопытных парадоксов в статистике, об одном из которых хочу рассказать.
Парадокс Симпсона — это когда выводы из данных выглядят по-разному, если смотреть на группы отдельно и если их объединить.
Давайте разберем на примере (скрин №1). Мы сделали программу адаптации для продавцов B2C и продавцов B2B. После прохождения программы замеряем средний процент выполнения плана и видим, что продавцы B2B справляются с выполнением плана лучше (99.5% против 87%). Делаем вывод, что программа адаптации для продавцов B2B более качественная.
Но, если мы разделим наших новых сотрудников на тех, у кого был ранее опыт работы в продажах, и сотрудников без опыта, картина получится ровно противоположной (скрин №2). Здесь мы видим, что продавцы B2C как с опытом работы, так и без, после прохождения программы адаптации, делают более качественные продажи, чем продавцы B2B, следовательно программа адаптации для продавцов B2C более качественная.
Парадокс Симпсона показывает, как важно учитывать детали в статистике. Статистические данные могут вводить в заблуждение, если рассматривать их без учета всех факторов.
🔥10❤6
Кейс Assassin's Creed: изучение истории через игру.
На конференции Digital Learning Олег Замышляев говорил о таком метанавыке, как умение «пересекать».
Мне очень понравился его тезис:
Видеоигры и e-learning, как мне кажется, во многом близкие сферы. Именно поэтому, я думаю, это отличный вариан, чтобы «попересекать».
Первая задача практически любой игры – НАУЧИТЬ игрока в нее играть.
Вторая задача – научить играть лучше, чтобы игроку было интереснее.
Но есть игры, которые помимо обучения игре в самих себя, учат игроков еще чему-то полезному. Этот кейс именно такой.
Assassin's Creed — это популярная серия видеоигр, разработанная компанией Ubisoft, которая погружает игроков в различные реальные исторические периоды с реальными историческими персонажами. В одной части мы помогаем Леонардо да Винчи тестировать его изобретения в эпоху Ренессанса, в другой сражаемся вместе с Вашингтоном в войне за независимость, в третьей спасаем Анастасию Романову из плена красных.
Несмотря на то, что окружение и персонажи базируются на реальных событиях и фигурах, главный сюжет игры остается художественным и не связан напрямую с реальной историей (практически вообще не связан).
После выпуска каждой новой части игры интернет заполняется не только отзывами о геймплее игры, ее сюжете или графике, а еще и историями о том, как игра пробуждает интерес к истории.
Естественно, разработчики не могли не заметить такого интереса и добавили исторические справки в саму игру. Гуляя по игровому миру игроки могут подойти к специальным сферам и узнать интересные факты о эпохе, персонажах или быте того времени, прочитать про исторические здания, рядом с которыми они гуляют в игре, и потом рассмотреть их со всех сторон. Также интересные факты скрашивают время в ожидании загрузок и еще сильнее погружают в игровой процесс.
Впереди праздники. Надеюсь, что у вас соответствующее предпраздничное настроение. У меня именно такое. Именно поэтому, мне захотелось рассказать о кейсе, который, по своей концепции, мне очень нравится.
На конференции Digital Learning Олег Замышляев говорил о таком метанавыке, как умение «пересекать».
Мне очень понравился его тезис:
Ты видишь концепцию в одной сфере, переносишь её на другие сферы, и на пересечении можешь найти очень много интересного. А чтобы хорошо пересекать, нужно знать много разных сфер.
Видеоигры и e-learning, как мне кажется, во многом близкие сферы. Именно поэтому, я думаю, это отличный вариан, чтобы «попересекать».
Первая задача практически любой игры – НАУЧИТЬ игрока в нее играть.
Вторая задача – научить играть лучше, чтобы игроку было интереснее.
Но есть игры, которые помимо обучения игре в самих себя, учат игроков еще чему-то полезному. Этот кейс именно такой.
Assassin's Creed — это популярная серия видеоигр, разработанная компанией Ubisoft, которая погружает игроков в различные реальные исторические периоды с реальными историческими персонажами. В одной части мы помогаем Леонардо да Винчи тестировать его изобретения в эпоху Ренессанса, в другой сражаемся вместе с Вашингтоном в войне за независимость, в третьей спасаем Анастасию Романову из плена красных.
Несмотря на то, что окружение и персонажи базируются на реальных событиях и фигурах, главный сюжет игры остается художественным и не связан напрямую с реальной историей (практически вообще не связан).
После выпуска каждой новой части игры интернет заполняется не только отзывами о геймплее игры, ее сюжете или графике, а еще и историями о том, как игра пробуждает интерес к истории.
Естественно, разработчики не могли не заметить такого интереса и добавили исторические справки в саму игру. Гуляя по игровому миру игроки могут подойти к специальным сферам и узнать интересные факты о эпохе, персонажах или быте того времени, прочитать про исторические здания, рядом с которыми они гуляют в игре, и потом рассмотреть их со всех сторон. Также интересные факты скрашивают время в ожидании загрузок и еще сильнее погружают в игровой процесс.
👍9❤2🔥2
Игровой движок GDevelop: есть ли для него место в e-learning?
Решение одновременно очень полезное, с явными серьёзными плюсами, и спорное, со своими минусами и ограничениями. Скажем так, подойдёт не для всех.
Цель этого поста — помочь разобраться, нужно ли это вам.
GDevelop — игровой движок, как Unity или Unreal, но более простой. Основное отличие GDevelop заключается в акценте на визуальное программирование, где игровые механики разрабатываются с помощью готовых блоков и функций, без необходимости писать код вручную.
Развёрнутую статью написал ТУТ (там 5 страниц текста + скриншоты и видео-примеры), а основные тезисы ниже:
1. «Надоел этот e-learning, хочу уйти в геймдев» — GDevelop точно не ваш вариант. Слишком простой, да и вакансий нет.
2. Очень простой в освоении и использовании (для примера — скриншоты интерфейса GDevelop и Unity в шапке поста). Первый маленький проект будет готов буквально через час. Час поучился — и уже какой-то результат, который ты можешь «пощупать». Классно же?
3. Визуальное программирование — супер фишка для T-shaped специалиста. Просто разобраться, а что, возможно, более важно — не нужно заново всё вспоминать, если полгода не использовал инструмент.
4. Можно использовать как дополнительный инструмент разработчика. Стек: конструктор лонгридов + GDevelop может дать классный результат. Теорию быстро упаковываем в лонгрид, упражнения собираем в GDevelop. Получается быстро, интерактивно и полезно.
В видео в шапке добавил интерактив с 3D персонажем в Rise. Его можно крутить, перемещать, на кнопки включать анимации. Интерактив в примере, разумеется, не несёт методического смысла. Просто пример технической возможности. Если добавить немного методологии и фантазии, может получиться что-то вроде: «Вот так выглядит огнетушитель. Ты уже изучил, за что тут дёргать и куда нажимать, — давай теперь на практике подёргай и понажимай». В таком контексте это выглядит интересно и полезно.
5. Технические ограничения (особенно в части работы с 3D), небольшое количество ассетов (говоря проще: шаблонов) и совсем маленькое сообщество, которое практически полностью состоит из непрофессионалов, добавляют целую кучу ложек дёгтя в бочку с мёдом.
6. Важно помнить про тренды. Тренд на сокращение time-to-market никто не отменял. С подобными решениями мы идём против трендов. Плыть против течения не очень удобно.
В итоге: движок классный, интересный и необычный. Я получил удовольствие, «поигравшись» с ним. Если вам интересно попробовать новый инструмент, расширить свой функционал или просто получить представление о игровых движках и геймдеве, — советую попробовать.
Подойдёт ли движок для выполнения ваших задач и будет ли полезен в работе? Не знаю. Если инструмент заинтересовал, но есть сомнения, — прочитайте полную версию статьи и попробуйте GDevelop самостоятельно.
Наконец, дошли руки до небольшого обзора игрового движка GDevelop. Больше месяца его планировал — и вот, пожалуйста, всё готово.
Решение одновременно очень полезное, с явными серьёзными плюсами, и спорное, со своими минусами и ограничениями. Скажем так, подойдёт не для всех.
Цель этого поста — помочь разобраться, нужно ли это вам.
GDevelop — игровой движок, как Unity или Unreal, но более простой. Основное отличие GDevelop заключается в акценте на визуальное программирование, где игровые механики разрабатываются с помощью готовых блоков и функций, без необходимости писать код вручную.
Развёрнутую статью написал ТУТ (там 5 страниц текста + скриншоты и видео-примеры), а основные тезисы ниже:
1. «Надоел этот e-learning, хочу уйти в геймдев» — GDevelop точно не ваш вариант. Слишком простой, да и вакансий нет.
2. Очень простой в освоении и использовании (для примера — скриншоты интерфейса GDevelop и Unity в шапке поста). Первый маленький проект будет готов буквально через час. Час поучился — и уже какой-то результат, который ты можешь «пощупать». Классно же?
3. Визуальное программирование — супер фишка для T-shaped специалиста. Просто разобраться, а что, возможно, более важно — не нужно заново всё вспоминать, если полгода не использовал инструмент.
4. Можно использовать как дополнительный инструмент разработчика. Стек: конструктор лонгридов + GDevelop может дать классный результат. Теорию быстро упаковываем в лонгрид, упражнения собираем в GDevelop. Получается быстро, интерактивно и полезно.
В видео в шапке добавил интерактив с 3D персонажем в Rise. Его можно крутить, перемещать, на кнопки включать анимации. Интерактив в примере, разумеется, не несёт методического смысла. Просто пример технической возможности. Если добавить немного методологии и фантазии, может получиться что-то вроде: «Вот так выглядит огнетушитель. Ты уже изучил, за что тут дёргать и куда нажимать, — давай теперь на практике подёргай и понажимай». В таком контексте это выглядит интересно и полезно.
5. Технические ограничения (особенно в части работы с 3D), небольшое количество ассетов (говоря проще: шаблонов) и совсем маленькое сообщество, которое практически полностью состоит из непрофессионалов, добавляют целую кучу ложек дёгтя в бочку с мёдом.
6. Важно помнить про тренды. Тренд на сокращение time-to-market никто не отменял. С подобными решениями мы идём против трендов. Плыть против течения не очень удобно.
В итоге: движок классный, интересный и необычный. Я получил удовольствие, «поигравшись» с ним. Если вам интересно попробовать новый инструмент, расширить свой функционал или просто получить представление о игровых движках и геймдеве, — советую попробовать.
Подойдёт ли движок для выполнения ваших задач и будет ли полезен в работе? Не знаю. Если инструмент заинтересовал, но есть сомнения, — прочитайте полную версию статьи и попробуйте GDevelop самостоятельно.
🔥5❤4👍3🦄1
This media is not supported in your browser
VIEW IN TELEGRAM
This media is not supported in your browser
VIEW IN TELEGRAM
This media is not supported in your browser
VIEW IN TELEGRAM
This media is not supported in your browser
VIEW IN TELEGRAM
This media is not supported in your browser
VIEW IN TELEGRAM
This media is not supported in your browser
VIEW IN TELEGRAM
This media is not supported in your browser
VIEW IN TELEGRAM
Анимировать нельзя помиловать
(да, название недокрутил)
Ссылки на сайты из шапки оставил внизу поста. Естественно, большая часть «красоты» доступна только на ПК версиях.
С каждым годом в веб-дизайне укрепляется тренд на анимации.
В этом есть своя логика:
- Контента в интернете становится все больше – нужно как-то выделяться среди конкурентов, чтобы потенциальный покупатель обратил на тебя внимание;
- Анимации делают контент более динамичным (снижают «сухость» текста), что может повысить желание пользователя остаться на странице (особенно в длинных материалах).
- Создается современный «дорогой» внешний вид – если лонгрид выглядит стильно и современно, складывается впечатление, что контент тоже качественный (встречают по одежке / эффект ореола / воспринимаемая ценность).
- Анимации могут выступать в роли подсказок, направляя пользователя по нужному пути, показывая различные взаимодействия, объясняя, что вообще сейчас происходит (ховеры, акцентные анимации на важных элементах интерфейса, интерфейсы загрузок и т.д.).
Как провожают пароходы? Совсем не так, как поезда.
С веб-дизайном все понятно. Если сайт продающий – анимации ему, скорее всего, только на пользу.
А применим ли такой подход в e-learning?
Если мы говорим про ховеры, микроанимации и акцентные анимации – совершенно точно да. Можно назвать такие анимации «анимациями для пользы» и отнести их к правилам хорошего тона.
Если анимации добавлены просто «для красоты», их влияние на учебные цели может быть неоднозначным:
С одной стороны, очень неплохо, если наш курс будет выделяться на фоне остальных, будет динамичным, и при первом взгляде на курс пользователи подумают «о, прикольно, постарались ребята, дай-ка почитаю, что там такого интересного».
С другой стороны, анимации отвлекают от контента: скролл-анимации, мигающие и двигающиеся элементы, различные эффекты могут раздражать и мешать сосредоточиться на тексте. Мозг тратит ресурсы на обработку лишних визуальных стимулов вместо усвоения информации (когнитивная перезагрузка).
Также длительные анимации чаще всего снижают скорость отображения контента (например, текст появляется «порционно» после прокрутки), это ухудшает UX и, что логично, увеличивает время, необходимое для прохождения курса.
Плюс нужно не забывать про time-to-market и бюджеты. Чаще всего в корпоратевном обучении нет таких ресурсов и возможностей, как, например, в маркетинге, а анимации могут существенно повлиять на стоимость конечного продукта.
------
Как мне кажется, анимация «для красоты» может сделать учебные продукты более интересными и эффективными, главное, чтобы она не была навязчивой, не перетягивала на себя основной фокус внимания, а была просто интересным дополнительным элементом, «вишенкой на торте» качественного образовательного продукта.
А как вы думаете, уместна ли анимация «для красоты» в e-learning?
Сайты из шапки:
Арт Лайфт, API Яндекс Карты, Flying Papers, Websoft, Girls don't cry, База, Itemy
(да, название недокрутил)
Когда вижу сайт с интересным дизайном – стараюсь (зачастую безуспешно) сохранить его себе куда-то в закладки, чтобы, когда наступит время, вдохновиться чем-то красивым. Просматривая последние сохраненные страницы, заметил, что большая часть понравившихся проектов яркая (тут ничего удивительного, скоро лето и настроение соответствующее) и с какой-то интересной, необычной анимацией, которая цепляет взгляд, заставляет в нее «позалипать».
Ссылки на сайты из шапки оставил внизу поста. Естественно, большая часть «красоты» доступна только на ПК версиях.
С каждым годом в веб-дизайне укрепляется тренд на анимации.
В этом есть своя логика:
- Контента в интернете становится все больше – нужно как-то выделяться среди конкурентов, чтобы потенциальный покупатель обратил на тебя внимание;
- Анимации делают контент более динамичным (снижают «сухость» текста), что может повысить желание пользователя остаться на странице (особенно в длинных материалах).
- Создается современный «дорогой» внешний вид – если лонгрид выглядит стильно и современно, складывается впечатление, что контент тоже качественный (встречают по одежке / эффект ореола / воспринимаемая ценность).
- Анимации могут выступать в роли подсказок, направляя пользователя по нужному пути, показывая различные взаимодействия, объясняя, что вообще сейчас происходит (ховеры, акцентные анимации на важных элементах интерфейса, интерфейсы загрузок и т.д.).
Как провожают пароходы? Совсем не так, как поезда.
С веб-дизайном все понятно. Если сайт продающий – анимации ему, скорее всего, только на пользу.
А применим ли такой подход в e-learning?
Если мы говорим про ховеры, микроанимации и акцентные анимации – совершенно точно да. Можно назвать такие анимации «анимациями для пользы» и отнести их к правилам хорошего тона.
Если анимации добавлены просто «для красоты», их влияние на учебные цели может быть неоднозначным:
С одной стороны, очень неплохо, если наш курс будет выделяться на фоне остальных, будет динамичным, и при первом взгляде на курс пользователи подумают «о, прикольно, постарались ребята, дай-ка почитаю, что там такого интересного».
С другой стороны, анимации отвлекают от контента: скролл-анимации, мигающие и двигающиеся элементы, различные эффекты могут раздражать и мешать сосредоточиться на тексте. Мозг тратит ресурсы на обработку лишних визуальных стимулов вместо усвоения информации (когнитивная перезагрузка).
Также длительные анимации чаще всего снижают скорость отображения контента (например, текст появляется «порционно» после прокрутки), это ухудшает UX и, что логично, увеличивает время, необходимое для прохождения курса.
Плюс нужно не забывать про time-to-market и бюджеты. Чаще всего в корпоратевном обучении нет таких ресурсов и возможностей, как, например, в маркетинге, а анимации могут существенно повлиять на стоимость конечного продукта.
------
Как мне кажется, анимация «для красоты» может сделать учебные продукты более интересными и эффективными, главное, чтобы она не была навязчивой, не перетягивала на себя основной фокус внимания, а была просто интересным дополнительным элементом, «вишенкой на торте» качественного образовательного продукта.
А как вы думаете, уместна ли анимация «для красоты» в e-learning?
Сайты из шапки:
Арт Лайфт, API Яндекс Карты, Flying Papers, Websoft, Girls don't cry, База, Itemy
❤6🔥3👍1
Здесь вам не тут: 2 интересных западных e-learning исследования
Коротко о методологии исследований:
- Исследования проводились путем опроса целевой аудитории (в первом случае — менеджеры по найму, во втором — разработчики курсов).
- Аудитория опрошенных в основном из англоговорящих стран (США, Канада, Великобритания, Австралия). Незначительное количество — из прочих стран (в основном из Индии).
- Основной канал распространения опроса — LinkedIn.
Отчет по подбору кадров
Какие критерии являются решающими при выборе кандидата на должность педагогического дизайнера/разработчика курсов:
1. Образование
- 74,2% работодателей не готовы рассматривать кандидатов без высшего образования.
- 39,6% опрошенных работодателей предпочли бы, чтобы у сотрудника была степень магистра.
- Сертификат о дополнительном профессиональном образовании является преимуществом при найме, при этом для 5% работодателей этот пункт критически важен.
А что у нас?
Данных по e-learning у нас нет (было бы интересно провести опрос), но есть общие данные. Согласно исследованию Работа.ру и СберПодбор, для 36% работодателей высшее образование критично при подборе специалистов (по методологии опроса сотрудников разделяют на: специалистов, руководителей и линейный/массовый персонал). Иными словами, работодатели в России минимум в 2 раза лояльнее относятся к отсутствию высшего образования.
2. Опыт
- Только 19,8% работодателей не рассматривают кандидатов без опыта.
- 62,4% работодателей хоть и готовы рассматривать кандидатов без опыта, но опытные кандидаты имеют больше шансов получить должность.
Здесь ничего удивительного — новичкам сложно везде. Нет опыта – 80%* дверей (при этом, скорее всего, наиболее привлекательных) будут для тебя закрыты.
*Ну или 20% дверей открыты — тут смотря, наполовину полон или пуст у вас стакан =)
3. Требуемые навыки
Тут никаких сюрпризов:
Первое место: Методология – 71,3%
Второе место: Коммуникативные навыки – 69,3%
Третье место: Навыки разработки курсов – 64,4% (при этом 75,2% работодателей хотели бы, чтобы новый сотрудник умел использовать Articulate Storyline).
Навыки управления проектами и дизайна тоже востребованы на рынке (40,6% и 31,7%), а вот умение использовать xAPI и программирование требуют всего 4% и 8,9% компаний соответственно.
Пробежавшись по вакансиям на hh.ru, можно сказать, что если заменить Storyline на iSpring — получится точно такая же ситуация, как у нас.
----
Отчет о заработной плате
Не сказать, что полезно, но любопытно, правда?)
Средняя зарплата по странам в месяц:
США: 6.945 $ (562.600 руб.)
Австралия: 6.240 $ (505.500 руб.)
Канада: 4.782 $ (387.400 руб.)
Великобритания: 4.285$ (347.150 руб.)
Индия: 1.184 $ (96.000 руб.)
В США самая большая средняя заработная плата, при этом и самая большая вилка: от 2.917$ (236.250 руб.) до 25.000$ (2.025.000 руб.).
А что у нас?
Средняя зарплата e-learning специалиста в Москве: 137.000 руб. (1.691 $)*
*Данные из отчета Recruitment for Friends. Кстати, вот ТУТ Виталий Кураго писал про этот отчет.
От чего зависит заработная плата?
1. Образование
Высшее образование позволяет увеличить доход до 2 раз. При этом разницы между бакалавриатом и магистратурой в доходах нет, а вот PhD позволяет увеличить доход на 10%.
2. Опыт
Сотрудники с большим опытом зарабатывают почти в 1,5 раза больше, чем новички.
3. Сфера бизнеса
Самый низкий доход в сфере высшего образования: на 20% ниже, чем в других сферах.
А как вам кажется, какие еще факторы влияют на успех в e-learning?
Ежегодно Павел Безяев проводит исследование рынка корпоративного обучения в сообществе Digital Learning. Мне стало интересно, насколько и в чем результаты отечественного и зарубежных исследований будут совпадать и где принципиальные отличия. Похожих отчетов я не нашел, но обнаружил два не менее любопытных материала: «Отчет по подбору кадров в педагогическом дизайне за 2024 год» и «Отчет о заработной плате разработчиков электронных курсов за 2024 год». Полные отчеты доступны по ссылкам, основные тезисы ниже =)
Коротко о методологии исследований:
- Исследования проводились путем опроса целевой аудитории (в первом случае — менеджеры по найму, во втором — разработчики курсов).
- Аудитория опрошенных в основном из англоговорящих стран (США, Канада, Великобритания, Австралия). Незначительное количество — из прочих стран (в основном из Индии).
- Основной канал распространения опроса — LinkedIn.
Отчет по подбору кадров
Какие критерии являются решающими при выборе кандидата на должность педагогического дизайнера/разработчика курсов:
1. Образование
- 74,2% работодателей не готовы рассматривать кандидатов без высшего образования.
- 39,6% опрошенных работодателей предпочли бы, чтобы у сотрудника была степень магистра.
- Сертификат о дополнительном профессиональном образовании является преимуществом при найме, при этом для 5% работодателей этот пункт критически важен.
А что у нас?
Данных по e-learning у нас нет (было бы интересно провести опрос), но есть общие данные. Согласно исследованию Работа.ру и СберПодбор, для 36% работодателей высшее образование критично при подборе специалистов (по методологии опроса сотрудников разделяют на: специалистов, руководителей и линейный/массовый персонал). Иными словами, работодатели в России минимум в 2 раза лояльнее относятся к отсутствию высшего образования.
2. Опыт
- Только 19,8% работодателей не рассматривают кандидатов без опыта.
- 62,4% работодателей хоть и готовы рассматривать кандидатов без опыта, но опытные кандидаты имеют больше шансов получить должность.
Здесь ничего удивительного — новичкам сложно везде. Нет опыта – 80%* дверей (при этом, скорее всего, наиболее привлекательных) будут для тебя закрыты.
*Ну или 20% дверей открыты — тут смотря, наполовину полон или пуст у вас стакан =)
3. Требуемые навыки
Тут никаких сюрпризов:
Первое место: Методология – 71,3%
Второе место: Коммуникативные навыки – 69,3%
Третье место: Навыки разработки курсов – 64,4% (при этом 75,2% работодателей хотели бы, чтобы новый сотрудник умел использовать Articulate Storyline).
Навыки управления проектами и дизайна тоже востребованы на рынке (40,6% и 31,7%), а вот умение использовать xAPI и программирование требуют всего 4% и 8,9% компаний соответственно.
Пробежавшись по вакансиям на hh.ru, можно сказать, что если заменить Storyline на iSpring — получится точно такая же ситуация, как у нас.
----
Отчет о заработной плате
Не сказать, что полезно, но любопытно, правда?)
Средняя зарплата по странам в месяц:
США: 6.945 $ (562.600 руб.)
Австралия: 6.240 $ (505.500 руб.)
Канада: 4.782 $ (387.400 руб.)
Великобритания: 4.285$ (347.150 руб.)
Индия: 1.184 $ (96.000 руб.)
В США самая большая средняя заработная плата, при этом и самая большая вилка: от 2.917$ (236.250 руб.) до 25.000$ (2.025.000 руб.).
А что у нас?
Средняя зарплата e-learning специалиста в Москве: 137.000 руб. (1.691 $)*
*Данные из отчета Recruitment for Friends. Кстати, вот ТУТ Виталий Кураго писал про этот отчет.
От чего зависит заработная плата?
1. Образование
Высшее образование позволяет увеличить доход до 2 раз. При этом разницы между бакалавриатом и магистратурой в доходах нет, а вот PhD позволяет увеличить доход на 10%.
2. Опыт
Сотрудники с большим опытом зарабатывают почти в 1,5 раза больше, чем новички.
3. Сфера бизнеса
Самый низкий доход в сфере высшего образования: на 20% ниже, чем в других сферах.
А как вам кажется, какие еще факторы влияют на успех в e-learning?
👍6🔥4❤3
Костыли*: инструмент или преступление?
*Костыль / обходной приём / workaround / паллиатив — относительно быстрое и простое решение проблемы, применяемое для срочного устранения её последствий, но не влияющее на причины её возникновения.
Многие разработчики ПО стыдятся своих «костылей», но, наверное, нет ни одного программиста, который хоть изредка их не использует. А если говорить о корпоративном e-learning, то в сложных проектах иногда без них вообще не обойтись.
Хотя костыли обычно считаются плохой практикой, иногда они бывают оправданы. Давайте разберёмся, в каких случаях их можно использовать в e-learning, а когда стоит избегать.
Когда костыли допустимы:
1. Сжатые сроки / временное решение
(А сроки практически всегда такие.)
Проект нужен «вчера», на разработку есть максимум 1,5–2 дня. Работы, если делать всё по-человечески, минимум на неделю. Что делать? Либо не сдавать проект в срок, либо собирать «на коленке» то, что как-то работает, а потом, при необходимости, переделывать «начисто».
Например: чуть больше чем за день (ну, так получилось) нужно было собрать лендинг с нестандартной механикой. Взяли два проекта, в каждом из которых была половинка нужной механики, и «поженили» их в один проект побольше. Стоит отметить, что и в тех двух проектах костыли присутствовали, а после «женитьбы» вообще получился франкенштейн. Но всё работало, и проект был сдан в срок.
2. Ограничения технологий
Не получается выполнить задачу теми инструментами, процессами и требованиями ИБ, которые есть, без костылей.
Например: конструкторы курсов очень удобны для стандартных задач, коих процентов 95 (а то и больше), но в остальных 5% требуются доработки, которые иначе как костылями реализовать невозможно. Или заказчику необходимо изменить элемент, который нельзя редактировать стандартными средствами конструктора.
3. Прототипирование
Нужно быстро проверить идею. Не факт, что она удачная, или, как минимум, высока вероятность, что потребуются существенные доработки. Так зачем тратить много времени? Чем раньше и дешевле проверили — тем лучше.
Например: два года назад я собирал диалоговый тренажёр с ИИ в Articulate Storyline. Основная задача — проверить гипотезы: насколько полезен такой тренажёр, как лучше реализовать механики, найти как можно больше подводных камней. Весь проект — склад костылей (добавление ИИ в Storyline само по себе тот ещё костыль, но и без этого их там достаточно).
Результат: быстро проверили гипотезы, получили опыт и полезные выводы для реализации будущих проектов.
Когда костыли недопустимы:
1. Долгосрочные проекты
Когда мы понимаем, что проектом будем пользоваться долго и часто вносить правки.
Например: проект-«франкенштейн». После 5–6 итераций изменений в лендинг (которые проходили с болью, потому что в проекте вообще ничего не понятно) переписали механики по-человечески. Теперь мелкие правки занимают не полчаса, а пару минут.
2. Если над проектом работает несколько человек / вносить изменения будет другой сотрудник или команда
В своём «кривом» коде бывает очень непросто разобраться, а в чужом — зачастую практически невозможно. Делу могут немного помочь комментарии, но лучше не портить жизнь другим людям и сделать всё хорошо и понятно.
Вывод
Конечно, если бы мы жили в идеальном мире, для таких решений не было бы места. Но в реальной жизни костыли — как молоток: ими можно и гвоздь забить, и стекло разбить. Главное — понимать, где они уместны, а где приведут к серьёзным негативным последствиям. В обучении (и другой быстрой разработке) они часто оправданы, но в серьёзных проектах лучше ими не злоупотреблять.
*Костыль / обходной приём / workaround / паллиатив — относительно быстрое и простое решение проблемы, применяемое для срочного устранения её последствий, но не влияющее на причины её возникновения.
Многие разработчики ПО стыдятся своих «костылей», но, наверное, нет ни одного программиста, который хоть изредка их не использует. А если говорить о корпоративном e-learning, то в сложных проектах иногда без них вообще не обойтись.
Хотя костыли обычно считаются плохой практикой, иногда они бывают оправданы. Давайте разберёмся, в каких случаях их можно использовать в e-learning, а когда стоит избегать.
Когда костыли допустимы:
1. Сжатые сроки / временное решение
(А сроки практически всегда такие.)
Проект нужен «вчера», на разработку есть максимум 1,5–2 дня. Работы, если делать всё по-человечески, минимум на неделю. Что делать? Либо не сдавать проект в срок, либо собирать «на коленке» то, что как-то работает, а потом, при необходимости, переделывать «начисто».
Например: чуть больше чем за день (ну, так получилось) нужно было собрать лендинг с нестандартной механикой. Взяли два проекта, в каждом из которых была половинка нужной механики, и «поженили» их в один проект побольше. Стоит отметить, что и в тех двух проектах костыли присутствовали, а после «женитьбы» вообще получился франкенштейн. Но всё работало, и проект был сдан в срок.
2. Ограничения технологий
Не получается выполнить задачу теми инструментами, процессами и требованиями ИБ, которые есть, без костылей.
Например: конструкторы курсов очень удобны для стандартных задач, коих процентов 95 (а то и больше), но в остальных 5% требуются доработки, которые иначе как костылями реализовать невозможно. Или заказчику необходимо изменить элемент, который нельзя редактировать стандартными средствами конструктора.
.button {
color: red !important; // Костыль, чтобы перебить другие стили
}
3. Прототипирование
Нужно быстро проверить идею. Не факт, что она удачная, или, как минимум, высока вероятность, что потребуются существенные доработки. Так зачем тратить много времени? Чем раньше и дешевле проверили — тем лучше.
Например: два года назад я собирал диалоговый тренажёр с ИИ в Articulate Storyline. Основная задача — проверить гипотезы: насколько полезен такой тренажёр, как лучше реализовать механики, найти как можно больше подводных камней. Весь проект — склад костылей (добавление ИИ в Storyline само по себе тот ещё костыль, но и без этого их там достаточно).
Результат: быстро проверили гипотезы, получили опыт и полезные выводы для реализации будущих проектов.
Когда костыли недопустимы:
1. Долгосрочные проекты
Когда мы понимаем, что проектом будем пользоваться долго и часто вносить правки.
Например: проект-«франкенштейн». После 5–6 итераций изменений в лендинг (которые проходили с болью, потому что в проекте вообще ничего не понятно) переписали механики по-человечески. Теперь мелкие правки занимают не полчаса, а пару минут.
2. Если над проектом работает несколько человек / вносить изменения будет другой сотрудник или команда
В своём «кривом» коде бывает очень непросто разобраться, а в чужом — зачастую практически невозможно. Делу могут немного помочь комментарии, но лучше не портить жизнь другим людям и сделать всё хорошо и понятно.
Вывод
Конечно, если бы мы жили в идеальном мире, для таких решений не было бы места. Но в реальной жизни костыли — как молоток: ими можно и гвоздь забить, и стекло разбить. Главное — понимать, где они уместны, а где приведут к серьёзным негативным последствиям. В обучении (и другой быстрой разработке) они часто оправданы, но в серьёзных проектах лучше ими не злоупотреблять.
👍9❤2🔥2
Костыли в видеоиграх (часть 1)
В e-learning мы используем костыли часто, но с кем мы точно не можем соревноваться в костылестроении — так это разработчики видеоигр. Они — настоящие короли костылей.
Практически всегда игровые движки имеют ряд серьёзных ограничений или недоработок, из-за которых разработчикам приходится искать интересные и нестандартные (а зачастую ещё глупые и смешные) пути обхода ограничений, чтобы игра вышла в свет именно такой, какой её задумал геймдизайнер.
О двух самых курьёзных и интересных кейсах сегодня и поговорим:
1. World of Warcraft и невидимые кролики ✨🐇✨ (кролики — это не только ценный мех)
World of Warcraft — это популярная онлайн-игра в фэнтези-стиле, где тысячи игроков исследуют открытый мир, сражаются и выполняют задания вместе или друг против друга.
Типичное задание в игре: неигровой персонаж просит убить 10 кабанчиков и принести ему шкуры. За выполнение задания игрок получает опыт и, возможно, какой-то ценный предмет.
Механика очень простая:
1. Поговорил с персонажем
2. Убил кабанчиков
3. Поговорил с персонажем
В чём может быть проблема?
Проблема в том, что квесты собирались на встроенном редакторе, в котором не было триггера «завершить квест после разговора с персонажем».
Как решили проблему?
Через убийство кроликов. После разговора с неигровым персонажем появлялся невидимый кролик, который сразу после появления умирал. А триггер выполнения квеста был привязан к смерти этого кролика.
Кстати, потом возможность завершать квесты после разговора добавили... через 3 года.
Забавный комментарий ведущего программиста Blizzard Кертиса МакКатерна по этому поводу:
На жертвенных смертях роль кроликов не закончилась.
Например, из-за технических ограничений не получалось «прикрепить» эффект лазера к турелям... думаю, вы уже понимаете, какое решение нашли разработчики. К кроликам такой эффект «цеплялся» запросто. Сажаем невидимого кролика на дуло турели, скотчем прикрепляем лазер — всё работает.
А что, если мы хотим, чтобы при входе в пустое подземелье срабатывало какое-то заклинание? Идея хорошая, но по логике игрового движка заклинание не может появиться само по себе, его обязательно кто-то должен наколдовать... да, кролики.
2. Fallout 3: поезд-шляпа 🚅🎩
Fallout 3 — шутер от первого лица в мире после ядерной войны.
В одном из заданий нам нужно прокатиться на поезде. Проблема в том, что механики езды на чём-то в движке не было. Конечно, её можно добавить, но это время и деньги, которые не хотелось тратить. Чтобы справиться с проблемой разработчики нашли действительно абсурдное решение, но... оно работало.
- Когда к станции подъезжал поезд, это на самом деле был не поезд, а неигровой персонаж с огромной шляпой в виде поезда.
- Теперь поезд мог подъезжать, но ехать наш персонаж в нём не мог (механики езды у кого в шляпе, в движке естественно тоже не было). Соответственно, после того как мы заходим в шляпу-поезд, наш персонаж сам надевает на себя шляпу-поезд и быстро бежит по рельсам.
Абсурдно, но работает.
----
Когда у разработчиков нет времени, ресурсов или подходящих инструментов, они находят выход — пусть и странный. Главное, чтобы продукт работал, а пользователи не замечали подвоха.
P.S. Если в игре что-то работает не так, как ожидалось, — где-то рядом точно есть невидимый кролик. 🐇
«Часть 1» в заголовке не просто так. Мне настолько понравилась эта тема, и интересных кейсов так много, что я решил не останавливаться на одном посте.
В e-learning мы используем костыли часто, но с кем мы точно не можем соревноваться в костылестроении — так это разработчики видеоигр. Они — настоящие короли костылей.
Практически всегда игровые движки имеют ряд серьёзных ограничений или недоработок, из-за которых разработчикам приходится искать интересные и нестандартные (а зачастую ещё глупые и смешные) пути обхода ограничений, чтобы игра вышла в свет именно такой, какой её задумал геймдизайнер.
О двух самых курьёзных и интересных кейсах сегодня и поговорим:
1. World of Warcraft и невидимые кролики ✨🐇✨ (кролики — это не только ценный мех)
World of Warcraft — это популярная онлайн-игра в фэнтези-стиле, где тысячи игроков исследуют открытый мир, сражаются и выполняют задания вместе или друг против друга.
Типичное задание в игре: неигровой персонаж просит убить 10 кабанчиков и принести ему шкуры. За выполнение задания игрок получает опыт и, возможно, какой-то ценный предмет.
Механика очень простая:
1. Поговорил с персонажем
2. Убил кабанчиков
3. Поговорил с персонажем
В чём может быть проблема?
Проблема в том, что квесты собирались на встроенном редакторе, в котором не было триггера «завершить квест после разговора с персонажем».
Как решили проблему?
Через убийство кроликов. После разговора с неигровым персонажем появлялся невидимый кролик, который сразу после появления умирал. А триггер выполнения квеста был привязан к смерти этого кролика.
Кстати, потом возможность завершать квесты после разговора добавили... через 3 года.
Забавный комментарий ведущего программиста Blizzard Кертиса МакКатерна по этому поводу:
Иногда ты и не знаешь, что дизайнерам требуется кухня, пока они не сварят лапшу в цветочной вазе на утюге.
На жертвенных смертях роль кроликов не закончилась.
Например, из-за технических ограничений не получалось «прикрепить» эффект лазера к турелям... думаю, вы уже понимаете, какое решение нашли разработчики. К кроликам такой эффект «цеплялся» запросто. Сажаем невидимого кролика на дуло турели, скотчем прикрепляем лазер — всё работает.
А что, если мы хотим, чтобы при входе в пустое подземелье срабатывало какое-то заклинание? Идея хорошая, но по логике игрового движка заклинание не может появиться само по себе, его обязательно кто-то должен наколдовать... да, кролики.
2. Fallout 3: поезд-шляпа 🚅🎩
Fallout 3 — шутер от первого лица в мире после ядерной войны.
В одном из заданий нам нужно прокатиться на поезде. Проблема в том, что механики езды на чём-то в движке не было. Конечно, её можно добавить, но это время и деньги, которые не хотелось тратить. Чтобы справиться с проблемой разработчики нашли действительно абсурдное решение, но... оно работало.
- Когда к станции подъезжал поезд, это на самом деле был не поезд, а неигровой персонаж с огромной шляпой в виде поезда.
- Теперь поезд мог подъезжать, но ехать наш персонаж в нём не мог (механики езды у кого в шляпе, в движке естественно тоже не было). Соответственно, после того как мы заходим в шляпу-поезд, наш персонаж сам надевает на себя шляпу-поезд и быстро бежит по рельсам.
Абсурдно, но работает.
----
Когда у разработчиков нет времени, ресурсов или подходящих инструментов, они находят выход — пусть и странный. Главное, чтобы продукт работал, а пользователи не замечали подвоха.
P.S. Если в игре что-то работает не так, как ожидалось, — где-то рядом точно есть невидимый кролик. 🐇
❤5
3. Wing Commander. Спасибо за игру ⭐️🚀⭐️
Wing Commander — симулятор космических боёв 1990 года.
Игра была уже практически завершена. Дискеты готовы для записи новинки. Игра работала отлично, но после завершения игровой сессии у пользователей постоянно вылетала ошибка «Ошибка менеджера памяти. EMM 386». Выпускать игру с такой проблемой не хотелось, раньше же нельзя было выпустить сырой продукт, а потом постоянно обновлять его через интернет, а времени на поиск причин и отладку не было.
Разработчики нашли оригинальное решение — заменили текст в информации об ошибке. Теперь, при выходе из игры пользователи видели сообщение: «Благодарим за то, что играли в Wing Commander».
Wing Commander — симулятор космических боёв 1990 года.
Игра была уже практически завершена. Дискеты готовы для записи новинки. Игра работала отлично, но после завершения игровой сессии у пользователей постоянно вылетала ошибка «Ошибка менеджера памяти. EMM 386». Выпускать игру с такой проблемой не хотелось, раньше же нельзя было выпустить сырой продукт, а потом постоянно обновлять его через интернет, а времени на поиск причин и отладку не было.
Разработчики нашли оригинальное решение — заменили текст в информации об ошибке. Теперь, при выходе из игры пользователи видели сообщение: «Благодарим за то, что играли в Wing Commander».
🔥8❤5
От no-code к коду: как ИИ возвращает программирование в корпоративный e-learning
20–30 лет назад электронные курсы были полноценными IT-продуктами: их разрабатывали на Delphi, Visual Basic или даже FORTRAN. С появлением no-code-конструкторов процесс упростился, но сейчас e-learning снова движется в сторону сложных решений благодаря ИИ.
Почему это происходит?
ИИ, особенно интегрированный в среды программирования, сокращает время разработки в разы. Теперь e-learning-специалист может за несколько дней создать то, что раньше требовало неделю и junior/middle-разработчика*.
*речь о простых проектах. Критичные системы (например, банковский скоринг) по-прежнему требуют экспертов.
Какие ваши доказательства?
(Тут должен быть мем из фильма «Красная жара»)
Посмотрим примеры:
1️⃣
Андрей Матюков разработал конвертер документов (PDF, Word, Excel) в SCORM. (этот проект и вдохновил меня на пост.)
Закинул в веб-интерфейс документ, с которым сотрудники должны ознакомиться, — скачал архив SCORM. Его можно загружать в LMS, назначать сотрудникам и контролировать статусы прохождения (так ещё и прогресс сохраняется).
Задача не самая простая и не очень быстрая. А у Андрея на разработку продукта ушла буквально ночь.
Здорово? Здорово! И полезно.
Раньше такой продукт совершенно точно нужно было заказывать у IT — теперь есть возможность собрать самостоятельно.
В своём канале Андрей описал разработку подробнее. Можно попробовать инструмент и использовать в работе. Это бесплатно 😄
Очень важно, что это не просто полезный проект, а ещё и демонстрация того, что, правильно использовав инструменты, можно быстро и качественно разрабатывать сложные e-learning-проекты с бэкендом силами внутренней команды обучения.
2️⃣
Коллеги из Курсомании разработали калькулятор стоимости разработки электронного курса.
Заносим в калькулятор информацию по предоставленным материалам, образу результата и требованиям к курсу — получаем ориентировочное время разработки и стоимость продукта. Полезно как для специалиста, так и для заказчика (чтобы было понимание трудозатрат и прозрачность системы расчётов).
Попробовать продукт и прочитать подробнее можно в канале Курсомании.
Как ИИ ускоряет создание IT-продуктов?
1️⃣ Генерирует код — просто опишите, что нужно (например: «кнопка, которая проверяет ответы»), и получите готовый вариант.
2️⃣ Подбирает библиотеки — ИИ сразу посоветует, какие готовые решения (библиотеки) использовать, экономя часы на поиск и изучение документации.
3️⃣ Находит и исправляет ошибки — если что-то не работает, ИИ не просто укажет на проблему, но и предложит конкретные способы исправления.
Что дальше? Будущее e-learning на стыке ИИ и программирования
ИИ — только часть необходимого инструментария, который может существенно улучшить учебный опыт. Сложные интерактивы и механики с небольшим time-to-market, реализуемые на фронтенде, доступны нам уже сейчас, и этим точно нужно начинать пользоваться (главное — с умом: не делать интерактив ради интерактива и сложные конструкции ради сложных конструкций).
В бэкенде потенциал больше: от лайков/комментариев до многопользовательских квизов и онлайн бизнес-игр, которые раньше требовали IT-специалистов. Но для реализации таких механик осталось самое сделать сложное — получить необходимое оборудование 😒
Вывод: IT возвращается в e-learning, но уже по-новому
История циклична: мы снова приходим к тому, что разработка учебного контента требует технических навыков. Но теперь не нужно быть middle-разработчиком, чтобы делать крутые вещи (да, тут я уже начал немного перегибать палку ради красивых речевых оборотов, прошу прощения).
Достаточно:
✅ Разбираться в основах программирования (хотя бы на уровне чтения и модификации кода).
✅ Уметь формулировать задачи для ИИ.
✅ Понимать, зачем нужен код в обучении (а не просто «потому что можно»).
Главное правило: ИИ не заменяет экспертизу, но сокращает путь от идеи до реализации. Чем точнее вы ставите задачу — тем быстрее получите результат.
Так что — вперёд, к новым (и не таким уж сложным) IT-горизонтам! 🚀
20–30 лет назад электронные курсы были полноценными IT-продуктами: их разрабатывали на Delphi, Visual Basic или даже FORTRAN. С появлением no-code-конструкторов процесс упростился, но сейчас e-learning снова движется в сторону сложных решений благодаря ИИ.
Почему это происходит?
ИИ, особенно интегрированный в среды программирования, сокращает время разработки в разы. Теперь e-learning-специалист может за несколько дней создать то, что раньше требовало неделю и junior/middle-разработчика*.
*речь о простых проектах. Критичные системы (например, банковский скоринг) по-прежнему требуют экспертов.
Какие ваши доказательства?
(Тут должен быть мем из фильма «Красная жара»)
Посмотрим примеры:
Андрей Матюков разработал конвертер документов (PDF, Word, Excel) в SCORM. (этот проект и вдохновил меня на пост.)
Закинул в веб-интерфейс документ, с которым сотрудники должны ознакомиться, — скачал архив SCORM. Его можно загружать в LMS, назначать сотрудникам и контролировать статусы прохождения (так ещё и прогресс сохраняется).
Задача не самая простая и не очень быстрая. А у Андрея на разработку продукта ушла буквально ночь.
Здорово? Здорово! И полезно.
Раньше такой продукт совершенно точно нужно было заказывать у IT — теперь есть возможность собрать самостоятельно.
В своём канале Андрей описал разработку подробнее. Можно попробовать инструмент и использовать в работе. Это бесплатно 😄
Очень важно, что это не просто полезный проект, а ещё и демонстрация того, что, правильно использовав инструменты, можно быстро и качественно разрабатывать сложные e-learning-проекты с бэкендом силами внутренней команды обучения.
Коллеги из Курсомании разработали калькулятор стоимости разработки электронного курса.
Заносим в калькулятор информацию по предоставленным материалам, образу результата и требованиям к курсу — получаем ориентировочное время разработки и стоимость продукта. Полезно как для специалиста, так и для заказчика (чтобы было понимание трудозатрат и прозрачность системы расчётов).
Попробовать продукт и прочитать подробнее можно в канале Курсомании.
Как ИИ ускоряет создание IT-продуктов?
1️⃣ Генерирует код — просто опишите, что нужно (например: «кнопка, которая проверяет ответы»), и получите готовый вариант.
2️⃣ Подбирает библиотеки — ИИ сразу посоветует, какие готовые решения (библиотеки) использовать, экономя часы на поиск и изучение документации.
3️⃣ Находит и исправляет ошибки — если что-то не работает, ИИ не просто укажет на проблему, но и предложит конкретные способы исправления.
Что дальше? Будущее e-learning на стыке ИИ и программирования
ИИ — только часть необходимого инструментария, который может существенно улучшить учебный опыт. Сложные интерактивы и механики с небольшим time-to-market, реализуемые на фронтенде, доступны нам уже сейчас, и этим точно нужно начинать пользоваться (главное — с умом: не делать интерактив ради интерактива и сложные конструкции ради сложных конструкций).
В бэкенде потенциал больше: от лайков/комментариев до многопользовательских квизов и онлайн бизнес-игр, которые раньше требовали IT-специалистов. Но для реализации таких механик осталось самое сделать сложное — получить необходимое оборудование 😒
Вывод: IT возвращается в e-learning, но уже по-новому
История циклична: мы снова приходим к тому, что разработка учебного контента требует технических навыков. Но теперь не нужно быть middle-разработчиком, чтобы делать крутые вещи (да, тут я уже начал немного перегибать палку ради красивых речевых оборотов, прошу прощения).
Достаточно:
✅ Разбираться в основах программирования (хотя бы на уровне чтения и модификации кода).
✅ Уметь формулировать задачи для ИИ.
✅ Понимать, зачем нужен код в обучении (а не просто «потому что можно»).
Главное правило: ИИ не заменяет экспертизу, но сокращает путь от идеи до реализации. Чем точнее вы ставите задачу — тем быстрее получите результат.
Так что — вперёд, к новым (и не таким уж сложным) IT-горизонтам! 🚀
Please open Telegram to view this post
VIEW IN TELEGRAM
❤14👍6⚡3