A Számos okot mérlegeltem a hackathonokon való részvételre. A vágy, hogy sok újat tanuljak és értékes nyereményeket nyerjek, sokakat vonz, de gyakran a szervezők vagy a szponzorként fellépő cégek hibái miatt az események kudarcba fulladnak, és a résztvevők elégedetlenül távoznak. Ahhoz, hogy az ilyen kellemetlen esetek ritkábban forduljanak elő, ezt a bejegyzést írtam. A trilógia második része a szervezők hibáiról szól.
A bejegyzés felépítése a következő: elején beszámolok az eseményről, elmagyarázom, hogy mi ment rosszul, és hogy ez hova vezetett (vagy hová vezethet hosszú távon). Ezután értékelem az eseményeket, és elmondom, én hogyan jártam volna el a szervezők helyében. Mivel minden eseményen résztvevőként szerepeltem, csak sejteni tudom a szervezők igazi motivációját. Ennek következtében az értékelésem egyoldalú lehet. Nem zárhatom ki, hogy bizonyos dolgok, amelyeket hibásnak tartok, valójában így lettek tervezve.
Bizonyos pillanatokban az olvasónak úgy tűnhet, hogy a szerző a verekedés után kezdett el ökölbe szorítani. De biztosíthatom, hogy ez nem így van. Néhány említett hackathonban sikerült díjat nyernem, ami azonban nem akadályoz meg abban, hogy beszéljek arról, hogy az esemény rosszul volt megszervezve.
A szervezők és résztvevők iránti tiszteletből a bejegyzés nem fog konkrét cégeket megnevezni. A figyelmes olvasó azonban kitalálhatja (vagy utánanézhet), hogy kiről van szó.
Hackathon #1. Szoros keretek
Fél évvel ezelőtt egy nagy telekommunikációs cég adatfeldolgozó hackatont szervezett. 20 csapat versengett a díjalapért. Az eseményen egy elemzésre szánt adatbázis volt biztosítva, amely tartalmazta a cég ügyfélszolgálatának elérhetőségeiről, közösségi média aktivitásáról és a felhasználók (nem, életkor stb.) kódolt információiról szóló adatokat. Az adatbázis legérdekesebb része - a felhasználói üzenetek és az operátor válaszai (szöveges adatok) - eléggé „zajos” volt, a további munkához tisztítani kellett.
A szervezők feladatot tűztek ki — valami érdekeset készíteni a megadott adatokkal, miközben tilos volt további nyilvános adatmátrixokat használni az interneten vagy maguknak megbontani az adatokat. Az is tilos volt, hogy az adatmátrixhoz nem kapcsolódó ötleteket javasoljanak. Sajnos a megadott adatok meglehetősen "szegényesek" voltak: nehéz volt érdekes termékeket kinyerni belőlük, és a mentoraikkal folytatott beszélgetésekből kiderült, hogy sok javasolt ötlet már megvalósult (vagy a közeljövőben meg fog valósulni) a cégnél.
Ennek eredményeként a csapatok túlnyomó többsége (15 a 20-ból) csevegő robotokat készített. Az előadások során egy csapat megoldása alig különbözött az előzőtől. Ki nem bírva, a zsűri egyik tagja megkérdezte a következő színpadra lépő csapattól: "Nos, gyerekek, nálatok is van csevegő robot?" Ennek eredményeként a három díjazott helyből az első és második helyet olyan csapatok kapták, akik nem készítettek csevegő robotokat.
Összehasonlításképpen vegyük a nemzetközi tanácsadó cég által szervezett hackatont, amelyet a "Zvezdochka" cég számára tartottak két évvel ezelőtt. Mivel a "Zvezdochka" cég tevékenysége sok résztvevő számára ismeretlen volt, az esemény elején a szervezők bemutatták a vállalat által használt mutatókat. Ezután hat különböző irányú adatmátrixot biztosítottak: szövegek, táblázatok, geopozíciók — minden résztvevő számára szabad mozgást biztosítva. A szervezők nem tiltották az további adatmátrixok használatát, és még támogatták is az ilyen kezdeményezéseket. A verseny végén tíz csapat különböző megoldásokkal küzdött a fődíjért, és minden csapat a cég által bemutatott adatokat használta (a tilalmak ellenére), ami a minőségi termékek előállításának jó potenciálját jelezte.
Morál
Ne korlátozd a résztvevők kreatív áramlását. Szervezőként biztosítanod kell a szükséges anyagokat, és bízni kell a nézőpontjukban és szakmai tudásukban. Ha hackathon résztvevő vagy, bármilyen korlátozás vagy tilalom gyanakvásra ad okot. Ez általában gyenge szervezést jelez (valós példa — a folyamatos vágy, hogy valahová kerítést állítsunk). Ha mégis korlátozásokkal találkozol, készülj fel arra, hogy a versenyhelyzet nagy lesz. Ilyen esetben kockáztatnod kell: valami alapvetően újat kell alkotnod, vagy egy különleges „killer feature”-t kell ajánlanod, hogy kiemelkedj a hasonló projektek tengeréből.
Hackathon #2. Megvalósíthatatlan feladatok
Az Amadori hackathon érdekesnek ígérkezett. A szponzoráló cég — egy nagy telefongyártó — négy hónappal a rendezvény előtt elkezdte a felkészülést. A közösségi médiában zajlott a rendezvény népszerűsítése, a leendő résztvevőknek technikai teszten kellett részt venniük és előző projektjeikről kellett írniuk ahhoz, hogy kiválaszthassák őket az eseményre. A nyereményalap kellemesen nagy volt. Pár nappal a hackathon előtt a mentorok technikai szessziót tartottak, hogy a résztvevőknek legyen idejük a szektor sajátosságait megérteni.
Magán a rendezvényen a szervezők egy 8 GB-os berendezési napló adatállományt biztosítottak, a feladat — bináris hibaosztályozás. Elmondták a projektek értékelésének kritériumait — a klasszifikálás minősége, a funkciók kreatív kidolgozása, a csapatmunkához való alkalmazkodás stb. Csakhogy a probléma az volt, hogy a 8 GB „funkció“ között mindössze 20 példa állt rendelkezésre a tanulási minták között és 5 a teszteléshez. A hackathon végső koporsószögét a torz adatok ütötték be: a szerdai naplókból származó adatok berendezési hibát tartalmaztak, míg a csütörtök egy napon készült naplók nem, és ezt az információt szóban csak két csapat tudta, mindkettő Oroszországból származott — a tapasztalt adatbányászok hazájából. Bár a teszt valódi címkéinek ismerete sem segített a válaszok megformálásában — a feladat megoldhatatlan volt. A szervezők nem érték el a kívánt eredményt, a résztvevők rengeteg időt pazaroltak el egy rosszul felépített feladat megoldására. A hackathon megbukott.
Morál
Készítse el a feladatok technikai szakértéseit, és ellenőrizze a feladatait a megfelelőség érdekében. Jobb előre kifizetni a szakértői véleményt (ebben az esetben bármely adatkutató azonnal rámutatna a feladat megoldhatatlanságára), mint utólag megbánni.
Ebben az esetben a felhasznált idő és pénz mellett a cég elvesztette a potenciális jelöltek bizalmát, és lehet, hogy nem tudnak beszámolni az eredményekről. Érdemes megemlíteni, hogy a sikeres eredményekről nemcsak a résztvevőknek, hanem a cégnek is beszélnie kell, maximálisan kihasználva a hackathon PR szempontjait. Sajnos nem minden cég teszi ezt, csupán a bejelentő posztra és egy-két fényképre korlátozva az eseményt a Twitteren.
Hackathon #3. Fogadd el vagy hagyd figyelmen kívül.
Nemrégiben csapatunk részt vett egy hackathonon Amszterdamban. Mivel mérnök-energetikai diplomám van (megújuló energiaforrások terén), a téma éppen nekünk való volt — energia. A hackathon online formátumban zajlott: kaptunk egy feladatleírást, és egy hónapot a teljesítésre. A szervezők azt szerették volna látni, hogy készen áll egy projekt, amely segít növelni Amszterdam házainak energiahatékonyságát.
Készítettünk egy projektet, amely előrejelzi az elektromos energiafogyasztást (korábban részt vettem egy erre a témára vonatkozó versenyen, ahol körülbelül egy SOTA megoldást kaptam, amiről lehet olvasni) és a napelem által generált energiát. Ezen előrejelzések alapján optimalizáljuk az akkumulátoros rendszer működését (ez az ötlet részben a mesterdiplomám alapján készült). A projektünk jól illeszkedett a szervezők által kiírt feladatokhoz (ahogy akkor nekünk tűnt), és Amszterdam önkormányzatának megújuló energiaforrásokkal kapcsolatos politikájához is az elkövetkező években.
A projektek értékelése során nekünk, ahogyan sok csapatnak, azt mondták, hogy ez nem az, amit a megrendelő várt, hozzátéve, hogy át kell dolgoznunk a projektet, ha versenyezni szeretnénk a díjakért. Mi nem csináltunk semmit újra, belenyugodtunk a kudarcba. A negyven résztvevő csapatból még a top 7-be sem jutottunk be, bár az organizátorok választása, véleményem szerint, elég furcsa volt. Például a döntőbe nem jutott be az a csapat, amely egy alkalmazást készített a szélsebesség és a napenergia (SI) számításához a mobiltelefon érzékelői alapján: mikrofonnal a szélhez, fényérzékelővel az SI-hez. A killer feature a hotdog/not hotdog három osztályba való besorolása volt: nap, szél, víz és a megfelelő Wikipedia cikk megjelenítése.).
Hagyd most egy pillanatra a kérdés erkölcsi oldalát: a résztvevők zsarolása a győzelem lehetőségével egyszerűen etikátlan. Mivel a hackathonokban való részvétel egyik motivációja (különösen a tapasztalt fejlesztők számára) az, hogy megvalósítsák ötleteiket, sok erős résztvevő egyszerűen elhagyhatja az eseményt, miután ilyen visszajelzést kaptak (ami nemcsak a mi csapatunkkal történt meg, hanem több más csapattal is, akik abbahagyták a projektjük oldalának frissítését a mentor értékelése után). Mégis, tegyük fel, hogy elfogadtuk az organizátorok kérését, és átírtuk a projektünket az ő igényeiknek megfelelően. Mi történhet ezután?
Mivel az organizátoroknak megvan a saját elképzelésük a „tökéletes projektről”, minden kérés (és ennek megfelelően a változtatások) minket arra az idealizált képhez fognak vezetni. A versenyzők egyre több időt fognak elköltöni, és egyre nehezebb lesz számukra visszakozni a további részvételtől (mivel már energiát fektettek az eseménybe, és úgy tűnik, hogy a győzelem már nagyon közel van). De valójában a verseny a díjakért fokozódni fog, és a résztvevőknek egyre gyakrabban kell átdolgozniuk a projektjüket az organizátorok javításai alapján, abban a reményben, hogy díjat nyernek. Végül azok a fiúk, akik nem nyerték el a díjakat, visszatekintve rájönnek, hogy olyan független munkát végeztek, amiért nem kaptak semmit cserébe (kivéve természetesen a megfelelő tapasztalatot).
Morál
Gyakran a szervezők kívánságai és visszajelzései segítenek a projektnek. Ezzel azonban a résztvevőknek nem kell a mentorok tanácsaira támaszkodniuk, mint ahogy a sánta támaszkodik a botjára. Ha a szervezőktől olyan visszajelzést hallasz a projekteddel kapcsolatban, hogy "távolítsd el, ezt nem kértük" — akkor a hackathonon való részvételedet ezen a ponton befejezettnek tekintheted.
Ha hackatont szervezel tiszta projekttel a fejedben, de nincs készséged vagy lehetőséged arra, hogy azt önállóan megvalósítsd, akkor jobb, ha a látásodat egy műszaki leírás formájában fogalmazod meg egy szabadúszó számára. Ellenkező esetben kétszer kell fizetned — egyszer a hackathonért, egyszer a szabadúszó szolgáltatásaiért.
Forrás: habr.com
