В Olen etsinyt useita syitä osallistua hackathoneihin. Motivaatio oppia paljon uutta ja voittaa arvokkaita palkintoja houkuttelee monia, mutta usein järjestäjien tai sponsoriyritysten virheiden vuoksi tapahtuma päättyy epäonnistuneesti ja osallistujat lähtevät tyytymättöminä. Jotta tällaisia epämiellyttäviä tapauksia sattuisi harvemmin, kirjoitin tämän viestin. Trilogian toinen osa on omistettu järjestäjien virheille.
Postaus on järjestetty seuraavasti: aluksi puhun tapahtumasta, kerron mikä meni pieleen ja mihin se johti (tai voi johtaa pitkällä tähtäimellä). Sitten annan arvion siitä, mitä tapahtuu, ja mitä tekisin, jos olisin järjestäjä. Koska osallistuin kaikkiin tapahtumiin, voin vain olettaa järjestäjien todellista motivaatiota. Tämän seurauksena arvioni voi olla yksipuolinen. En sulje pois sitä mahdollisuutta, että jotkin minusta virheellisiltä vaikuttavat kohdat on todella tarkoitettu sellaiseksi.
Jossain vaiheessa lukija saattaa ajatella, että kirjoittaja päätti heiluttaa nyrkkejään tappelun jälkeen. Mutta voin vakuuttaa teille, että näin ei ole. Joissakin listatuissa hackathoneissa onnistuin nappaamaan palkinnon, mikä ei kuitenkaan estä sanomasta, että tapahtuma oli huonosti järjestetty.
Kunnioituksesta järjestäjiä ja osallistujia kohtaan, postauksessa ei viitata tiettyihin yrityksiin. Huomaavainen lukija voi kuitenkin arvata (tai Google), kenestä puhumme.
Hackathon nro 1. Tiukat puitteet
Kuusi kuukautta sitten yksi suuri teleyritys järjesti hackathonin data-analyysistä. Palkintorahastosta kilpaili 20 joukkuetta. Tilaisuudessa annettiin analysoitavaksi tietojoukko, joka sisälsi tietoa yrityksen tukipalvelun puheluista, aktiivisuudesta sosiaalisissa verkostoissa sekä koodattuja tietoja käyttäjistä (sukupuoli, ikä jne.). Mielenkiintoisin osa aineistosta – käyttäjien viestit ja operaattorin vastaukset (tekstidata) – oli melko meluisa ja se piti puhdistaa jatkotyötä varten.
Järjestäjät asettivat tehtävän - tehdä jotain mielenkiintoista annetuilla tiedoilla, ja oli kiellettyä käyttää ylimääräisiä avoimia tietojoukkoja verkosta tai jäsentää tietoja itse. Myös aineistoon kuulumattomien ideoiden ehdottaminen oli kiellettyä. Valitettavasti toimitetut tiedot olivat melko "huonoja": mielenkiintoisia tuotteita oli vaikea saada heiltä, ja mentoreiden kanssa kommunikoinnista kävi selväksi, että monet ehdotetuista ideoista ovat jo toteutuksessa (tai tullaan toteuttamaan lähitulevaisuudessa) seurassa.
Tämän seurauksena ylivoimainen määrä joukkueita (15/20) teki chatbotteja. Esitysten aikana yhden joukkueen päätös poikkesi vähän edellisestä. Yksi tuomariston jäsenistä ei kestänyt sitä, ja kysyi seuraavalta lavalle nousevalta tiimiltä: "Mitä, kaverit, onko teillä myös chatbot?" Tämän seurauksena kolmesta palkinnosta ykkös- ja kakkossijat menivät joukkueille, jotka eivät tehneet chatbotteja.
Otetaan vertailuksi hackathon, jonka kansainvälinen konsulttiyritys järjesti Zvezdochka-yritykselle kaksi vuotta sitten. Koska Zvezdochka-yrityksen toiminnan erityispiirteet olivat monelle hackathonin osallistujalle tuntemattomia, tapahtuman alussa järjestäjät puhuivat yrityksessä käytössä olevista mittareista. Tämän jälkeen toimitettiin kuusi erityyppistä tietojoukkoa: tekstiä, taulukoita, maantieteellistä sijaintia – liikkumavaraa oli kaikille osallistujille. Järjestäjät eivät kieltäneet lisätietoaineistojen käyttöä ja jopa tukivat tällaisia aloitteita. Kilpailun finaalissa pääpalkinnosta kilpaili kymmenen joukkuetta erilaisilla ratkaisuilla, ja kaikki joukkueet käyttivät yrityksen toimittamia tietoja (rajoitusten puutteesta huolimatta), mikä osoitti hyvät mahdollisuudet saada laadukkaita tuotteita.
moraali
Osallistujien luovaa virtaa ei tarvitse rajoittaa. Järjestäjänä sinun tulee tarjota materiaaleja ja luottaa heidän visioonsa ja ammattitaitoonsa. Jos osallistut hackathoniin, kaikkien rajoitusten tai kieltojen pitäisi hälyttää.Yleensä tämä on todiste huonosta organisoinnista (esimerkki tosielämästä on jatkuva halu laittaa aita jonnekin). Jos kohtaat rajoituksia, varaudu siihen, että joudut luomaan projektin poolissa, jossa on paljon kilpailua. Tässä tapauksessa sinun on otettava riskejä: tehdä jotain täysin uutta tai tarjota epätavallinen "tappajaominaisuus" erottuaksesi yksitoikkoisten projektien virrasta.
Hackathon nro 2. Mahdottomat tehtävät
Hackathon Amadorissa lupasi olla mielenkiintoinen. Sponsoroiva yritys, suuri puhelinvalmistaja, aloitti valmistelut 4 kuukautta ennen tapahtumaa. Tapahtuman PR toteutettiin sosiaalisissa verkostoissa, mahdollisten osallistujien piti läpäistä tekninen testi ja kirjoittaa menneistä projekteistaan tullakseen valituksi tähän tapahtumaan. Palkintorahasto oli miellyttävän suuri. Muutama päivä ennen hackatonia mentorit pitivät teknisen istunnon, jotta osallistujilla oli aikaa ymmärtää alan erityispiirteet.
Itse tapahtumassa järjestäjät toimittivat tietojoukon laitelokeista, joiden tilavuus oli 8 Gt, tehtävänä oli vikojen binääriluokitus. He puhuivat projektien arviointikriteereistä - luokittelun laadusta, luovuudesta ominaisuuksien luomisessa, kyvystä työskennellä ryhmässä jne. Se on vain huonoa tuuria - 8 Gt:n "ominaisuuksia" varten junassa oli vain 20 esimerkkiä ja testissä 5. Viimeinen naula hackathonin arkkuun tuli tiedoista: keskiviikkona saapuneet laitelokit sisälsivät virheen laitteiden toiminnassa, mutta torstaina luoduissa ei (muuten tästä tiesi vain kaksi joukkuetta, ja molemmat olivat Venäjältä, kokeneiden datalouhosten kotimaasta). Vaikka edes testin todellisten merkintöjen tietäminen ei auttanut vastausta määrittämään, tehtävä oli ratkaisematon. Järjestäjät eivät saaneet toivottua tulosta, osallistujat käyttivät paljon aikaa huonosti suunnitellun ongelman ratkaisemiseen. Hackathon oli epäonnistuminen.
moraali
Suorita toimeksiantojen teknisiä katsauksia ja tarkista toimeksiantojen riittävyys. On parempi maksaa liikaa alustavasta tutkimuksesta (tässä tapauksessa jokainen datatieteilijä huomauttaa välittömästi, että tätä ongelmaa on mahdotonta ratkaista) kuin katua sitä myöhemmin.
Tässä tapauksessa hukkaan ajan ja rahan lisäksi yritys menetti uskottavuutensa mahdollisten ehdokkaiden keskuudessa ja mahdollisesti kirjoitti tuloksista. Muuten, ei vain osallistujien, vaan myös yrityksen tulisi kirjoittaa onnistuneista tuloksista maksimoimalla hackathonin PR-näkökulmasta. Valitettavasti kaikki yritykset eivät tee tätä, vaan rajoittuvat vain ilmoitusviestiin ja pariin valokuvaan tapahtumasta Twitterissä.
Hackathon nro 3. Ota tai jätä
Viimeksi tiimimme osallistui hackathoniin Amsterdamissa. Koska olen koulutukseltani sähköinsinööri (uusiutuvien energialähteiden alalla), aihe oli juuri meille sopiva - energia. Hackathon pidettiin verkossa: meille annettiin kuvaus tehtävästä ja kuukausi aikaa sen suorittamiseen. Järjestäjät halusivat nähdä valmiin projektin, joka auttaisi lisäämään Amsterdamin talojen energiatehokkuutta.
Teimme projektin, jossa ennakoitiin sähkön kulutus ) ja tuotanto aurinkopaneelien avulla. Näiden ennusteiden perusteella akun suorituskykyä optimoidaan (tämä idea on osittain otettu diplomityöstäni). Projektimme oli hyvin sopusoinnussa sekä järjestäjien ohjeiden kanssa (kuten meistä silloin näytti) että Amsterdamin hallinnon uusiutuvien energialähteiden politiikan kanssa useiden vuosien ajan.
Projektien arvioinnissa meille, kuten monille joukkueille, kerrottiin, että tämä ei ollut sitä, mitä asiakas odotti, ja lisättiin, että meidän on tehtävä projekti uudelleen, jos halusimme kilpailla palkinnosta. Emme tehneet mitään uudelleen hyväksyen tappion. Neljästäkymmenestä osallistuvasta joukkueesta emme päässeet edes 7 parhaan joukkoon, vaikka järjestäjien valinta oli mielestäni melko outo. He pääsivät finaaliin esimerkiksi tiimin, joka teki sovelluksen tuulen nopeuden ja auringonsäteilyn (SI) laskemiseen älypuhelimen antureiden datan perusteella: mikrofoni tuulelle, valoanturi SI:lle. Tappava ominaisuus oli hotdog/not hotdog -luokitus kolmeen luokkaan: aurinko, tuuli, vesi ja vastaavan artikkelin näyttäminen Wikipediassa ().
Jätetäänpä hetkeksi asian moraalinen puoli: osallistujien kiristäminen voiton mahdollisuudella on yksinkertaisesti epäeettistä. Koska yksi hackathoneihin osallistumisen motiiveista (etenkin kokeneiden kehittäjien) on ideoidensa toteuttaminen, monet vahvat osallistujat voivat yksinkertaisesti poistua tapahtumasta kuultuaan tällaisen palautteen (jota ei tapahtunut vain tiimillemme, vaan myös useille muille keskeyttäneille päivittää sivuprojektinsa mentoria kuunneltuaan). Oletetaan kuitenkin, että suostuimme järjestäjien toiveisiin ja teimme projektimme uudelleen heidän tarpeitaan vastaavaksi. Mitä voisi tapahtua seuraavaksi?
Koska järjestäjillä on oma käsityksensä "ihanteellisesta projektista", kaikki toiveet (ja vastaavasti muutokset) johtavat meidät kohti tätä ihannetta. Kilpailijat tuhlaavat aikaansa ja heidän on yhä vaikeampaa kieltäytyä osallistumisesta (koska he ovat jo panostaneet, ja näyttää siltä, että he ovat vain vähän päässä voitosta). Mutta todellisuudessa kilpailu palkinnoista lisääntyy, ja osallistujien on yhä useammin tehtävä uusi projekti järjestäjien muokkausten perusteella palkinnon toivossa. Tämän seurauksena kaverit, jotka eivät ottaneet palkintoja, ymmärtävät taaksepäin katsoessaan osallistuneensa freelancerina ilman rahaa: he tekivät muokkauksia asiakkaalle, mutta eivät saaneet tästä mitään vastineeksi (paitsi asiaankuuluvaa kokemusta, kurssi).
moraali
Usein hankkeen avuksi tulee järjestäjien toiveet ja palaute. Samalla osallistujien ei kuitenkaan tule luottaa mentoreiden neuvoihin kuin ontuva mies kepin päällä. Jos kuulet järjestäjiltä palautetta projektistasi "ota pois, me emme tilannut tätä" -hengessä, osallistumisesi hackathoniin voidaan katsoa suoritetuksi.
Jos järjestät hackathonin selkeällä visiolla projektista, mutta ilman taitoja tai kykyä toteuttaa se itse, on parempi muotoilla visiosi freelancerin teknisten eritelmien muodossa. Muuten joudut maksamaan kahdesti – hackathonista ja freelancerin palveluista.
Lähde: will.com