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

Но эта статья — о том, как хакатоны можно изменить и переосмыслить. Нужно, конечно, оставить всё веселье. Также, нужно добавить свободы участникам: когда хакатоны проводят компании, они обычно делают это со своими конкретными целями. И третье — нужно сделать их более длительными. Я предлагаю делать хакатоны длительностью где‑то в спринт (2 недели), но так, чтобы время активной работы было по‑прежнему около нескольких суток. Другими словами, нужен хакатон, доступный работающему и, возможно, семейному человеку. Возможно ли это? Нужно ваше мнение.

Мой собственный опыт участия в хакатонах — небольшой, но — был запоминающимся. Лет 10 назад я учился в магистратуре Академического университета им. Алфёрова, и у нас проводился трёхдневный хакатон Dev Days, где студенты могли выбрать любую тему и воплотить её в код. Мероприятие было насыщенным — выспаться, конечно, не удалось.

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

Вообще, если делать хакатоны для широкого круга айтишников, то круглосуточный кодинг на протяжении нескольких суток — так себе вариант. Во‑первых, выходные свободны не у всех. Во‑вторых, после тридцати хочется работать в менее напряжённом режиме. И в третьих, это не так эффективно: если между кодинг‑сессиями есть время, чтобы отдохнуть‑отвлечься — результат получается лучше.

Можно сделать хакатон более длительным — например, длиной в 2 недели. По объёму проекты можно оставить такими же — чтобы работы было на день или два. Может показаться, что в таком случае получится разброд и шатание: ведь обычно участвует несколько команд. Но это не так: хакатон — достаточно хаотичный в любом случае: есть даты начала и конца, а между ними может происходить всё что угодно. Команды должны синхронизироваться внутри себя, между разными же командами — почти нет точек соприкосновения. Ну, кроме того, что приятно узнать, что у других ещё ничего не готово (или что то, что они задумали — в принципе невозможно).

Attack - 100%, Damage - 0%

Главная вещь, которая делает хакатон уникальным жанром — это выбор темы проекта. Она должна быть интересной, амбициозной и — с полётом фантазии. И, также, должна привести за пару дней к результату, который можно продемонстрировать. Но какая‑то практическая польза от сделанного на хакатоне после его завершения — не нужна. Также, если ваш проект, в смысле практической реализации — под силу хорошей компании вроде Google — это не проблема, а только плюс.

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

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

Темы для хакатонов нужно придумывать заранее. Как и планировать сам хакатон. Всё‑таки, такие внерабочие события в рабочий график вписывать непросто. Но никто и не заставляет участвовать в хакатонах часто. А само мероприятие, тем не менее, может быть регулярным!

Программисты шутят

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

Как это может выглядеть

Как я говорил, я себе представляю хакатон размером примерно в 2 недели с определёнными датами начала и конца. В самом минималистичном варианте, перед началом хакатона, на вики редактируются идеи и набираются команды. Дальше происходит двухнедельная магия — хакатон. К концу спринта, участвующие команды записывают на вики, как у них ничего не получилось. Конечно, можно добавить в процесс больше жизни и хотя бы сделать в конце какую‑то презентацию‑демо с результатами, но это не обязательно. Как не обязателен и соревновательный элемент — определение и награждение победителей (я покупаю билеты не ради выигрыша!)

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

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

И — последняя (и важная) часть. Сотрудники всяких модных бигтехов — наверняка, идея провести хакатон время от времени возникает в вашей компании и даже, возможно, воплощается в жизнь. Как они у вас проходят? Какие были самые удачными? Что думаете о такой идее?