Диаграмма Исикавы для онлайн-курса: от версий причин к проверке проблемы

Представим условный поток: из двадцати четырёх участников, открывших задание второго модуля, десять не передали работу к согласованному сроку. Это ещё не объяснение причин. Куратор подозревает перегрузку, автор — слабую подготовку, технический помощник — проблему с файлом. До переработки модуля полезно разделить эти версии и проверить, что за ними стоит.

Опишите один наблюдаемый эффект

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

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

Определение диаграммы как способа организовать возможные причины приведено в руководстве ASQ по Fishbone. Рисунок помогает обсуждению, но расположение версии на ветке само по себе не доказывает причинную связь.

Выберите категории под учебную ситуацию

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

Например, к инструкции относятся непонятный формат результата и противоречивые требования. К материалам — отсутствие нужного примера и неправильная версия файла. К техническому пути — недоступная ссылка и затруднение при передаче работы. Разделяйте факторы настолько, чтобы для них можно было придумать разные проверки.

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

Разложите общие мнения на проверяемые версии

Попросите каждого участника команды сначала записать версии самостоятельно. Затем перенесите их на общую схему, объединяя только действительно одинаковые. Рядом с каждой пометьте, на чём она основана: конкретное обращение, наблюдение при прохождении или пока только предположение.

Фразу «слишком сложно» раскройте вопросом: какое действие требует навыка, которого ещё не было в программе? Например, ученик должен объединить два списка, хотя до этого работал только с одним. Фраза «неудобная платформа» тоже требует уточнения: ссылка не открывается, файл не скачивается или человек не понимает место сдачи?

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

Назначьте наблюдение для каждой важной ветки

Для нескольких приоритетных версий составьте короткие проверки:

• Неясен формат результата: попросить участника после чтения инструкции пересказать, что он должен передать.

• Не хватает предварительного навыка: дать короткое действие с двумя списками без сложности основного задания.

• Недоступен файл: открыть ту же ссылку через тестовый ученический аккаунт и проверить нужное устройство.

• Не хватает времени: выяснить фактический объём работы и другие обязательные задания в тот же период.

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

Для технической ветки используйте проверку платформы тестовым учеником, а не только вход администратора с расширенными правами.

Выберите исправление по собранным данным

Допустим, наблюдение показало, что часть участников успешно выполняет действие, но передаёт промежуточный файл вместо итогового. Это условное продолжение примера. Тогда разумно уточнить название результата и добавить образец состава файла; полная перезапись видео пока не обоснована.

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

Не обязаны существовать одна главная причина и одно универсальное решение. У разных учеников затруднения могут различаться. Полезнее сохранить несколько подтверждённых направлений работы, чем искусственно выбрать единственного виновника.

Закройте разбор повторной проверкой

После изменения проведите новое прохождение и отметьте, какие затруднения сохранились. Версии без подтверждения не удаляйте бесследно: укажите, что проверено и с каким ограничением. Это поможет следующему куратору не повторять те же догадки.

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

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