Егор Миронь — фулстек-разработчик и неоднократный участник хакатонов в качестве конкурсанта и члена жюри — продолжает рассказывать о том, как участвовать в хакатоне так, чтобы не только произвести хорошее впечатление на судей, но и получить максимум пользы и удовольствия.
Часть 1, Часть 2, Часть 3, Часть 4
В этот раз разбираемся, как найти подходящую идею и грамотно подойти к ее реализации.
Shutterstock / Cozine
Идея: где ее взять?
Прежде всего, идея должна исходить из тематики самого хакатона. Нет смысла приходить с приложением для продажи билетов в цирк на хакатон по блокчейну. Если только вы не придумаете, как завязать продажу билетов на блокчейн-технологию, и самое главное, не обоснуете необходимость такой реализации, показав потенциальную выгоду.
Но часто хакатоны проходят и без жестких тематических рамок. В таком случае, чтобы придумать идею, над которой вы сможете работать, стоит подумать над проблемой, которую вы хотели бы решить.
В первую очередь лучше подумать о тех проблемах, с которыми вы сталкиваетесь сами. Так будет проще понять корень проблемы и придумать интересное решение.
Если же вас заинтересовала проблема из чужого опыта или в совершенно не близкой вам сфере и вы видите потенциальное широкое поле для эксперимента, следует подготовиться заранее и сделать предварительное исследование. Опросите тех, кто сталкивается с этой проблемой, соберите мнение нескольких человек, которые знакомы с задачей с разных сторон.
Проанализируйте рынок: возможно, уже существуют готовые продукты, решающие похожие задачи в этой же или в смежных областях. И если у вашей идеи есть конкуренты, подумайте, чем ваше решение может быть лучше. Что вы можете привнести в уже существующие продукты?
Когда идея сформирована и, возможно, даже есть предварительное видение самого продукта, не стоит останавливаться. Специфика разработки собственного продукта в том, что она, как правило, итеративна. И это касается не только самой программы, но и идеи.
Даже если вам кажется, что вы все продумали, будьте готовы к тому, что исходя из новой полученной информации вы можете поменять идею как частично, так и кардинально. Стоит понимать, что это нормальный живой процесс создания продукта, и следует относиться к таким изменениям не как к ошибкам, а как к итерациям.
На хакатоне вам предоставится возможность пообщаться со специалистами в разных областях, и я бы советовал максимально прислушиваться к различным мнениям, особенно к советам менторов, которые уже имеют опыт в похожих областях.
Shutterstock / GaudiLab
Разработка собственного продукта — это постоянное поддержание баланса между требованиями рынка, ограничениями со стороны разработки и собственным полетом фантазии, и тут важно учитывать все три составляющие.
А если у вас нет своей идеи, но поучаствовать все же хочется — не беда. Вы можете просто присоединиться к команде, чья идея вам ближе всего.
Грамотная реализация — это как?
Придуманная идея для продукта может быть достаточно обширной, масштабной и требовать массу ресурсов для реализации. В таком случае нельзя стремиться полностью реализовать все в рамках хакатона.
Надо иметь ввиду и трезво оценивать имеющиеся ограничения: это и достаточно короткий временной промежуток, и недостаток технического опыта у участников команды, и недостаток ресурса: у вас легко может не быть нужного числа разработчиков, дизайнеров, бизнес-аналитиков и т. д.
Поэтому, когда соберете команду и проанализируете ее возможности, сфокусируйтесь на том решении, которое будет максимально отражать суть идеи в малых масштабах и покажет потенциальную ценность продукта при должных вложениях.
Shutterstock / Matej Kastelic
Для этого стоит продумать, какую функциональность можно будет развивать в будущем, подумать на стратегией и способом масштабирования продукта в дальнейшем. Все это вы не успеете реализовать в рамках хакатона, но сможете рассказать во время презентации продукта.
Именно поэтому выделю пару ключевых моментов.
Начните с малого
В рамках создания продукта для хакатона гораздо важнее показать принцип работы вашего приложения или сервиса, а не поразить жюри масштабом разработки или обилием сопутствующих функций.
Техническое решение может быть довольно изящным и интересным, но намного важнее, чтобы оно работало. Поэтому лучше всего исходить из принципа MVP (minimum viable product).
Сфокусируйтесь на том, что будет максимально отражать вашу идею при минимальных масштабах продукта и ресурсных вложениях. Не стоит тратить время на реализацию 30 фильтров для списков, если в целом одного-двух достаточно, чтобы показать их наличие.
Лучше оговорить потенциальные возможности во время презентации, чем показать их плохо работающими.
На одном из хакатонов у нашей команды была идея разработки маркетплейса для поиска и оказания услуг локального характера ( в радиусе одного города ). Для демонстрации работы был выбран самый распространенный сценарий использования подобных сервисов:
- Пользователь заходит на сайт.
- Вводит в поиске, какую услугу он хочет получить.
- Видит список объявлений, соответствующих критерию поиска.
- Заходит в наиболее подходящий для него вариант.
- Видит контакты продавца услуги
Этот достаточно простой сценарий описывает и основную идею, и реализацию нашего проекта. Притом каждый из этих пунктов легко можно масштабировать, расширяя, например, критерии поиска, улучшая поведение алгоритма подбора объявлений или добавляя другие возможности для контакта с продавцом.
Определите оптимистичный сценарий
То, что вы будете показывать жюри — это презентация самого продукта. У вас будет довольно короткий отрезок времени, чтобы показать возможности вашей технической реализации и объяснить все так, чтобы жюри и участники поняли и запомнили вашу идею. Для этого вы можете определить сценарий, по которому пройдет пользователь в процессе решения своей проблемы.
Важно, чтобы этот сценарий был оптимистичным, то есть в начале вы имеете какую-то проблему, а в конце у вас есть довольный пользователь, который эту проблему решил с помощью вашего продукта.
На этом этапе не стоит сильно фокусироваться на всех пограничных случаях и пытаться предусмотреть все возможные помехи. Над этим стоит подумать и составить список таких сценариев — чтобы у вас были готовые ответы или даже целый стратегии на случай, если жюри или участники зададут вопросы, касающиеся таких кейсов.
Но для непосредственной технической реализации и ее демонстрации стоит остановиться на определенном сценарии, на который у вас, по предварительным оценкам, хватит времени и ресурсов.
Shutterstock / nd3000
Определите тип продукта
После того как у вас сформирована идея, первые требования для MVP и определен оптимистичный сценарий, вы можете подумать над тем, какой именно тип продукта у вас будет. Будет ли это веб-сайт, мобильное приложение или какой-то сторонний сервис?
Чтобы определиться с типом продукта, проанализируйте следующие ограничения:
- Ограничения со стороны требований хакатона. Хотя на сегодняшний день можно обойти эти ограничения, использовав библиотеки и инструменты, позволяющие заворачивать одну функциональность в другую, все же стоит продумать этот момент заранее и стараться максимально соответствовать требованиям хакатона.
-
Ограничения со стороны задачи. Если мы говорим о проблеме, которая требует решения «на лету», стоит подумать о мобильном приложении или дополнении к какому-то уже существующему приложению (Telegram-бот, браузерное расширение и т.д.). Если же задача требует большего времени работы над ней или же накладывает определенные технические ограничения, стоит подумать над веб-приложением, веб-сайтом и т.д.
Важно понимать корень проблемы, чтобы предложить нужный сервис для ее решения.
-
Ограничения со стороны экспертизы участников. Здесь все довольно просто: если вы планировали iOS-приложение, но у вас нет достаточного количества iOS-разработчиков, стоит подумать в сторону веб-разработки. Можете указать во время презентации, что вы считаете приложение более оптимальным решением, но у вас нет должных ресурсов.
Этот совет скорее применим к тем командам, которые были сформированы уже на самом хакатоне.
Если же вы продумали идею заранее и пришли со своей командой, достаточно компетентной в нужных областях, вы довольно быстро определитесь с типом продукта и сможете приступить к разработке, о которой мы подробнее поговорим в следующей статье.
Фото на обложке: Shutterstock / Khakimullin Aleksandr
Нашли опечатку? Выделите текст и нажмите Ctrl + Enter