ОбразованиеКак ускорить без найма
Как проверять домашние задания быстрее, не теряя качества?
Проверяющие спешат, задания возвращаются на доработку, нагрузка растёт сама от себя.
Что дал расчёт
- Доля доработок
- было
3417%−17 п.п. - Фактический срок проверки
- было
3819ч−50% - Работ на проверяющего в день
- было
1714шт−18%
На потоке 64 800 работ в год это2,6 млн ₽в год
Что за процесс и где он ломался
Онлайн-школа: 18 проверяющих, около 5400 работ в месяц, норматив проверки — 24 часа. Работа может быть отправлена на доработку.
Доработанная работа возвращается в ту же очередь и проверяется заново — то есть каждая отправка на доработку создаёт ещё одну единицу работы для отдела.
Вопрос, на который отвечали
Как проверять домашние задания быстрее, не теряя качества?
Признаки, по которым стало понятно: дело не в людях
При росте потока проверяющие ускоряются, качество проверки падает, доля доработок растёт — и возвращается в тот же поток второй раз.
Как процесс превратили в имитационную модель
В модель заложили поток работ, длительность проверки, зависимость доли доработок от спешки и повторное поступление доработанных работ.
Связка «быстрее проверяешь — чаще возвращаешь» задана явной зависимостью: при сокращении времени проверки доля доработок растёт. Именно эта петля и превращает ускорение в замедление.
Какие данные взяли и что честно допустили
- Поток
- 5400 работ в месяц, пики в конце учебного модуля
- Проверка
- 11 минут при нормальном темпе, 7 — при спешке
- Доля доработок
- 21% при нормальном темпе, 38% при спешке
- Не моделировали
- апелляции по оценке
Отчёт симуляции: что показал расчёт
Здесь будет живой отчёт симуляции
Расчёт по этому кейсу ещё не прогнан. После прогона сюда встанет тот же отчёт, что видит пользователь Storm: очереди, загрузка ресурсов, время цикла и стоимость одной заявки по каждому сценарию.
Какие сценарии прогнали и чем они отличались
| Сценарий | Что меняли |
|---|---|
| Как есть Базовый | 18 проверяющих, темп подстраивается под очередь |
| Фиксированный темп проверки | Спешка запрещена, очередь копится |
| Чек-лист типовых ошибок студентам | Снижение доли доработок на входе |
| Чек-лист и фиксированный темп | Оба изменения |
Было и стало
- Было
- Стало
Доля доработок , %
Фактический срок проверки , ч
Работ на проверяющего в день , шт
Выполнение норматива 24 часа , %
Стоимость проверки работы , ₽
| Метрика | Было | Стало | Изменение |
|---|---|---|---|
| Доля доработок , % | 34 | 17 | −17 п.п. |
| Фактический срок проверки , ч | 38 | 19 | −50% |
| Работ на проверяющего в день , шт | 17 | 14 | −18% |
| Выполнение норматива 24 часа , % | 46 | 92 | +46 п.п. |
| Стоимость проверки работы , ₽ | 210 | 170 | −19% |
Что показал расчёт
Спешка увеличивает нагрузку, а не уменьшает
Каждая доработка возвращается в очередь: ускорение проверки на треть даёт рост потока на две трети.
Чек-лист студентам снимает половину доработок
Дешевле любых изменений внутри процесса проверки.
Работ на проверяющего стало меньше, а срок — вдвое короче
Потому что исчезли повторные проверки одного и того же.
Что оказалось не так, как считали
Как проверять домашние задания быстрее, не теряя качества?Чтобы проверять быстрее, надо было перестать торопиться. Петля обратной связи через доработки превращала экономию четырёх минут в лишнюю проверку целиком.
Что решили сделать и что получилось
Ввели чек-лист типовых ошибок для студентов и запретили спешку как способ разгрузить очередь. Ставку на качество входа считали приёмом «С первого раза правильно», эффект по циклу — приёмом «Снизить переделки».
Норматив 24 часа стал выполняться в 92% случаев тем же составом.
Приёмы оптимизации, которые здесь сработали
Почему на этот вопрос отвечает имитационное моделирование, а совещание — нет
Процессы с возвратом на доработку содержат петлю обратной связи, и её поведение контринтуитивно: локальное ускорение усиливает саму себя через рост брака. Такое считается только прогоном, а не арифметикой.
Петля видна по числам: доля доработок 34%, и из-за неё фактический срок проверки 38 часов при нормативе в 24.
Где этот вывод не работает
Эффект чек-листа оценён по пилоту на одной группе. На других предметах доля доработок может снижаться слабее.
Частые вопросы по этому расчёту
Как измерить «спешку» в модели?
Через зависимость доли доработок от времени проверки — восстановлена по историческим данным: при нормальном темпе 11 минут доля доработок 21%, при спешке 7 минут — 38%. Это показатель качества по факту, не предположение.
Если быстрая проверка в 7 минут даёт 38% доработок, почему люди не работают качеством?
Когда поток растёт из 5400 работ в месяц, люди ускоряются по необходимости разгрузить очередь, не по мотивации. Ускорение на треть добавляет две трети доработок обратно: каждая возвращается в ту же очередь и создаёт ещё одну единицу работы. Спешка усиливает саму себя — эту петлю видит модель, интуиция её не видит.
Чек-лист помогал в пилоте — насколько полезен на всех предметах?
На пилотной группе дал −17 п.п. доработок (с 34% до 17%). Но это один предмет: ошибки могут быть совсем другие. Нужна своя историческая база по каждому предмету, чтобы прогнать модель с реальными коэффициентами для 18 проверяющих.
Нужно ли проверяющих учить про петлю обратной связи?
Да, если вы хотите поддержку запрета на спешку как метода разгрузки. Без понимания выглядит как требование, с пониманием — факт: каждые 4 минуты спешки стоят вам одной целой проверки в цикле 5400 работ. Это меняет восприятие нормы работы.
Ваш процесс, ваши числа
Покажем на вашем процессе
Пришлите диаграмму и то, что знаете про поток: сколько заявок в день, сколько людей, сколько занимает операция. Соберём модель, прогоним сценарии, которые вы назовёте, и разберём отчёт вместе — с очередями, загрузкой ресурсов, сроком и стоимостью заявки.
- Присылаете диаграмму и три-четыре цифры про поток
- Собираем модель и прогоняем сценарии, которые вы назовёте
- Разбираем отчёт вместе и обсуждаем, что из него следует
Первый процесс считаем бесплатно: нужна диаграмма и несколько цифр по потоку.