Как связать критерии с целью хакатона, описать шкалу, распределить проекты между судьями и проверить итоговые результаты.
·4 мин чтения·
Критерии оценки хакатона должны объяснять участнику, какую работу показывать, а судье, на какие свидетельства опираться. Слова «качество», «инновационность» и «эффект» без описания шкалы оставляют слишком много места личным трактовкам. Для каждого критерия укажите наблюдаемое основание оценки.
Начните с цели события. Если хакатон посвящён проверке технических подходов, критерии должны позволять оценить реализацию и эксперимент. Если задача требует понимания пользовательского процесса, включите соответствующую проверку. Не добавляйте бизнес-показатели только потому, что они встречались в чужом конкурсе.
Отделите допуск от качества
Формальные требования определяют, может ли проект участвовать в оценке: срок подачи, состав команды, обязательные материалы и соблюдение правил. Оценочные критерии определяют качество допущенной работы. Смешивание этих двух уровней затрудняет объяснение результата.
Например, отсутствие обязательной ссылки на код требует предусмотренной регламентом процедуры проверки. Нельзя автоматически заменить её снижением балла за «техническую сложность», если это другой критерий. Последствия нарушения должны быть известны до сдачи.
Назначьте ответственных за проверку комплектности и спорных случаев. Судья, которому дали несколько минут на демонстрацию, не должен одновременно искать недостающие файлы и придумывать санкцию. Это отдельная работа организатора.
Опишите критерий через свидетельства
Для соответствия задаче попросите показать связь сценария с опубликованным брифом. Для реализации определите, что можно проверить в прототипе или материалах. Для пользовательской проверки укажите, какие наблюдения команда должна описать и как отличать их от предположений.
Старайтесь не оценивать одно свойство несколько раз. Если убедительность питча, качество подачи и впечатление от выступления имеют отдельные большие веса, сценическая уверенность может вытеснить смысл технического конкурса. Оставьте только те различия, которые действительно нужны.
Критерий оригинальности тоже нуждается в пояснении. Новая комбинация известных инструментов, самостоятельная реализация и новизна задачи представляют разные свойства. Выберите подходящее определение и объясните, что считается достаточным подтверждением.
Необязательно начинать матрицу с пустого листа. Адаптируйте шаблон критериев оценки Stavleak, проверьте веса и примеры на пробных проектах.
Пример шкалы для рабочего сценария
Для критерия «работоспособность основного сценария» можно использовать такой учебный пример:
Нижний уровень: действие описано, но его выполнение не показано.
Средний уровень: основной путь работает на обозначенных данных, ограничения раскрыты.
Верхний уровень: основной путь воспроизводится, а важные ошибки обработаны и объяснены.
Это пример описаний, не готовая система баллов. Количество уровней, веса и пороги задаёт организатор. Убедитесь, что судья может применить шкалу за отведённое время и что участник способен понять её до разработки.
Если используется итоговая взвешенная оценка, опубликуйте способ расчёта. Заранее определите порядок при равенстве результатов, пропущенной оценке и самоотводе судьи. Эти случаи нельзя оставлять на импровизацию после просмотра таблицы лидеров.
Проведите калибровку жюри
До начала оценки дайте судьям один учебный проект или запись прошлого события, которую разрешено использовать. Попросите оценить независимо, затем обсудите расхождения. Задача встречи состоит в общем понимании критериев, а не в требовании одинаковых вкусов.
Уточните, что делать, если информации недостаточно. Судья может задать вопрос, отметить отсутствие свидетельства или обратиться к организатору по предусмотренной процедуре. Он не должен достраивать результаты тестирования по уверенности выступающего.
Проверьте форму оценки на этом же примере. Участники жюри должны уметь сохранить результат, исправить ошибку до закрытия и сообщить о конфликте интересов. Технический инструктаж полезнее в спокойной обстановке до первого реального проекта.
Распределите нагрузку и конфликты
Посчитайте доступное время с учётом вопросов, переходов и записи комментариев. Распределите проекты так, чтобы каждый получил предусмотренное число независимых просмотров. Для узких направлений проверьте наличие подходящих специалистов.
Соберите сведения о связях судей с командами и проектами через рабочий процесс организатора. Наставничество, совместная работа или личная заинтересованность могут потребовать самоотвода. Правило должно быть определено заранее и применяться последовательно.
В плане судейства MLH отдельно разбираются распределение проектов и пробный запуск процесса. Конкретный метод ранжирования выбирайте под своё событие и сообщайте участникам до финала.
Собирайте полезные комментарии
Просите судью указать наблюдение, основание оценки и один вопрос или следующий шаг. Комментарий «слабая реализация» не помогает понять результат. Полезнее написать, какой заявленный сценарий не удалось воспроизвести и какой информации не хватило.
Отделите замечания о презентации от оценки продукта. Если показ был неясным, это можно отметить прямо. Не приписывайте команде отсутствие функции только потому, что её не было на слайде, когда условия позволяют проверить материалы отдельно.
Уточните, какая часть комментариев будет передана участникам. Судьи должны знать аудиторию записей. Уберите сведения о других командах и личные оценки людей; обратная связь должна касаться представленной работы.
Проверьте итог до объявления
Сверьте комплектность оценок, правильность формулы, обработку самоотводов и выполнение формальных условий. Сохраните итоговую версию и ответственного за подтверждение. Если обнаружена ошибка ввода, исправляйте её по прозрачной процедуре с записью причины.
Не меняйте веса после того, как увидели лидеров. Если возникла неописанная ситуация, зафиксируйте решение уполномоченных организаторов и объясните его применение. Затем внесите вывод в подготовку следующего регламента.
Результаты объявляйте после завершения проверки. Порядок обращений участников и допустимый предмет пересмотра должны быть описаны в правилах хакатона. Это помогает отличить исправление фактической ошибки от несогласия с профессиональной оценкой.
