В Több okot is megvizsgáltam a hackathonokon való részvétel mellett. A sok újdonság elsajátítására és az értékes nyeremények megszerzésére irányuló motiváció sokakat vonz, de gyakran a szervezők vagy a támogató cégek hibái miatt a rendezvény sikertelenül végződik, a résztvevők pedig elégedetlenül távoznak. Azért írtam ezt a bejegyzést, hogy ritkábban történjenek ilyen kellemetlen események. A trilógia második részét a szervezők hibáinak szentelik.
A poszt a következőképpen épül fel: az elején beszélek az eseményről, elmagyarázom, hogy mi romlott el, és mihez vezetett (vagy hosszabb távon vezethet). Aztán értékelem, mi történik, és mit tennék, ha én lennék a szervezők. Mivel minden rendezvényen részt vettem, csak feltételezni tudom a szervezők valódi motivációját. Ebből következően az értékelésem egyoldalú lehet. Nem zárom ki, hogy egyes számomra hibásnak tűnő pontokat valóban így tervezték.
Egy bizonyos ponton az olvasó azt gondolhatja, hogy a szerző úgy döntött, hogy verekedés után ököllel hadonászik. De biztosíthatom önöket, hogy ez nem így van. A felsorolt hackathonok némelyikén sikerült díjat is átvinnem, ami azonban nem akadályozza meg, hogy azt mondjuk, hogy rosszul sikerült a rendezvény.
A szervezők és a résztvevők iránti tiszteletből a bejegyzésben nem lesz utalás konkrét cégekre. A figyelmes olvasó viszont kitalálja (vagy a Google), kiről van szó.
Hackathon No. 1. Szigorú keretek
Hat hónappal ezelőtt egy nagy távközlési cég hackathont szervezett az adatelemzésről. 20 csapat versengett a nyereményalapért. A rendezvényen elemzésre egy adatállományt bocsátottak rendelkezésre, amely információkat tartalmazott a cég támogatási szolgálatának hívásairól, a közösségi oldalakon végzett tevékenységről és a felhasználókról kódolt információkat (nem, életkor stb.). Az adatkészlet legérdekesebb része – a felhasználói üzenetek és a kezelői válaszok (szöveges adatok) – meglehetősen zajos volt, és a további munkához meg kellett tisztítani.
A szervezők azt a feladatot tűzték ki, hogy valami érdekeset csináljanak a megadott adatokkal, és tilos volt további nyílt adatkészleteket használni a hálózatról, illetve az adatokat saját kezűleg elemezni. Tilos volt az adatkészlethez nem kapcsolódó ötleteket is javasolni. Sajnos a közölt adatok meglehetősen „szegényesek” voltak: nehéz volt tőlük érdekes terméket szerezni, és a mentorokkal folytatott kommunikációból világossá vált, hogy a javasolt ötletek közül sok már megvalósul (vagy a közeljövőben fog megvalósulni) a cégben.
Ennek eredményeként a csapatok túlnyomó része (15-ból 20) készített chatbotot. Az előadások során az egyik csapat döntése alig különbözött az előzőtől. Az egyik zsűritag nem tudta elviselni, hogy megkérdezte a következő, színpadra lépő csapattól: „Mi van, srácok, nektek is van chatbototok?” Ennek eredményeként három nyeremény közül az első és a második helyezést azok a csapatok szerezték meg, akik nem készítettek chatbotot.
Összehasonlításképpen vegyünk egy hackathont, amelyet egy nemzetközi tanácsadó cég szervezett a Zvezdochka cég számára két évvel ezelőtt. Mivel a Zvezdochka cég tevékenységének sajátosságai sok hackathon résztvevő számára ismeretlenek voltak, a rendezvény elején a szervezők a cégnél alkalmazott mérőszámokról beszéltek. Ezt követően hat különböző típusú adatkészletet bocsátottak rendelkezésre: szöveg, táblázatok, földrajzi helymeghatározás – minden résztvevőnek volt mozgástere. A szervezők nem tiltották meg további adatkészletek használatát, sőt támogatták az ilyen kezdeményezéseket. A verseny döntőjében tíz csapat versengett különböző megoldásokkal a fődíjért, minden csapat a cég által megadott adatokat használta (a korlátozások hiánya ellenére), ami jó lehetőséget jelez a minőségi termékek megszerzésére.
Erkölcs
Nem szükséges korlátozni a résztvevők kreatív áramlását. Szervezőként Önnek kell biztosítania az anyagokat, és bíznia kell az elképzeléseikben és a professzionalizmusukban. Ha Ön egy hackathon résztvevője, minden korlátozás vagy tilalom riasztja Önt, ez általában a rossz szervezés bizonyítéka (egy példa a való életből az állandó vágy, hogy kerítést ragasszunk valahova). Ha korlátozásokkal találkozik, akkor készüljön fel arra, hogy egy projektet egy nagy versenytársban lévő medencében kell létrehoznia. Ebben az esetben köteles kockáztatni: tenni valami alapvetően újat, vagy felajánlani egy szokatlan „killer funkciót”, hogy kitűnjön a monoton projektek sodrából.
Hackathon No. 2. Lehetetlen feladatok
Érdekesnek ígérkezett az amadori hackathon. A támogató cég, egy nagy telefongyártó cég 4 hónappal az esemény időpontja előtt megkezdte az előkészületeket. Az esemény PR-ját közösségi hálózatokon végezték, a potenciális résztvevőknek technikai teszten kellett átmenniük, és meg kellett írniuk korábbi projektjeikről, hogy kiválaszthassák őket erre az eseményre. A nyereményalap kellemesen nagy volt. Néhány nappal a hackathon előtt a mentorok technikai foglalkozást tartottak, hogy a résztvevőknek legyen idejük megérteni az iparág sajátosságait.
Magán a rendezvényen a szervezők egy 8 GB-os eszköznapló-adatsort bocsátottak rendelkezésre, a feladat a meghibásodások bináris osztályozása volt. Szó esett a projektek értékelésének szempontjairól - az osztályozás minősége, kreativitás a funkciók létrehozásában, csapatmunka képessége stb. Ez csak balszerencse – 8 GB „funkcióhoz” mindössze 20 példa volt a vonatban és 5 a tesztben. Az utolsó szög a hackathon koporsójába az adatokból érkezett: a szerdán beérkezett felszerelési naplókban hiba volt a berendezés működésében, a csütörtökön készülteknél viszont nem (erről egyébként csak két csapat tudott, ill. mindkettő Oroszországból, a tapasztalt adatbányászok hazájából származott). Bár még a teszt valódi címkéinek ismerete sem segített a válasz meghatározásában, a feladat megoldhatatlan volt. A szervezők nem érték el a kívánt eredményt, a résztvevők sok időt töltöttek egy rosszul megtervezett probléma megoldásával. A hackathon sikertelen volt.
Erkölcs
Végezze el a megbízások műszaki felülvizsgálatát, és ellenőrizze a megbízások megfelelőségét. Jobb, ha túlfizet egy előzetes vizsgálatért (ebben az esetben minden adatkutató azonnal rámutat, hogy ezt a problémát lehetetlen megoldani), mint később megbánni.
Ebben az esetben az elvesztegetett idő és pénz mellett a cég hitelét vesztette a potenciális jelöltek előtt, és esetleg írt az eredményekről. A sikeres eredményekről egyébként ne csak a résztvevők, hanem a cég is írjon, maximalizálva a hackathont PR-szempontból. Sajnos nem minden cég csinálja ezt, csupán egy bejelentésre és pár fotóra szorítkozik az eseményről a Twitteren.
Hackathon No. 3. Vidd el vagy hagyd itt
Legutóbb egy hackathonon vett részt csapatunk Amszterdamban. Mivel végzettségem szerint villamosmérnök vagyok (megújuló energiaforrások témakörében), a téma pont nekünk szólt - energia. A hackathon online zajlott: a feladat leírását és egy hónapot kaptunk a teljesítésre. A szervezők egy kész projektet szerettek volna látni, amely elősegíti az amszterdami házak energiahatékonyságának növelését.
Készítettünk egy projektet, amiben előre jelezték az áramfogyasztást (előtte ebben a témában részt vettem egy pályázaton, ahol kaptam egy közeli sota megoldást, amiről olvashattok ) és napelemekkel történő generálás. Ezen előrejelzések alapján az akkumulátor teljesítménye optimalizálva van (ez az ötlet részben a diplomamunkámból származott). Projektünk jó összhangban volt mind a szervezők utasításaival (ahogy akkoriban nekünk tűnt), mind az amszterdami kormányzat politikájával a megújuló energiaforrások területén az elkövetkező években.
A projektek értékelése során sok csapathoz hasonlóan azt mondták nekünk, hogy a megrendelő nem ezt várja, hozzátéve, hogy újra kell csinálnunk a projektet, ha versenyezni akarunk a díjért. Nem csináltunk újra semmit, elfogadtuk a vereséget. A negyven résztvevő csapatból még a legjobb 7-be sem jutottunk be, bár a szervezők választása számomra meglehetősen furcsa volt. Például bejutottak a döntőbe azt a csapatot, amely egy alkalmazást készített a szélsebesség és a napsugárzás (SI) kiszámítására okostelefon-érzékelők adatainak felhasználásával: mikrofon a szélhez, fényérzékelő az SI-hez. A gyilkos jellemző a hotdog/nem hotdog három osztályba sorolása volt: Nap, szél, víz és a megfelelő cikk megjelenítése a Wikipédián ().
Hagyjuk egy pillanatra a kérdés morális oldalát: a résztvevőket a győzelem lehetőségével zsarolni egyszerűen etikátlan. Mivel a hackathonokon való részvétel egyik motivációja (különösen a tapasztalt fejlesztők számára) az ötleteik megvalósítása, sok erős résztvevő egyszerűen elhagyhatja az eseményt ilyen visszajelzések hallatán (ami nem csak a mi csapatunkkal történt, hanem sok mással is, akik abbahagyták). oldalprojektjének frissítése a mentor meghallgatása után). Mégis, tegyük fel, hogy egyetértettünk a szervezők kívánságaival, és a projektünket az igényeiknek megfelelően alakítottuk át. Mi történhet ezután?
Mivel a szervezőknek megvan a saját elképzelésük az „ideális projektről”, minden kívánság (és ennek megfelelően változás) ehhez az ideálishoz vezet. A versenyzők elvesztegetik az idejüket, és egyre nehezebb lesz megtagadniuk a további részvételt (hiszen már belefektették az erőfeszítéseiket, és úgy tűnik, egy kicsit távol állnak a győzelemtől). A valóságban azonban megnő a verseny a díjakért, és a résztvevőknek egyre gyakrabban kell újra elkészíteniük a projektet a szervezők szerkesztései alapján a nyeremény reményében. Ennek eredményeként azok a srácok, akik nem vettek át díjat, visszatekintve megértik, hogy pénz nélkül vettek részt szabadúszó munkában: szerkesztettek a megrendelőnek, de cserébe nem kaptak semmit (kivéve a vonatkozó tapasztalatot, pl. tanfolyam).
Erkölcs
Gyakran a szervezők kívánságai és visszajelzései segítik a projektet. Ugyanakkor a résztvevőknek nem szabad úgy hagyatkozniuk mentorok tanácsaira, mint sánta a botra. Ha a „vidd el, ezt nem mi rendeltük” jegyében hallasz visszajelzést a szervezőktől a projekteddel kapcsolatban, akkor a hackathonon való részvételed befejezettnek tekinthető.
Ha hackathont szervez, amelynek világos elképzelése van a projektről, de nincs készsége vagy képessége, hogy saját maga megvalósítsa, akkor jobb, ha az elképzelését egy szabadúszó műszaki specifikációi formájában formálja meg. Ellenkező esetben kétszer kell fizetnie – a hackathonért és a szabadúszó szolgáltatásaiért.
Forrás: will.com