Czy warto wziąć udział w hackathonie i jak go wygrać?

Brałaś/brałeś kiedyś udział w hackathonie? Może zastanawiasz się czy warto? Ważny jest sam udział, czy warto wygrać? I jak to zrobić? Hackathony kilka lat temu cieszyły się dużą popularnością. Tematyczne, zadaniowe, jednodniowe, wielodniowe, częściej stacjonarne, czasami online......

W czasie pandemii moda na hackathony trochę wyhamowała, moim zdaniem dlatego, że odpadła forma stacjonarna, która jest najciekawsza. Na szczęście wracają, i bardzo dobrze, ponieważ dla uczestników to świetna forma spotkania i sprawdzenia swoich umiejętności a dla organizatorów możliwość dotarcia do niezwykle utalentowanych osób, które mają dodatkowo bardzo cenną cechę; chce im się.

Nigdy nie brałem udziału w hackathonie jako uczestnik. W czasie, kiedy byłem programistą, hackathonów po prostu nie organizowano. Mam jednak za sobą kilka hackathonów w roli jurora lub mentora. Dwa razy współorganizowałem hackathony o tematyce bankowej.

Nie wiem, jak wygrać hackathon, ale mam kilka spostrzeżeń, które mogą zwiększyć prawdopodobieństwo wygranej. Przy czym skupię się na hackathonach, w których nie ma postawionych konkretnych zadań do rozwiązania, natomiast określony jest pewien zakres tematyczny.

Aby dobrze bawić się w czasie hackathonu i przy okazji zwiększyć prawdopodobieństwo wygranej potrzebne są trzy rzeczy:
1️⃣ Zespół
2️⃣ Pomysł
3️⃣ Historia

1️⃣ Zespół
Zwykle w hackathonach uczestniczą zespoły, które dobrze się znają. Zdarzały się przypadki, w których single byli łączeni w zespoły w czasie wydarzenia. Ba, byłem świadkiem, gdy raz taki ad hoc’owy zespół wygrał, ale to raczej wyjątek potwierdzający regułę. Lepszym pomysłem jest zabranie drużyny pierścienia wcześniej. Znacie się, wiecie kto co potrafi i czym może się zająć. Nie będziecie tracić czasu na docieranie. A początek wydarzenia jest bardzo ważny. Głowa świeża, pełna pomysłów. Warto wtedy skupić się na planie co i jak chcemy zrobić.

Kogo warto mieć w zespole, oprócz samych programistów? Jeżeli jest to hackathon, na którym powstanie jakaś forma interfejsu użytkownika, to warto mieć w zespole kogoś od UX i/lub grafiki. Takie umiejętności przydadzą się bardzo w projektowaniu użyteczności jak i w czasie przygotowania finałowej prezentacji. Oczywiście, programista może zaprojektować interfejs, ale umówmy się, ilu takich programistów znacie? Ja w swoim zawodowym życiu pracowałem z blisko 300 programistami i takich, którzy mieli jako takie pojęcie o UX, poznałem dwoje. Statystycznie programiści nie znają się na projektowaniu interfejsu użytkownika, chociaż się do tego nie przyznają 😊.

Bardzo ważna jest także umiejętność prezentacji rozwiązania, czyli opowiedzenia, dlaczego, co i jak udało się jakieś zadanie rozwiązać. Jeżeli macie w zespole kogoś, kto pociągnie prezentacje to świetnie. Jeżeli nie, warto kogoś dokooptować, aby nie spalić dobrego rozwiązania przez złą jego prezentacje.

2️⃣ Pomysł
Możliwości są dwie. Pierwsza to organizatorzy określają zakres tematyczny na tyle dokładnie, że pomysł można opracować wcześniej (ja tak robiłem przy okazji organizowanych przez siebie hackathonów). Druga, organizatorzy podają tematykę z zaskoczenia i oczekują, że pomysł wykluje się w czasie wydarzenia. Bez względu, która opcja będzie zastosowana, podejście jest podobne. Warto wyjść od trzech pytań: dlaczego? co? jak?

Dlaczego?
Jaki problem chcemy rozwiązać? Kto na tym rozwiązaniu skorzysta? Czyj ból zmniejszymy lub zniwelujemy? Jakie będzie nasze story?

Co?
W rzeczywistości zrobimy? W jaki sposób wyglądałoby rozwiązanie docelowe? Jakie MVP wybierzemy do realizacji na hackathonie, aby się wyrobić? Jakie będzie „user story”?

Jak?
Podział pracy na zadania i rozdzielenie tych zadań na zespół.  

Warto chwilę poświęcić na przedyskutowanie pomysłu i wstępne zaplanowanie. Nie za dużo, nie za mało. Zawsze można i trzeba korygować pomysł w trakcie i go dostosowywać. Skupcie się na jednej głównej funkcjonalności, nawet jeżeli rozwiązanie może być dużo większe. O tym zawsze można powiedzieć, ale dobrze pokazać działającą funkcjonalność. Lepiej jedną zrobić dobrze, niż kilka do połowy.

3️⃣ Historia
Nigdy nie zapomnę, jak na jednym z hackathon’ów, zespół trzech 17-sto latków zaprezentował swoje rozwiązanie do płatności bluetooth. Płatność ładowała system pre-paid, który aktywował zasilanie tostera. Było dużo kabli, trochę dymu i owacja na stojąco, gdy z tostera wyskoczył tost.

Pamiętaj, że nawet najlepsze rozwiązanie można spalić przez złą prezentację. Zadbaj o to, aby mieć w zespole osobę, która ciekawie opowie o rozwiązaniu. Skupcie się na historii, odpowiedzcie sobie na pytanie jaka jest Wasza wielka idea? Co chcecie, aby odbiorcy zapamiętali z Waszej prezentacji?

Czy robić slajdy? Mogą się przydać, pod warunkiem, że nie zostaną zapełnione tekstem a Wy będziecie to czytać. To nie karaoke. Na slajdach można pokazać jaki jest pomysł docelowy (historia) i czym jest MVP, które za chwilę pokażecie. Niech slajdy będą tłem Waszej historii, najlepiej z odrobiną humoru.
Pamiętajcie, aby zrobić próbę i sprawdzić, czy mieścicie się w czasie.

Ps. Projekt hackathonowy niewiele różni się od sprintu w Agile. Oczywiście jest ekstremalnie krótki, ale podobnie jak w typowym sprincie, zespół powinien być kompletny, wspólnie uzgodnić plan pracy i ocenić pracochłonność, robić szybkie stand-up’y i retro. A na koniec zrobić demo funkcjonalności, która działa. Jeżeli dobrze czujesz się biorąc udział w hackathonach, bez problemu odnajdziesz się w zespole Agile realizującym większy projekt.

Photo: unsplash.com / Joshua Golde
unsplash.com / Tim Gouw