Егор Миронь — фулстек-разработчик и неоднократный участник хакатонов в качестве конкурсанта и члена жюри — продолжает рассказывать о том, как участвовать в хакатоне так, чтобы не только произвести хорошее впечатление на судей, но и получить максимум пользы и удовольствия.
Часть 1, Часть 2, Часть 3, Часть 4
В этой статье Егор рассказывает, как сделать процесс разработки простым и при этом максимально эффективным.
Shutterstock / Joyseulay
Каким должен быть процесс?
Забудьте о менеджменте
Процесс разработки продукта может быть довольно сложным и объемным, требующим организации параллельной работы нескольких команд разработчиков, дизайнеров и аналитиков. Однако для быстрого создания небольшого приложения или сервиса следует стараться вести работу последовательно и пытаться максимально упрощать взаимодействие внутри команды.
Скрам, канбан, стендапы — все это очень хорошо, но не для хакатона.
По моему опыту, попытки развернуть сложный процесс разработки оборачиваются пустой тратой времени. Нет нужды прилагать усилия для создания досок в Trello, Jira или любом другом таск-менеджере, так как все участники сидят рядом друг с другом и всегда есть возможность задать вопрос здесь и сейчас.
Вы можете определить скоуп задач, написав их на стикере или просто оговорив словами. Намного эффективнее договариваться обо всем «на лету», чем пытаться переводить коммуникацию в онлайн-формат.
Максимально используйте уже готовые решения
В большинстве случаев в процессе создания продукта вам наверняка придется иметь дело со стандартными функциями, так или иначе характерными для всех приложений/сервисов подобного рода (регистрация, авторизация, работы с базами данных и т.д.).
Cовершенно нет смысла писать их с нуля, так как существует масса ресурсов, инструментов и готовых библиотек, которые позволят избежать ненужной траты времени и сил.
Это даст возможность уделить дополнительное время расширению основной функциональности или же более подробно и детально продумать идею и презентацию.
Например, во время участия в Garage48 мы создавали продукт для связи потенциальных покупателей услуг и продавцов этих услуг. Мы взяли готовую библиотеку UI-компонентов Material UI, чтобы не тратить время на проработку деталей и показать решение в приятном виде.
Для backend на Node Js мы решили выбрать Sails Js. Это позволило нам не писать много шаблонных деталей системы, таких как CRUD-операции, роутинг, и не привязываться к конкретному frontend-фреймворку.
Позаботьтесь о дизайне
Дизайн на хакатоне может быть не столь важен на первый взгляд. Однако хороший продукт должен помогать пользователю решать проблему, а не создавать новую в виде неочевидного и неинтуитивного интерфейса.
Чтобы создать качественный интерфейс, в любом случае необходимо подумать об удобстве использования, оно же user experience.
Поэтому неплохо иметь в команде UX-дизайнера, который сможет подсказать и сориентировать как именно должен выглядеть продукт, чтобы решить определенную проблему.
Стоит иметь в виду, что на хакатоне не стоит распыляться на красивые шрифты и оригинальные иллюстрации внутри продукта. Если у вас в команде есть UI-дизайнер, стоит вложиться в стиль и эстетику презентации, это поможет создать вау-эффект и обеспечить запоминаемость.
Что касается самого продукта, я бы советовал максимально использовать готовые библиотеки, такие как Material UI, Bootstrap, NG Lightning и др. Эти инструменты также помогут, если у вас в команде и вовсе нет дизайнера.
Shutterstock / BEST-BACKGROUNDS
Покажите мне код!
Многое зависит от того, включает ли в себя данный хакатон код ревью. Бывали случаи, что хакатоны выигрывались командами, у которых и вовсе не было работающего прототипа, лишь презентация и нарисованные дизайнером макеты. Но такие мероприятия следует называть скорее конкурсом идей, нежели хакатонами.
Как правило, вы должны будете предоставить ссылку на репозиторий со всем кодом вашего проекта — это обязательное требование, без которого команду просто не допустят к финальному этапу.
Если ваш продукт нацелен на инновационный подход к решению какой-либо типовой задачи, хорошо будет продемонстрировать, как вы этого добились и какой именно сервис за это отвечает.
Хочу отметить отдельно, что не стоит беспокоиться за стилистику или структуру методов и папок — на это смотреть никто не будет.
Сфокусируйтесь на отработке основного сценария
Тут нужно понимать, что время крайне ограничено, и нет смысла тратить его на продумывание всех corner cases или писать тесты.
Следует максимально сфокусироваться на выполнении рабочего сценария, который был определен на этапе реализации идеи. Именно его вы будете показывать в течении презентации проекта и тут крайне важно, чтобы все работало именно так, как и было запланировано, без багов и ошибок.
Также нет смысла на данном этапе прорабатывать отдельно те случаи, когда у вас еще нет данных. Жюри не смотрит на красоту empty states и никто не станет читать фейковые данные.
Не стоит писать отдельный сервис авторизации. В процессе разработки приложений для хакатонов мы делали допущение, что пользователь уже прошел этап регистрации и первоначальное наполнение контентом. Достаточно сделать фейковую авторизацию, просто чтобы продемонстрировать экран, с которого начинает пользователь, и добавить записи напрямую в базу данных.
Также мы не придавали значение дополнительному визуальному оформлению на этом этапе.
Минимизируйте конфликты в разработке
Если в команде несколько разработчиков, крайне важно запараллелить работу, чтобы не мешать друг другу и не создавать конфликты в версиях приложения. Постарайтесь минимизировать пересечения и сделать так, чтобы каждый человек в команде отвечал за свою часть.
Скорее всего, готовое решение удастся собрать только к концу хакатона. Поэтому важно заранее продумать части, которые в итоге должны соединиться.
Например, если вы решили показать несколько сценариев, можно разделить работу по ним. Также frontend легко может работать параллельно, договорившись с backend’ом о формате данных, которые тот будет отправлять.
Я делаю еще немного хитрее: предполагаю что ответ backend’a придет в самом удобном для меня виде, и если backend присылает данные в другом формате, преобразую их сразу после того, как получил.
Лучшее решение — быстрое решение
Избегайте траты времени на поиск элегантного решения задачи, если у вас уже есть какой-либо рабочий вариант.
Чаще всего лучше решить задачу «в лоб», чем тратить ресурс на оптимизацию, которая на данном этапе менее важна, чем отработка успешного сценария. У вас будет ограниченное количество данных, и практически любой алгоритм справится с задачей за адекватное время.
Если вы планируете и дальше развивать продукт, сделанный в рамках хакатона, то в будущем у вас будет больше времени и ресурсов на рефакторинг и более детальную проработку архитектуры с учетом всех нужд.
Подытожим:
- упрощайте взаимодействие внутри команды,
- используйте готовые инструменты и библиотеки,
- не забудьте про user experience, но не увлекайтесь красивыми шрифтами и картинками,
- сфокусируйтесь на реализации рабочего сценария,
- делите работу на части и действуйте параллельно, чтобы не мешать друг другу,
- помните, что лучше решить задачу «в лоб», чем тратить время и ресурс на оптимизацию.
Продолжение читайте здесь.
Фото на обложке: Shutterstock / MIND AND I
Нашли опечатку? Выделите текст и нажмите Ctrl + Enter
Материалы по теме
ВОЗМОЖНОСТИ
24 апреля 2024
25 апреля 2024