Примем как аксиому, что мы пишем вопросы не для того, чтобы самоутвердиться и показать командам, какие мы умные (это и так всем ясно и в доказательствах не нуждается), а для того, чтобы вопросы брались. Причем, для того, чтобы пакет выполнил свою спортивную задачу, необходимо, чтобы вопросы брались не всеми командами, участвующими в турнире. Чтобы выполнить это условие, необходимо априори оценить сложность вопросов в пакете. Тестирование на командах, безусловно, является достаточно сильным и действенным инструментом, но и оно не лишенно недостатков – другие условия игры, недостаток квалифицированных тестеров, несоответствие уровня игры тестеров уровню команд и т.д. Поэтому необходимы дополнительные инструменты для оценки сложности вопроса.
Прежде всего, я бы хотел разделить понятие «сложность вопроса» на три подпонятия:
1. Фактическая сложность вопроса
2. Сложность генерации правильной версии
3. Сложность выбора правильной версии
1. Фактическая сложность вопроса
Для оценки фактической сложности я обычно проверяю вопрос на Минимальное Необходимое Знание (МНЗ) для взятия вопроса и Минимальное Достаточное Знание (МДЗ) для взятия вопроса. Под МНЗ понимается знание, без которого взять вопрос можно, только попав пальцем в небо, под МДЗ – знание, обладание которым позволяет взять вопрос чистым знанием, без раскрутки. Вот, к примеру, вопрос с Кубка Кармиеля:
Вопрос:
"Да подождите, подождите, вы еще ничего не слышали!" – говорит герой этого фильма и начинает петь. Назовите этот фильм.
Ответ: "Певец джаза".
В данном вопросе минимально необходимое знание - это название первого звукового фильма, а минимально достаточное – знание источника цитаты.
Чем меньше минимальное достаточное знание, тем больше шанс, что произойдет «закорот» и вопрос возьмут без раскрутки. Чем больше минимальное необходимое знание, тем больше шанс, что команды не смогут ответить на вопрос, даже если раскрутят всю логическую цепочку. Для хорошего вопроса, на мой взгляд, МНЗ должно присутствовать, а МДЗ – отсутствовать у подавляющего большинства команд (в идеале – у всех, но всегда есть шанс, что кто-то прочел ту же самую редкую книгу).
Естественно, что наша оценка должна обязательно базироваться на уровне играющих команд – что хорошо для Московской Вышки, плохо для Второй Хайской Лиги, и наоборот. Кстати, объективности нашей оценке фактической сложности может добавить не только тестирование, но и тривиальный поиск факта в интернете – чем чаще он упоминается, тем больше людей на него могут просто случайно натолкнуться. В любом случае, полагаясь на знание игроками какого либо факта, следует подумать – хотим ли мы, чтобы знающие факт на этом вопросе получили преимущество перед теми, кто факта не знает. Если хотим – смело полагаемся на знание факта, если не хотим – правим вопрос.
2. Сложность генерации правильной версии
Сложность генерации правильной версии оценить намного труднее. Тут, кроме как тестирование, на мой взгляд, мало что может помочь. Один из немногих, наверное, полу-формальных способов – это подсчитать количество наводок на правильную версию. Если их нет совсем – вопрос, скорее всего, будет гробом, если их слишком много – кнопкой. К сожалению, многие авторы грешат и тем и другим, и наша задача, как редакторов, исправлять их ошибки, добавляя и усиливая и убирая и ослабляя наводки.
Кроме того, очень часто для того, чтобы игроку как-то использовать наводку, ему необходим перебор нескольких вариантов. Размер поля перебора как раз вполне можно поверить алгеброй, и сократить/расширить его для приведения вопроса к играбельному виду – одна из наших непосредственных задач.
Например,
Вопрос:
ИКС входил в известный "треугольник" и жил в России. А теперь Россия входит в ИКС. Как звали жену ИКСа?
Ответ: Лиля (Юрьевна Брик).
В этом вопросе три поля перебора – треугольников, организаций (и не только организаций) в которые входит Россия и женатых людей. На мой взгляд, размеры всех трех полей близки к бесконечности.
Кстати, то, что нам может показаться наводкой на правильную версию, кого-то может увести совсем в другую сторону, что плавно приводит нас к третьему аспекту сложности вопроса – сложность выбора правильной версии.
3. Сложность выбора правильной версии
К моему глубокому сожалению в последнее время сложилась тенденция максимально облегчать жизнь капитанам и сводить сложность выбора к минимуму. На вопросы навешиваются дополнительные ходы, вставляются фактические отсечки и т.д. Все это, конечно, необходимо, но ведь можно же постараться сделать выбор чуть менее очевидным, так, чтобы не лишать капитанов работы. Да, в вопросе необходимо дать основание для выбора, но основание это необязательно должно быть чисто фактическим.
При этом обязательно следует помнить, что игроки могут найти отсечку там, где вы и не предполагали, поэтому, во-первых, тестирование таких вопросов трижды обязательно, а во-вторых, в таких вопросах абсолютно не должно быть лишней инфорнмации – иначе эта лишняя информация может послужить кому-либо основание для неправильного выбора. Кстати, становится возможным изящный ход – в вопрос вводится якобы лишняя информация, которая, на самом деле, является основанием для выбора.
Не могу отказать себе в удовольствии и, напоследок, процитирую лучший, наверное, вопрос на тонкий выбор, который я играл в этом году:
Вопрос:
Чтобы при разработке системы проверить удобство ее предполагаемого пользовательского интерфейса, иногда применяют такой придуманный на Западе способ. Пользователя сажают перед муляжом интерфейса, за которым скрывается разработчик, симулирующий реакцию готовой системы. Назовите страну, которая упоминается в названии этого способа.
Ответ: Страна Оз.
Отсечкой от Турции для меня послужил вроде бы ни к селу ни к городу упомянутый Запад.
