Junction 2017 – Euroopan suurin ”Hackathon”-tapahtuma

Junction 2017 – Euroopan suurin ”Hackathon”-tapahtuma

Osallistuimme 24.-26.11.2017 ensimmäistä kertaa hackathoniin, ennen kaikkea oppiaksemme hackathoneista sekä jakaaksemme nyt sitä kokemusta esim. tämän blogi-kirjoituksen muodossa.

Mikä Hack?

Käydäänpä ensin hiukan termejä läpi, joita kyseisessä tapahtumassa viljeltiin.

Mikä on ”hackathon”? Hackathon on tapahtuma jossa osallistujat ovat ”hakkereita”, jotka ratkaisevat yhtä tai useampaa haastetta yksin tai yhdessä. Haasteen tarjoaja voi olla yritys, yhteisö, kunta tai vaikka valtio, miksei yksityishenkilökin. Hackathonin lopuksi valitaan kunkin haasteen voittaja, ratkaisun perusteella.

Mikä se ”hakkeri” on, joku rikollinen vai? Voi olla… Aloitetaan laveammalla määrityksellä. Hackathonin lisäksi ”Hakkeri” tai hakkeri on ehdottomasti tämän hetken trendi-sana. Hakkeriin liitettyjä muita kuvaavampia nimiä ovat mm.:

  • ”Valkohattu-hakkeri”,
  • ”Mustahattu-hakkeri”,
  • ”Harmaahattu-hakkeri”,
  • ”haktivisti”,
  • ”bio-hakkeri”,
  • ”life hacker”,
  • ”graphic designer”,
  • ”developer”,
  • ”UX-designer” ja
  • ”Hardware hacker”.

Näistä neljää viimeistä tarkoitettiin ”hakkerilla” Junction 2017:ssa, pääsääntöisesti. Niitä voikin muuhun listaan verraten leikkisästi kutsua myös ’mallikelpoisiksi’ tai vaikka värittömiksi hakkereiksi.

Itseäni kiinnostaa hakkeri-kulttuuri, kaikkien yllä mainittujen hakkerityyppien osalta, ja erityisesti tietoturvaan liittyvä ’hattu’-hakkerointi. Sen verran tässä voidaan avata tuosta oudosta ’hattu’-sanasta että De Bono:n ”kuutta ajattelu hattua” tällä ei tarkoiteta. Tietoturvasta puhuttaessa on kuitenkin hyvä ajatella de Bonon kaltaisesti. Kuten monet muutkin tietoturva-osaajat tietävät että tekniikka on vähemmän tärkeä kuin *tapa ajatella* tietoturvasta. Lyhyesti, ’hattu’ ei määrittele henkilöä. Tällä kertaa, tässä kirjoituksessa, ei sukelleta ”hacker”-kulttuuriin tai tietoturva-asioihin tämän syvemmin.

Junction 2017

Junction on varmasti Euroopan suurin hackathon. Espoon Otaniemessä Dipolissa tapahtumaan osallistui n. 1500 hakkeria. Tapahtuman jälkeen @koodiklinikka#general:ssa yhden kommentin mukaan hakijoita olisi ollut jopa 4000.

Osallistujien lisäksi oli mukana haasteen tarjoajia, sponsoreita, mentoreta eri yhteisöistä ja yrityksistä esim. Aalto Yliopisto, Castren & Snellman- lakitoimisto, Helsingin Kaupunki, Elisa, ESA, Finnair, Nordea, Outotec, Planmeca, Spotify ja Veikkaus sekä muita. Paikalla kävijöiden joukossa näkyi lisäksi mm. NASA:n edustaja ja Peter Vesterbacka.

Tapahtuma oli hyvin järjestetty, ja mikä vakuuttavinta osallistujat olivat todella motivoituneen oloisia. Ilmeisesti korkeakoulu-opiskelijoilla, joita pääsääntöisesti osallistuja olivat, oli halu näyttää taitonsa. Nuorin osallistuja taisi olla 16-vuotias.

