În Am analizat câteva motive pentru a participa la hackathoane. Motivația de a învăța lucruri noi și de a câștiga premii valoroase atrage mulți, dar adesea din cauza greșelilor organizatorilor sau a companiilor sponsori, evenimentul se încheie nefericit și participanții pleacă nemulțumiți. Pentru ca astfel de situații neplăcute să apară mai rar, am scris această postare. A doua parte a trilogiei se concentrează pe greșelile organizatorilor.
Postarea este organizată în felul următor: la început povestesc despre eveniment, explic ce nu a mers bine și la ce a condus aceasta (sau ce ar putea conduce pe termen lung). Apoi îmi ofer evaluarea asupra celor întâmplate și cum aș acționa în locul organizatorilor. Deoarece la toate evenimentele am participat ca participant, pot doar să îmi imaginez adevărata motivație a organizatorilor. Ca urmare, evaluarea mea ar putea fi subiectivă. Nu exclud faptul că anumite aspecte care mi se par greșite au fost, de fapt, intenționate.
La un moment dat, cititorului i s-ar putea părea că autorul a decis să fluture pumnii după bătaie. Dar vă pot asigura că nu este cazul. La unele dintre hackathoanele enumerate am reușit să ocup un loc premiat, ceea ce, totuși, nu împiedică afirmația că evenimentul a fost prost organizat.
Din respect pentru organizatori și participanți, în postare nu vor fi menționate companii specifice. Totuși, un cititor atent poate deduce (sau căuta pe Google) despre cine este vorba.
Hackathon Nr. 1. Cadre stricte
Acum șase luni, o companie mare de telecomunicații a organizat un hackathon pentru analiza datelor. 20 de echipe au concurat pentru fondul de premii. La eveniment a fost oferit un set de date pentru analiză, care conținea informații despre apelurile către serviciul de asistență al companiei, activitatea pe rețelele sociale și informații codificate despre utilizatori (sex, vârstă etc). Cea mai interesantă parte a setului de date — mesajele utilizatorului și răspunsul operatorului (date textuale) — era destul de „zgomotoasă”, fiind necesară curățarea acesteia pentru o utilizare ulterioară.
Organizatorii au impus o sarcină - de a crea ceva interesant cu datele furnizate, interzicându-se utilizarea seturilor de date deschise suplimentare din rețea sau scrierea de date personale. De asemenea, nu erau permise idei care să nu fie legate de setul de date. Din păcate, datele furnizate erau destul de „sărăcăcioase”: era greu să obții produse interesante din ele, iar din discuțiile cu mentorii a devenit clar că multe dintre ideile propuse deja erau implementate (sau vor fi implementate în viitorul apropiat) în companie.
În rezultatul acesta, majoritatea echipelor (15 din 20) au dezvoltat chat-boti. În timpul prezentărilor, soluția unei echipe se distingea puțin de cea anterioară. Neputând rezista, unul dintre membrii juriului a întrebat echipa care a urcat pe scenă: „Ce, băieți, și voi aveți un chat-bot?”. În cele din urmă, din cele trei locuri premiate, primul și al doilea au fost câștigate de echipele care nu au realizat chat-boti.
Pentru o comparație, să luăm hackathonul organizat de o companie internațională de consultanță pentru firma „Zvezdochka” acum doi ani. Deoarece specificul activității companiei „Zvezdochka” nu era familiar multor participanți la hackathon, la începutul evenimentului organizatorii au prezentat metricile utilizate în companie. După aceea, au fost furnizate șase seturi de date din diverse domenii: texte, tabele, geolocație - toți participanții aveau spațiu pentru manevră. Organizatorii nu interziceau utilizarea seturilor de date suplimentare și chiar sprijineau astfel de inițiative. La finalul competiției, zece echipe cu soluții diferite s-au luptat pentru marele premiu, iar toate echipele au utilizat datele prezentate de companie (în ciuda absenței interdicțiilor), ceea ce demonstrează un bun potențial pentru obținerea de produse de calitate.
Morală
Nu trebuie să limitezi fluxul creativ al participanților. În calitate de organizator, trebuie să oferi materiale și să ai încredere în viziunea și profesionalismul lor. Dacă ești participant la hackathon, orice limitare sau interdicție ar trebui să te alerteze. De obicei, aceasta este o dovadă a unei organizații slabe (un exemplu din viața reală — dorința constantă de a înfinge un gard undeva). Dacă te confronti totuși cu restricții, fii pregătit să creezi un proiect într-un mediu cu competiție mare. Într-un astfel de caz, trebuie să-ți asumi riscuri: să faci ceva complet nou sau să propui o „caracteristică ucigașă” neobișnuită pentru a te evidenția din fluxul proiectelor monotone.
Hackathon Nr. 2. Sarcini imposibile
Hackathonul din Amador promitea a fi interesant. Compania sponsor — un mare producător de telefoane, a început pregătirile cu 4 luni înainte de data desfășurării. Pe rețelele sociale s-a desfășurat o campanie de promovare a evenimentului, iar participanții potențiali trebuiau să treacă un test tehnic și să scrie despre proiectele lor anterioare pentru a fi selectați la acest eveniment. Fondul de premii a fost plăcut de generos. Cu câteva zile înainte de hackathon, mentorii au organizat o sesiune tehnică pentru ca participanții să aibă timp să se familiarizeze cu specificul industriei.
La evenimentul propriu-zis, organizatorii au furnizat un set de date cu loguri de echipamente de 8 GB, sarcina — clasificarea binară a defectelor. Au discutat despre criteriile de evaluare a proiectelor — calitatea clasificării, creativitatea în generarea caracteristicilor, abilitatea de a lucra în echipă etc. Doar că, neplăcut, în cele 8 GB de „caracteristici”, au fost doar 20 de exemple în setul de antrenament și 5 în cel de testare. Ultimul cui în capacul sicriului hackathonului a fost pus de lipsa de date: logurile de echipamente obținute miercuri conțineau o eroare în funcționarea echipamentului, iar cele realizate joi — nu conțineau (despre aceasta, de altfel, știau doar două echipe, și ambele erau din Rusia — patria mineriadei de date experimentați). Chiar și cunoașterea etichetelor adevărate de test nu a ajutat la ajustarea răspunsului — sarcina era imposibil de rezolvat. Organizatorii nu au obținut rezultatul dorit, participanții au pierdut mult timp rezolvând o problemă prost formulată. Hackathonul a fost un eșec.
Morală
Efectuați expertize tehnice asupra sarcinilor și verificați adecvarea acestora. Mai bine să plătiți în plus pentru o expertiză preliminară (în acest caz, orice specialist în știința datelor ar fi subliniat imediat imposibilitatea de a rezolva această sarcină), decât să regretați mai târziu.
În acest caz, pe lângă timpul și banii cheltuiți, compania a pierdut credibilitatea în fața candidaților potențiali și ar putea fi, de asemenea, să scrie despre rezultate. Apropo, rezultatele reușite ar trebui să fie scrise nu doar de participanți, ci și de companie, maximizând astfel impactul hackathonului din punct de vedere al PR-ului. Din păcate, nu toate companiile fac acest lucru, limitându-se doar la un post de anunț și câteva fotografii de la eveniment pe Twitter.
Hackathonul nr. 3. Ia-l sau lasă-l
Recent, echipa noastră a participat la un hackathon în Amsterdam. Deoarece educația mea este în domeniul ingineriei electrice (în domeniul surselor de energie regenerabilă), tema a fost potrivită pentru noi - energia. Hackathonul a avut loc online: ne-au fost date descrierile sarcinii și o lună pentru finalizare. Organizatorii doreau să vadă un proiect finalizat care să ajute la creșterea eficienței energetice a caselor din Amsterdam.
Am realizat un proiect în care se prezice consumul de energie electrică (anterior am participat la o competiție pe această temă unde am obținut o soluție aproape de vârf, despre care se poate citi ) și generarea de energie prin panouri solare. Pe baza acestor predicții, se optimizează funcționarea bateriei de acumulare (această idee a fost parțial preluată din teza mea de masterat). Proiectul nostru era bine aliniat atât cu sarcina dată de organizatori (așa ne părea atunci), cât și cu politica administrației din Amsterdam în domeniul surselor de energie regenerabilă pentru anii următori.
În timpul evaluării proiectelor, nouă, la fel ca multor echipe, ni s-a spus că acest lucru nu este ceea ce aștepta clientul, adăugând că trebuie să refacem proiectul dacă dorim să concurăm pentru un loc pe podium. Nu am refăcut nimic, acceptând înfrângerea. Din patruzeci de echipe participante, nu am ajuns nici măcar în top 7, deși alegerea organizatorilor mi s-a părut destul de ciudată. De exemplu, au lăsat în finală o echipă care a realizat o aplicație pentru calcularea vitezei vântului și a radiației solare (SI) pe baza datelor senzorilor smartphone-ului: un microfon pentru vânt, un senzor de luminozitate pentru SI. Funcția inedită era clasificarea hotdog/not hotdog în trei clase: Soare, Vânt, Apă și afișarea articolului corespunzător de pe Wikipedia.).
Să lăsăm deoparte, pentru o clipă, latura morală a problemei: a șantaja participanții cu posibilitatea de a câștiga este pur și simplu lipsit de etică. Deoarece una dintre motivațiile pentru a participa la hackathoane (în special pentru dezvoltatorii experimentați) este realizarea ideilor proprii, mulți participanți talentați pot să părăsească pur și simplu evenimentul în auzind un astfel de feedback (ceea ce s-a întâmplat nu doar cu echipa noastră, ci și cu alte câteva echipe care au încetat să actualizeze pagina proiectului lor după întâlnirea cu mentorul). Totuși, să presupunem că am acceptat sugestiile organizatorilor și ne-am refăcut proiectul conform cerințelor lor. Ce ar putea să se întâmple mai departe?
Deoarece organizatorii au propria lor înțelegere a „proiectului ideal”, toate sugestiile (și, în consecință, modificările) ne vor conduce către acest ideal. Participanții vor pierde timp și le va fi din ce în ce mai greu să renunțe la participarea ulterioară (deoarece deja au investit eforturi și pare că sunt foarte aproape de victorie). Însă, de fapt, competiția pentru locurile premiante va crește, iar participanții vor trebui din ce în ce mai des să refacă proiectul conform modificărilor organizatorilor în speranța de a obține un premiu. În final, băieții care nu au obținut locuri pe podium, privindu-se înapoi, își vor da seama că au participat la freelancing fără plată: au făcut modificări pentru client, dar nu au obținut nimic în schimb (cu excepția, desigur, a experienței corespunzătoare).
Morală
Deseori, dorințele și feedback-ul din partea organizatorilor vin în ajutorul proiectului. Totuși, participanții nu ar trebui să se bazeze pe sfaturile mentorilor ca un om fără picior pe o cârje. Dacă auziți feedback de la organizatori pe proiectul vostru de genul "îndepărtați asta, nu am comandat" — participarea voastră la hackathon poate fi considerată încheiată.
Dacă organizați un hackathon cu o viziune clară asupra proiectului, dar fără abilități sau posibilitatea de a-l implementa singuri, este mai bine să vă transformați viziunea într-un caiet de sarcini pentru un freelancer. Altminteri, va trebui să plătiți de două ori — pentru hackathon și pentru serviciile freelancerului.
Sursa: habr.com
