+ 7 (495) 123-30-51

заполнить бриф
hr@dhabits.ru
hello@dhabits.ru
Назад

Павел Колбасов о подготовке к хакатону «Цифровой прорыв»

В 2021 году проходит третий сезон всероссийского конкурса «Цифровой прорыв». Он включает в себя серию хакатонов, онлайн-чемпионат по Data Science, Machine Learning и Искусственному интеллекту, а также образовательную программу. К хакатону со своей командой готовится Java-разработчик Павел Колбасов.

Сейчас я работаю на проекте СберСпасибо Java-разработчиком. Проект очень масштабный, и он мотивирует меня развиваться в свободное время. Поэтому когда ко мне пришел друг с предложением поучаствовать в хакатоне, и я согласился. Он Backend-разработчик, как и я. В феврале начали собирать команду, нашли Frontend-разработчика, Android-разработчика и специалиста широкого профиля — менеджер, аналитик, QA. Таким составом мы можем выкатить полноценное web или мобильное приложение. Ранее никто из нас не участвовал в хакатонах, но опыт разработки у всех большой — что-то может получиться.

По условиям хакатона можно участвовать только в двух секциях, всего их восемь. Мы решили участвовать в самых последних секциях, начиная с сентября. Выбираем между секциями Lifetech и FinTech, окончательное решение примем, когда увидим предлагаемые кейсы.

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

Раз в две недели мы созваниваемся с командой, чтобы синхронизироваться по задачам на доске, а также для обсуждения кейсов.

Материалы для подготовки

В основном мы используем кейсы и видео с прошедших этапов Цифрового прорыва. Мы анализируем решения команд, разбираем, почему выиграло конкретное решение. Также устраиваем мозговые штурмы, решаем, какой мы бы выбрали кейс для реализации, как бы делали его.

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

Наш состав: два Backend’а (Java), Androind, web (PHP + JS), поддержка (QA, аналитика, менеджмент).

Наши достоинства:

  • все специалисты Senior уровня с большим опытом промышленной разработки в распределенных командах;

  • есть возможность делать как web, так и android разработку;

  • есть опыт разработки приложений для банковской, медицинской, страховой сфер;

  • есть опыт преподавания в институте.

Наши недостатки:

  • нет компетенций в сфере ML и BigData;

  • нет опыта участия в хакатонах (соревнованиях на выносливость);

  • команда распределена по разным городам;

  • нет дизайнера — будет страдать визуал;

  • избыточность узких специалистов (может не потребоваться);

  • недостаток узких специалистов (на frontend — 1, на mobile — 1), некому помочь в реализации.

Закрыть наши недостатки может хорошая идея для кейса. Хорошо бы, чтобы основная часть команды владела предметной областью (сталкивалась/сталкивается с ней по жизни).

Критерии оценки решений технологических кейсов на хакатонах:

1) Прототип

2) Решение основной проблемы. Основную проблему подробно кейсодержатель описывает в интервью ближе к началу хакатона. Нужно ее держать в фокусе.

3) Разработка и внедрение. У нас хороший продакшн стек — Java + Web или Java + Android, на чем пишется значимое количество крупных сервисов.

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

5) UI/UX. У нас нет дизайнера. Как выкручиваться? Стоит брать кейсы, в которых это не критически важно.

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

7) Аналитика. Нужен человек, который будет документировать и делать презентации. У нас такой человек есть. Документирование REST-сервисов можно сделать через Swagger на уровне кода.

Примеры краткого анализа кейсов
Предлагается сделать web или мобильное приложение с несколькими ролями пользователей: работодатель, студент, админ и т. д. Технически команда владеет всеми технологиями для реализации данного кейса. Все члены команды были студентами относительно недавно, часть были преподавателями и имеют прямой доступ к студентам, чтобы провести мини-исследование, понять как можно привлечь студента и выявить новаторские идеи. Идеи не завязаны на UX/UI. Делать лучше web-версию, как более подходящую для идеи обучения. На этот кейс подошла бы команда в составе: Web, Android, Back, Back, Аналитик. Этот кейс подходит нашей команде.
Команда владеет набором компетенций для решения этого кейса, но многие члены команды будут очень слабо задействованы. Кейс сильно привязан к UX/UI и web-разработке. Не стоит брать этот кейс.

Подошла бы команда в составе: Web (JS), Web (JS), Дизайнер, Back, Аналитик/QA/Управленец.
Кейс не подходит для нашей команды. Нужно делать плагин для системы Moodle. Она написана на php. Только один член команды его знает. Также тут большой упор на идею геймификации процесса обучения, нам не хватает знаний.

На этот кейс подошла бы команда в составе: Web (PHP + JS), Web (PHP+JS), Дизайнер, Аналитик (специалист по геймификации), Управленец.
Кейс более-менее подходит на нашу команду, но хуже, чем кейс РосАтома. Основной упор тут на Back, знания есть. Задача может свестись к ETL-процессам, CQRS, кэшированию, OLAP, а может потребовать (вероятность очень высока) применения некоторых BigData фреймворков. С последним тяжело. Некоторые знания есть, но их может не хватить. Также это тяжело с точки зрения инфраструктуры. Нужно много ресурсов на эмуляцию реальной системы, обоснования пропускной способности, нагрузочных тестов. Тут упор не на идею, а на реальные знания технологий.

Подошла бы команда в составе: Архитектор, Back (Java), BigData, Специалист по нагрузочному тестированию, Аналитик.

Все скриншоты с кейсами взяты с сайта конкурса «Цифровой прорыв»
Цели участия в хакатоне
Мы участвуем в первый раз, а в соперниках будут команды, которые профессионально занимаются участием в хакатонах, поэтому наши цели такие:
  • подготовить шаблоны для других хакатонов;
  • выдать готовое решение;
  • попасть в десятку сильнейших команд по выбранному кейсу.

Также участие в хакатоне — это возможность проверить себя и узнать, что сейчас востребовано в современном IT. Оказалось, что без Machine Learning почти никуда в хакатонах, количество кейсов которые команда может сделать без ML — одна треть из доступных.

Самое непростое в подготовке — это не перегореть, не потерять мотивацию, а придерживаться плана подготовки и идти небольшими шагами. А в самом хакатоне будет ясно уже после участия, на данный момент выглядит сложно за 48 часов создать что-то полезное и рабочее. Но очень хочется попробовать.
Выводы по подготовке для тех, кто раздумывает участвовать в хакатонах
  • анализируйте решения других команд, опираясь на критерии оценки решений технологических кейсов;

  • грамотно выбирайте кейсы учитывая возможности и компетенции команды. У нас нет дизайнера, значит, мы будем выбирать кейс, где UX/UI не является критически важным;

  • делайте заранее шаблоны кода и инфраструктуру, которые могут пригодиться;

  • учите Machine Learning. Незнание ML сокращает количество кейсов которые можно выбрать на хакатоне.
Специалист по внутренним коммуникациям
Кристина Колесникова