BUILD & MEASURE

Junctionissa kilpailuun osallistuminen edellytti MLH (Major League Hacking)-sääntöjen mukaan että koulu on kesken tai valmistumisesta on kulunut korkeintaan 12 kuukautta. Janin osalta Ylemmän AMK-tutkinnon osalta se oli selkeää. Omalta osaltani se tarkoitti coursera:n ja udemyn ohjelmointi”-koulutuksia”. Palaute-kyselyssä itsellä nykyinen koulu valinta osui kohtaan ”Code School”.

Me tapahtumaan osallistuneet Hubblelaiset – Jani ja minä – totesimme että emme osallistu kilpailuun vaan verkostoidumme ja seuraamme tapahtumaa sekä koodailemme, mikäli löytyy meille mielestämme sopiva haaste. Kuten hakemukseen asian kerroimme. Osallistumis-hakemuksen tekeminen tapahtumaan oli muuten avoin kaikille. Tapahtuma lyhyesti sanottuna on profiloitunut muiden MLH-tapahtumien tapaan opiskelijoille, näytön paikkana.

Junction tarjosi haasteiden lisäksi myös muuta ohjelmaa kuten Mindfullness-harjoituksen, perehtymisen ESA satelliitti-dataan sekä Spotifyn julkaisemattomaan Web Developer API tutorialin. Koodasimme myös tovin, Legaltech-haasteeseen osin liittyen, GDPR:ään liittyvää aputyökalua itsellemme. Keskustelimme tämän aputyökalun käytöstä ja mahdollisesta kiinnostuksesta myös Castren & Snellmanin juristien kanssa, saimmekin heiltä hyviä näkökulmia.

LEARN

Tapahtumasta jäi päällimäisenä mieleen, nivoutuen toisiinsa:

  • motivoituneet opiskelijat
  • palkintoina, rahallisen palkinnon lisäksi, oli mm. mahdollisuus tavata haaste-yrityksen päättäjiä
  • valtava potentia yrityksille jotka haluavat panostaa (saattaa edellyttää hieman enemmän kuin läsnäoloa)
    • uusiin ideoihin
    • uusiin tekijöihin
    • valmiisiin ratkaisuihin (osa ratkaisusta oli erittäin ”valmiin” oloisia)
    • testata DX:ää (Developer eXperience) uusien ’julkaisemattomien’ APIensa osalta (esim. Spotify) ja saada palautetta
  • tapahtuma on enemmän ”hands-on”-tyyppinen ja vähäisesti ”verkostoitumis”-tyyppinen tapahtuma
  • after-party sunnuntai-iltana 🙂 (alkoholia ei ollut tarjolla muuten, tämä on selvästi harkittu juttu)
  • Lopuksi ajatus hackathoneista: ”osallistujien määrä lisää laatua”
    • tämä ehkä kuulostaa absurdilta, kuitenkin tapahtuman nähneenä uskon tähän. Vinkkinä siis hackathonien järjestäjille jotka miettivät pitäisikö liittyä jonkin toisen hackathonin kanssa yhteen, vastaus: kyllä

 

Linkit

Lisää tietoa, kuten videoita tapahtumasta, löytyy youtube kanavalta sekä nettisivuilta:

Ideat, kokeilu ja validoitu oppiminen

Ideat, kokeilu ja validoitu oppiminen

Senkus räpläätte

Valtakunnallisen kokeiluviikon innoittamana päätin kirjoittaa hiukan kokeiluista ja validoidusta oppimisesta. Kokeilukulttuuria syydetään lähes joka tuutista, enemmän tai vähemmän edellytyksenä menestykselle. No sitähän me Hubblessakin toitotetaan. Mielestäni usein kuitenkin unohdetaan validoitu oppiminen, ja sitä pitäisi korostaa enemmän kuin vain kokeiluja. Validoidun oppimisen pitäisi olla yksi tärkeä peruste kokeilujen tekemiselle. Kun puhutaan vain kokeilemisesta, tulee helposti mieleen hallitsematon räpläily minkä tahansa asian ympärillä. Toisaalta kokeiluihin mahdollistava johdon kommentti ”senkus räpläätte” voi olla se ainoa tarvittu palanen suurten innovaatioiden syntymiseen. Historia sen kertoo, että paljonhan niitä vahingossa on syntynytkin.

