Poznatky z košického hackathonu

Hackathon je slovo, které vzniklo spojením slov Hack a Marathon. Čtyřiadvacetihodinový maraton začínající představením nápadů, nalezením členů týmu a pak už jen makání, makání a makání. Událost, která musí skončit něčím skutečně funkčním, co lze nejen předvést, ale co má smysl pro cílovou skupinu a potenciál dalšího rozvoje. Právě takový hackathon se konal uplynulý víkend v Košicích.

Skvělá akce, plná super nápadů, energie a klasického pocitu z dobré eventy. Více než stovka účastníků, kteří obětovali svůj víkend, to prostě musí vygenerovat nějaký produkt.

Kromě konzultací o přípravě produktu jsem měl čas zamyslet se i nad nápady, jak kvalitativně posunout úroveň týmů v příštím ročníku.

Nejvíce mi asi zarezonovala podobnost chyb hackathon týmů s chybami profesionálních IT týmů v komerčním světě.

Prodat myšlenku

Již začátek hackathonu odhalil paralely s praxí. Někteří stihli odprezentovat myšlenku produktu za 20 vteřin. Našli se i tací, kteří to nestihli. A právě ti, kteří to stihli rychleji, více zaujali publikum.

Protože byli připraveni, struční, věcní a především začali s problémem lidí, který chtějí odstranit. Ti další prezentovali vlastnosti, a právě proto nestíhali. V čem je paralela s praxí?

Ti rychlejší byli lídři, kteří nastavili produkt správným směrem a namotali si takhle i tým. Bylo jim jasné, co jdou řešit. Chtěli uživatelům pomoci. Tušili, že bude takto jednodušší zasáhnout potenciální klienty.

Kolik IT dodavatelů vysvětluje super vlastnosti, ale na to, proč je vlastně potřebujete, musíte přijít sami? Kolik z nás máme v prezentacích okna, high tech pojmy v češtino-angličtino-ajťáčině? Takže pokud prezentujete nápad, začněte problémy. Nápad je nálepkou na bolesti klienta. Klient nepotřebuje nálepku, nechce bolest.

Angažovaný tým

Lidé si projekty v práci moc nevybírají. Ty přistanou mezi úkoly na oddělení, a tak se maká na tom, co se musí. Potom se divíme, že lidé chodí do práce, především proto, že musí. Na hackatonu to byl jejich produkt, něco, co si vybrali. Stačí, aby výsledek byl jejich hrdostí a ne ostudou.

Možná i vás dělí od angažovanosti lidí jen otevření interního trhu práce. Možná s přístupem podobným InHiro, kde jako zaměstnavatel musíte být tak atraktivní, aby si lidé vybrali zrovna vás, ne naopak vy své lidi.

Kolik lidí vám v práci prodalo myšlenku produktu, namotalo vás tak, že za nimi jdete a dáváte do produktu duši? Měli byste mít šanci ten pocit zažít. I proto byste měli zajít na takový hackathon, start-up awards nebo udělat si ve firmě interní innovation day.

Otcomatka produktu

Týmy, které na hackathonu měly lídra, makaly naplno. Ty, které ho neměly, více kecely a hledaly cestu. Čím blíže byly ke konci hackathonu, tím bylo jasnější, že směřování je důležitější než další dvě ruce pro kódování. Orchestr potřebuje dirigenta. Kapela bubeníka.

I v praktickém životě týmy potřebují lídra, otcomatku produktu, za kterým tým půjde. Toto firmám věru chybí. Najít toho, kdo je ochoten se postavit za výsledek, je dost obtížné. A tak mnohdy se raději oháníme tabulkami, risk radary, semafory a tvrdíme že to není naše vina, ale jiná objektivní příčina na stole jiného.

Sekera důležitější než myšlenka

Někteří se vrhli během první hodiny na nástroje. Trello, git apod. Trápili se, zatímco konkurenti vymýšleli produkt. Další část nevymýšlela, ale designovala user interface. To je jednodušší, že? Nakreslit rychle prototypy, užít si zábavu vymýšlením. Tady tlačítko, tam comboboxík, tu fullscreen mapička, ikonečka 256×256, fontíček. Koho by to nebavilo. Fajn, ale too early.

• Co z toho, že mám okno a nevím, jaký problém jím řeším?
• Co z toho, když nevím, čí je to problém, jak takový uživatel vypadá a jak se chová v dané situaci?
• Co z toho, když si to neověříme u potenciálních klientů?

Možná by bylo rozumnější začít popsáním uživatelů, jejich pains, gains a jobs. Na to hledat vlastnosti. Teprve potom začít navrhovat user experience. Neboť je zbytečné, když má aplikace najít nejbližší zastávku MHD a vy nabídnete super mapu, kterou starší člověk nepřečte a ani se v ní nezorientuje. Existuje mnoho řešení, problém ale zůstává stejný. I proto nejprve problém.

V reálném světě se vrhneme na architekturu, analýzu, design, nástroje, dokmenty a…. Skutek utek.

Taktická příprava

Týmy si k mému překvapení začaly připravovat i plánovat úkoly. Horší už to však bylo s jejich zněním. Databázové schéma. Hmmm, co má z toho ten důchodce?

Tak to uvidíte i v reálné IT praxi. Páni a dámy, plánujte vlastnosti, nikoli technologické vrstvy. Plánujte tok hodnoty end to end, nejen přes váš systém. Jinak po uplynutí času máte fajn databázi, ale dědeček je i nadále na ulici ztracený.

Tým není jen kopa lidí

Na hackathonu jste našli týmy, které se dokázaly rozdělit a fungovat v miniskupinkách, pracovaly paralelně. A byly i týmy, kde diskutovali ve stejné době všichni. Jako na mítincích ve firmách. Jeden prezentuje, ostatní se sice dívají, ale nevytvářejí hodnotu.

„Rozděl a panuj“ platí i v 21. století. Raději udělejte agilní minitýmy 2–4 lidí, rozdělte si vlastnosti a dokončujte je paralelně.

Chtějte feedback

Na hackathonu jsme byli výborná sestava konzultantů. Lidé z praxe se zkušenostmi od vymýšlení produktů, přes jejich programování až po prezentační dovednosti.

Především na začátku využívaly týmy této jedinečné šance na rozhovor a ověření si hotové části tak trochu ostýchavě. Stejně jako v praxi se obáváme zeptat klientů.

And, who is guilty?

Na závěr bych chtěl poděkovat výjimečnému týmu kolem Karola Kocúra ze společnosti T-Systems za jejich pozvání, skvělou organizaci eventu a možnost nasát kreativní energii, kvůli které se vyplatilo projet autem 1500 km přes dvě země.

Dohackování za rok.