В Am analizat mai multe motive pentru a participa la hackathonuri. Motivația de a învăța multe lucruri noi și de a câștiga premii valoroase îi atrage pe mulți, dar adesea, din cauza greșelilor organizatorilor sau companiilor sponsorizate, evenimentul se încheie fără succes, iar participanții pleacă nemulțumiți. Pentru ca astfel de incidente neplăcute să se întâmple mai rar, am scris această postare. A doua parte a trilogiei este dedicată greșelilor organizatorilor.
Postarea este organizată astfel: la început vorbesc despre eveniment, explic ce a mers prost și la ce a dus (sau poate duce pe termen lung). Apoi îmi dau evaluarea a ceea ce se întâmplă și ce aș face dacă aș fi organizatorii. Din moment ce am participat la toate evenimentele, nu pot decât să-mi asum adevărata motivație a organizatorilor. Ca urmare, evaluarea mea poate fi unilaterală. Nu exclud ca unele puncte care mi se par eronate au fost de fapt concepute astfel.
La un moment dat, cititorul poate crede că autorul a decis să fluture pumnii după o luptă. Dar vă pot asigura că nu este cazul. În unele dintre hackathoanele enumerate, am reușit să iau un premiu, ceea ce, însă, nu ne împiedică să spunem că evenimentul a fost prost organizat.
Din respect pentru organizatori și participanți, în postare nu vor fi referiri la anumite companii. Un cititor atent, însă, poate ghici (sau Google) despre cine vorbim.
Hackathon nr. 1. Cadre stricte
În urmă cu șase luni, o mare companie de telecomunicații a organizat un hackathon privind analiza datelor. 20 de echipe au concurat pentru fondul de premii. La eveniment a fost furnizat spre analiză un set de date, care conținea informații despre apelurile către serviciul de asistență al companiei, activitatea pe rețelele de socializare și informații codificate despre utilizatori (sex, vârstă etc.). Cea mai interesantă parte a setului de date — mesajele utilizatorului și răspunsurile operatorului (date text) — era destul de zgomotoasă și trebuia curățată pentru lucrări ulterioare.
Organizatorii au stabilit o sarcină - să facă ceva interesant cu datele furnizate și a fost interzis să folosești seturi de date suplimentare deschise din rețea sau să analizezi singur datele. De asemenea, a fost interzisă propunerea de idei care nu au legătură cu setul de date. Din păcate, datele furnizate au fost destul de „sărace”: a fost dificil să obțineți produse interesante de la ei, iar din comunicarea cu mentorii a devenit clar că multe dintre ideile propuse sunt deja implementate (sau vor fi implementate în viitorul apropiat) in compania.
Drept urmare, numărul covârșitor de echipe (15 din 20) a creat chatboți. În timpul spectacolelor, decizia unei echipe a fost puțin diferită de cea anterioară. Incapabil să suporte, unul dintre membrii juriului a întrebat următoarea echipă care urca pe scenă: „Ce, băieți, aveți și un chatbot?” Drept urmare, din trei premii, locurile I și II au revenit echipelor care nu au făcut chatbot.
Pentru comparație, să luăm un hackathon organizat de o companie internațională de consultanță pentru compania Zvezdochka în urmă cu doi ani. Întrucât specificul activităților companiei Zvezdochka nu era familiar pentru mulți participanți la hackathon, la începutul evenimentului organizatorii au vorbit despre valorile utilizate în companie. După aceasta, au fost furnizate șase seturi de date de diferite tipuri: text, tabele, geolocalizare - a existat spațiu de manevră pentru toți participanții. Organizatorii nu au interzis utilizarea unor seturi de date suplimentare și chiar au susținut astfel de inițiative. În finala competiției, zece echipe cu soluții diferite au concurat pentru premiul principal, toate echipele utilizând datele furnizate de companie (în ciuda lipsei de restricții), ceea ce indica un potențial bun de obținere a produselor de calitate.
moralitate
Nu este nevoie să limitați fluxul creativ al participanților. În calitate de organizator, trebuie să oferi materiale și să ai încredere în viziunea și profesionalismul lor. Dacă participați la un hackathon, orice restricții sau interdicții ar trebui să vă alarmeze. De obicei, aceasta este o dovadă a unei organizații slabe (un exemplu din viața reală este dorința constantă de a lipi un gard undeva). Dacă întâmpinați restricții, atunci fiți pregătiți pentru faptul că va trebui să creați un proiect într-un bazin cu multă concurență. În acest caz, sunteți obligat să vă asumați riscuri: faceți ceva fundamental nou sau oferiți o „funcție ucigașă” neobișnuită pentru a ieși din fluxul de proiecte monotone.
Hackatonul nr. 2. Sarcini imposibile
Hackathonul din Amador promitea a fi interesant. Compania sponsor, un mare producator de telefoane, a inceput pregatirile cu 4 luni inainte de data evenimentului. PR pentru eveniment a fost realizat pe rețelele de socializare; potențialii participanți au trebuit să treacă un test tehnic și să scrie despre proiectele lor anterioare pentru a fi selectați pentru acest eveniment. Fondul de premii a fost plăcut de mare. Cu câteva zile înainte de hackathon, mentorii au susținut o sesiune tehnică pentru ca participanții să aibă timp să înțeleagă specificul industriei.
La evenimentul în sine, organizatorii au furnizat un set de date de jurnalele echipamentelor cu un volum de 8 GB, sarcina a fost o clasificare binară a defecțiunilor. Au vorbit despre criteriile de evaluare a proiectelor - calitatea clasificării, creativitate în crearea de caracteristici, capacitatea de a lucra în echipă etc. Este doar ghinion - pentru 8 GB de „funcții”, au fost doar 20 de exemple în tren și 5 în test. Ultimul cui din sicriul hackatonului a venit din date: jurnalele de echipament primite miercuri conțineau o eroare în funcționarea echipamentului, dar cele create joi nu au făcut-o (apropo, doar două echipe știau despre asta și ambii erau din Rusia, patria minerii de date experimentați). Deși chiar și cunoașterea adevăratelor etichete ale testului nu a ajutat la determinarea răspunsului - sarcina era de nerezolvat. Organizatorii nu au obținut rezultatul dorit, participanții au petrecut mult timp rezolvând o problemă prost concepută. Hackatonul a fost un eșec.
moralitate
Efectuați evaluări tehnice ale misiunilor și verificați adecvarea sarcinilor dvs. Este mai bine să plătiți în exces pentru o examinare preliminară (în acest caz, orice cercetător de date ar sublinia imediat că este imposibil să rezolvați această problemă) decât să regretați mai târziu.
În acest caz, pe lângă timpul și banii pierduti, compania și-a pierdut credibilitatea față de potențialii candidați și, eventual, a scris despre rezultate. Apropo, nu numai participanții, ci și compania ar trebui să scrie despre rezultate de succes, maximizând hackatonul din punct de vedere PR. Din păcate, nu toate companiile fac acest lucru, limitându-se doar la o postare de anunț și câteva fotografii de la eveniment pe Twitter.
Hackatonul nr. 3. Ia-l sau pleaca
Cel mai recent, echipa noastră a participat la un hackathon la Amsterdam. Întrucât sunt inginer electrician de formare (în domeniul surselor de energie regenerabilă), tema a fost tocmai potrivită pentru noi - energia. Hackathonul a avut loc online: ni s-a oferit o descriere a sarcinii și o lună pentru a o finaliza. Organizatorii au dorit să vadă un proiect finalizat care să contribuie la creșterea eficienței energetice a caselor din Amsterdam.
Am realizat un proiect în care s-a prevăzut consumul de energie electrică (înainte de asta am participat la un concurs pe această temă unde am primit o soluție aproape sota, despre care puteți citi ) și generare prin panou solar. Pe baza acestor predicții, performanța bateriei este optimizată (această idee a fost preluată parțial din teza mea de master). Proiectul nostru a fost în bun acord atât cu indicațiile organizatorilor (cum ni s-a părut atunci), cât și cu politica administrației de la Amsterdam în domeniul surselor de energie regenerabilă pentru câțiva ani de acum înainte.
În timpul evaluării proiectelor, nouă, la fel ca multe echipe, ni s-a spus că acest lucru nu este ceea ce se aștepta clientul, adăugând că trebuie să refacem proiectul dacă vrem să concuram pentru premiu. Nu am refăcut nimic, acceptând înfrângerea. Dintre cele patruzeci de echipe participante, nici nu am ajuns în top 7, deși alegerea organizatorilor, mi se pare, a fost destul de ciudată. De exemplu, au permis echipei să treacă în finala care a creat o aplicație pentru calcularea vitezei vântului și a radiației solare (SI) folosind date de la senzorii smartphone-ului: un microfon pentru vânt, un senzor de lumină pentru SI. Caracteristica ucigașă a fost clasificarea hotdog/nu hotdog în trei clase: Soare, vânt, apă și afișarea articolului corespunzător pe Wikipedia ().
Să lăsăm pentru un moment latura morală a problemei: șantajarea participanților cu posibilitatea de victorie este pur și simplu lipsită de etică. Deoarece una dintre motivațiile participării la hackathon-uri (în special dezvoltatorii cu experiență) este realizarea ideilor lor, mulți participanți puternici pot părăsi evenimentul pur și simplu după ce au auzit un astfel de feedback (ceea ce sa întâmplat nu numai echipei noastre, ci și altora care s-au oprit). actualizându-și proiectul de pagină după ascultarea mentorului). Totuși, să presupunem că am fost de acord cu dorințele organizatorilor și am refăcut proiectul pentru a se potrivi cerințelor acestora. Ce s-ar putea întâmpla în continuare?
Deoarece organizatorii au propria lor înțelegere a „proiectului ideal”, toate dorințele (și, în consecință, schimbările) ne vor conduce către acest ideal. Concurenții își vor pierde timpul și le va fi din ce în ce mai greu să refuze participarea ulterioară (deoarece și-au investit deja eforturile și se pare că sunt doar puțin departe de victorie). Dar, în realitate, competiția pentru premii va crește, iar participanții vor trebui din ce în ce mai mult să refacă proiectul pe baza editărilor organizatorilor în speranța de a câștiga un premiu. Drept urmare, băieții care nu au luat premii, privind în urmă, vor înțelege că au participat la freelancer fără bani: au făcut editări pentru client, dar nu au primit nimic în schimb (cu excepția experienței relevante, a curs).
moralitate
Adesea, dorințele și feedback-ul organizatorilor vin în sprijinul proiectului. În același timp, totuși, participanții nu ar trebui să se bazeze pe sfaturile mentorilor ca un om șchiop pe un baston. Dacă auziți feedback de la organizatori cu privire la proiectul dvs. în spiritul „luați-l, nu am comandat acest lucru”, participarea dumneavoastră la hackathon poate fi considerată finalizată.
Dacă organizezi un hackathon cu o viziune clară pentru proiect, dar fără abilitățile sau capacitatea de a-l implementa singur, atunci este mai bine să-ți oficializezi viziunea sub forma unor specificații tehnice pentru un freelancer. În caz contrar, va trebui să plătiți de două ori – pentru hackathon și pentru serviciile freelancerului.
Sursa: www.habr.com