Как выбрать идею для хакатона и сократить её до прототипа

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

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

Сформулируйте проблему до выбора инструмента

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

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

Если тема события требует определённую технологию, проверьте её роль в этом шаге. Она может быть обязательной частью решения, но не обязана занимать весь рассказ. Жюри всё равно потребуется понять, для чего вы её применили и что проверили.

Чтобы записать проблему, ограничения и ожидаемый результат, адаптируйте шаблон задачи для партнёра от Stavleak. Он поможет собрать вводные перед обсуждением идеи.

Сравните несколько вариантов одной короткой карточкой

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

Проверьте четыре вещи. Есть ли у команды доступ к данным? Можно ли выполнить обязательную интеграцию? Умеет ли хотя бы один человек проверить результат? Помещается ли основной сценарий в срок? Отрицательный ответ не всегда запрещает идею, но требует понятного решения, а не надежды.

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

Напишите демонстрацию до разработки

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

В разборе Sophia Sharif автор предлагает оценивать идеи через будущий путь демонстрации. Этот приём помогает увидеть обязательные части прототипа. Его не следует понимать как разрешение украшать показ возможностями, которых в проекте нет.

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

Найдите зависимость, которая может остановить всё

Иногда самая трудная часть выглядит маленькой. Интерфейс чата можно собрать быстро, а доступ к документам, качество поиска и корректные ссылки займут большую часть времени. Проверяйте риск до того, как команда потратит вечер на оформление.

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

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

Отделите обязательное от удобного

Разделите функции на три группы. Первая нужна для основного результата. Вторая делает его понятнее или надёжнее. Третья относится к будущей версии. Список должен быть коротким, чтобы команда действительно могла пользоваться им во время работы.

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

Для оставленных функций опишите минимальный критерий готовности. «Есть поиск» допускает множество трактовок. «По заданному запросу возвращаются подходящие документы и открывается исходный фрагмент» задаёт проверяемое поведение.

Сохраните возможность честно показать ограничения

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

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

Когда идея выбрана, зафиксируйте её одним абзацем и запишите исключённые функции. Новое предложение добавляйте только вместе с ответом, какую текущую работу оно заменяет. Затем распределите первые проверки по плану разработки прототипа. Начинайте с действия, которое быстрее всего покажет, осуществим ли главный сценарий.