На хакатоне времени постоянно не хватает – многие идеи приходится отсекать на лету. В спешке легко забыть, что проект будут смотреть и оценивать реальные люди, которые ожидают получить готовый MVP, соответствующий требованиям задачи. Технически выверенное, но неприменимое в реальном бизнесе решение не впечатлит жюри.
В статье разберемся, как создать на хакатоне привлекательный проект, который по достоинству оценят эксперты.
Изучите задачу
В описании задания почти всегда подробно расписан формат, в котором судьи ожидают получить решение от конкурсантов. Лучшее, что можно сделать – четко следовать этим рекомендациям и не заниматься самодеятельностью. Общие для всех требования – не прихоть экспертов, а необходимость:
- Как и у конкурсантов, время у судей ограничено. Они не могут себе позволить долго разбираться с незнакомыми форматами файлов и оформленными не по шаблону решениями.
- Проверка участников. Нередко организаторы после хакатонов приглашают авторов лучших проектов в команду. Умение сдавать работу в оговоренном формате – важный профессиональный навык.
Не игнорируйте экспертов
Хакатон – не просто соревнование. Почти всегда организаторы предлагают участникам образовательную программу – от пары митапов на коротких конкурсах до полноценных индивидуальных чек-поинтов на длинных. Ни в коем случае не пропускайте их, даже если будет казаться, что дедлайны горят, и лучше поработать над проектом, чем пообщаться с экспертом.
Консультация позволит оценить промежуточное состояние решения. На ML-соревновании у участников есть лидерборд – общий рейтинг точности модели, который помогает команде понимать, насколько хорошо она справляется с задачей. На продуктовом хакатоне такой общей метрики нет, но зато есть чек-поинты – их проводят эксперты, которые будут оценивать проекты в финале. Кто, как не судья, лучше всего объяснит, что не так с решением и где его можно улучшить?
Чем полезны встречи с менторами:
- Погружение в задачу. Из текстового описания не всегда может быть ясно, на какие аспекты задания важно обратить внимание. Эксперт расскажет, какие бизнес-проблемы решает хакатон, что поможет более точно расставить акценты и наметить план работы.
- Указание на недоработки. Опытный специалист сразу скажет, какие элементы решения тянут его вниз и не дадут попасть в финал. У таких ошибок должен быть максимальный приоритет.
- Ответы на вопросы. Задача эксперта – помочь конкурсантам, чтобы получить на хакатоне как можно больше качественных проектов. Не бойтесь показаться некомпетентным и спрашивайте обо всем, что непонятно и вызывает сомнения.
Никогда не отмахивайтесь от рекомендаций, полученных на чек-поинтах. Эксперты потратили месяцы на то, чтобы организовать хакатон, продумать и подготовить задания. Они максимально глубокого погружены в проект и прекрасно знают, какие решения хотят получить в итоге. Пренебрегать советами от таких людей – большая ошибка, которая гарантированно не позволит занять высокое место.
Команды, которые внимательно слушают экспертов и учитывают их предложения, регулярно завоевывают призовые места.
Вопросы на чекпоинтах, которые стоит обязательно обсудить:
- Какие элементы проекта самые многообещающие и на чем сконцентрировать внимание? От чего лучше отказаться?
- Как решить проблему, с которой столкнулись? Какие инструменты можно для этого использовать?
- Насколько удобно пользоваться сервисом? Что необходимо доработать в UI?
- Может ли быть решение внедрено в реальный бизнес? Что для этого нужно доработать?
- Как подготовить презентацию проекта? Как будет проходить защита?
Сделайте продуманный дизайн
На хакатоне всегда велико искушение с головой погрузиться в разработку, а создание внешнего вида и интерфейса отложить на самый конец (и, конечно же, не успеть). Может показаться, что крутая техническая реализация принесет гораздо больше баллов, чем дизайн, а жюри представить как команду суровых технарей, которые будут пристально анализировать каждую строчку кода. Но это не так.
Гораздо продуктивнее думать о судьях как о простых пользователях, которые хотят с комфортом использовать ваш сервис, а не разбираться в назначении множества одинаковых неподписанных кнопок без иконок. Среди экспертов будут и специалисты, которые оценят техническую часть, но они прекрасно понимают сжатые сроки хакатона и не будут придираться, если где-то не соблюдены принципы объектно-ориентированного программирования или использован неоптимальный паттерн.
С другой стороны, никто из жюри и от дизайна не будет ожидать инноваций уровня Material Design. Достаточно сделать интерфейс аккуратным и простым в использовании.
Что здесь может помочь:
- Не оставлять разработку внешнего вида на потом. Лучше всего вести работу параллельно. Добавили новую функцию в проект – сразу создайте под нее соответствующую кнопку.
- Найти дизайнера в команду. Он сможет все время посвятить работе над интерфейсом и сделает это качественнее, чем любой другой специалист.
- Использовать фронтенд-фреймворки и дизайн-системы. Они значительно ускорят разработку внешнего вида благодаря готовым модулям и иконкам.
- Проводить тестирование. Покажите свой проект знакомым, друзьям, родственникам, коллегам – всем, кто может дать фидбэк. Взгляд со стороны обычного пользователя, впервые запустившего сервис, поможет увидеть недоработки, которые команда не замечает.
Убедитесь, что все работает
Жюри доходит до вашего проекта. А он не запускается – команда забыла оплатить сервер, на котором должно работать веб-приложение. Такие обидные поражения происходят на хакатонах регулярно. Проверьте, что ваше решение работает стабильно, и судьи могут посмотреть его.
- Баги. Кода без багов не бывает. Особенно много их будет в проекте, написанном за выходные. В таких условиях важно распределять ошибки по значимости и правильно выставлять приоритеты. Лучше исправить один критический баг, приводящий к вылету программы, чем десяток мелких визуальных.
- Оптимизация. Решение должно выдавать результат в приемлемое время. Если проект получился «задумчивым», а времени на исправление уже нет, то дайте пользователю понять, что приложение не зависло, а загружает данные – добавьте прогресс-бар, песочные часы и т.д. Главное не увлекаться оверинжинирингом и не ставить высокую производительность как самоцель.
- Совместимость. «А на моем ноутбуке все запускается» – плохой аргумент на финальной защите проекта. Проверьте работоспособность приложения на как можно большем количестве устройств и конфигураций. Постарайтесь охватить хотя бы самые популярные разрешения экранов, браузеры и операционные системы, в том числе без последних обновлений. Не лишним будет сдуть пыль со старого ноутбука – если решение нормально заработает даже на нем, то и с новым «железом» проблем, скорее всего, не возникнет.
Все советы из статьи лучше всего отрабатывать на практике. Не пропустить новое интересное IT-соревнование поможет наш регулярный дайджест.