Pyrstö edellä puuhuun

Yksi kokeiluajatusten lähde ja itseänikin asian tiimoilta innoittanut kirja on Eric Riesin Lean startup. Ericin kuvaama malli on sangen yksinkertainen ja siksi pidän siitä. Sitä on helppo soveltaa lähes mihin tahansa toimialaan, kunhan ajattelee luovasti eikä asettele itse keinotekoisia rajoituksia. Build – Measure – Learn mallia käytetään paljon ja joskus haastan itseänikin ajattelemaan tuota mallia takaperoisesti. Eli pyritään ensin miettimään mitä halutaan oppia, miten se oppiminen saadaan validoitua ja sen jälkeen tehdään MVW (Minimum Viable Whatever).

Naama edellä

Normaali tapa on edetä toteuttamalla iteraatio rakentamalla ensin MVW, mittaamalla onnistumista ja keräämällä opit. Vaikka asiaa ajattelisi näin, haastan silti miettimään asiaa myös takaperoisesti. Kun päästään kiinni ajatukseen mitä halutaan oppia, on huomattavasti helpompi löytää sopivia ”määreitä” onnistumisen mittaamiseen.

Ja ensin se idea

Lean startup mallia voi käyttää, kun ensin on se idea. Digitaalisen tilannekuvan työpajoissa olen havainnut, että kyllä niitä ideoita löytyy, kunhan on hyviä tapoja saada niitä esiin. Erilaiset Game storming mallit ovat hyviä. Peleissä päästään eroon erilaisista ideointia haittaavista ongelmista, kuten esimerkiksi itsekritiikistä, desibeli ideoinnista (kovaäänisimmän idea on paras) tai HIPPO priorisoinnista (highest paid person’s opinion). Idean perusteella muodostetaan hypoteesi, jota lähdetään validoimaan kokeilumallilla.

Byrokratiaa peliin, not

Koska kokeiluissa halutaan olla nopeita ja ketteriä voi dokumentointi ja kokeilumalli jäädä pohtimatta. Kun palataan validoituun oppimiseen, on hyvä päästä asiaan uudestaan kiinni myöhemminkin. Ajatellen esimerkiksi tilannetta, jossa uusi työntekijä tulee taloon ja yrityksessä on hiljalleen saatu kokeilukulttuuria edistettyä. Kevyt dokumentaatio tehdyistä kokeiluista, validointitavoista ja oppimisesta on erittäin arvokasta tietoa uudelle kaverille. Pääsee heti kiinni ajatukseen, kuinka omia ideoita voisi kokeilla. Tai kun ajan saatossa jokin aikaisemmin kokeiltu hypoteesi nousee uudestaan pintaa, voidaan asiaa ensin lähestyä ajatuksella ”kuinka maailma hypoteesin ympärillä on muuttunut”. Kevyellä ja avoimella dokumentaatiolla on paikkansa. Ei hommaa tietenkään tule kuormittaa liian byrokraattisella rakenteella, mutta jokin kevyt toistuva tapa kokeilujen käsittelyyn tulisi olla. Tuo tapa tietysti kehittyy jatkuvasti. Liika byrokratia tunnetusti hoitaa koko homman niin, ettei validoitavia ideoita ja hypoteeseja ole eikä tule.

Fail fast, fail cheap

Kannustan teemaviikon mukaisesti kokeilemaan. Mielenkiintoa saa lisää, kun miettii miten asian saa kokeilemalla validoitua nopeasti ja halvalla.

Jani