В Unë kam shikuar disa arsye për të marrë pjesë në hackathons. Motivimi për të mësuar shumë gjëra të reja dhe për të fituar çmime të vlefshme tërheq shumë, por shpesh, për shkak të gabimeve të organizatorëve apo kompanive sponsorizuese, eventi përfundon pa sukses dhe pjesëmarrësit largohen të pakënaqur. Për të bërë incidente të tilla të pakëndshme të ndodhin më rrallë, kam shkruar këtë postim. Pjesa e dytë e trilogjisë i kushtohet gabimeve të organizatorëve.
Postimi është organizuar si më poshtë: në fillim flas për ngjarjen, shpjegoj se çfarë shkoi keq dhe në çfarë çoi (ose mund të çojë në afat të gjatë). Më pas jap vlerësimin tim për atë që po ndodh dhe çfarë do të bëja nëse do të isha organizator. Meqenëse kam marrë pjesë në të gjitha ngjarjet, mund të supozoj vetëm motivimin e vërtetë të organizatorëve. Si rezultat, vlerësimi im mund të jetë i njëanshëm. Nuk e përjashtoj që disa pika që më duken të gabuara, në fakt janë menduar kështu.
Në një moment të caktuar, lexuesi mund të mendojë se autori vendosi të tundte grushtat pas një zënke. Por mund t'ju siguroj se nuk është kështu. Në disa nga hackathon-et e listuara, arrita të marr një çmim, i cili megjithatë nuk na pengon të themi se ngjarja ishte e organizuar keq.
Për respekt për organizatorët dhe pjesëmarrësit, nuk do të ketë referenca për kompani të veçanta në postim. Sidoqoftë, një lexues i vëmendshëm mund të hamendësojë (ose Google) se për kë po flasim.
Hackathon nr. 1. Korniza strikte
Gjashtë muaj më parë, një kompani e madhe telekomi organizoi një hackathon mbi analizën e të dhënave. 20 ekipe garuan për fondin e çmimeve. Në këtë event u sigurua për analizë një grup të dhënash, i cili përmbante informacione për thirrjet në shërbimin mbështetës të kompanisë, aktivitetin në rrjetet sociale dhe informacione të koduara për përdoruesit (gjinia, mosha, etj.). Pjesa më interesante e grupit të të dhënave - mesazhet e përdoruesit dhe përgjigjet e operatorit (të dhënat me tekst) - ishte mjaft e zhurmshme dhe duhej pastruar për punë të mëtejshme.
Organizatorët vendosën një detyrë - të bënin diçka interesante me të dhënat e dhëna, dhe ishte e ndaluar të përdorni grupe të dhënash të hapura shtesë nga rrjeti ose të analizoni vetë të dhënat. Gjithashtu ishte e ndaluar të propozoheshin ide që nuk lidhen me grupin e të dhënave. Fatkeqësisht, të dhënat e ofruara ishin mjaft "të dobëta": ishte e vështirë të merrje ndonjë produkt interesant prej tyre, dhe nga komunikimi me mentorët u bë e qartë se shumë nga idetë e propozuara tashmë janë duke u zbatuar (ose do të zbatohen në të ardhmen e afërt) në kompani.
Si rezultat, numri dërrmues i ekipeve (15 nga 20) bënë chatbots. Gjatë shfaqjeve, vendimi i një ekipi ishte pak i ndryshëm nga ai i mëparshmi. Në pamundësi për të duruar, një nga anëtarët e jurisë pyeti ekipin tjetër që doli në skenë: "Çfarë, djema, a keni edhe ju një chatbot?" Si rezultat, nga tre çmime, vendet e para dhe të dyta u takuan skuadrave që nuk bënë chatbot.
Për krahasim, le të marrim një hackathon të organizuar nga një kompani ndërkombëtare konsulente për kompaninë Zvezdochka dy vjet më parë. Meqenëse specifikat e aktiviteteve të kompanisë Zvezdochka ishin të panjohura për shumë pjesëmarrës të hackathon, në fillim të ngjarjes organizatorët folën për metrikat që përdoren në kompani. Pas kësaj, u siguruan gjashtë grupe të dhënash të llojeve të ndryshme: tekst, tabela, gjeolokacion - kishte vend për manovrim për të gjithë pjesëmarrësit. Organizatorët nuk e ndaluan përdorimin e të dhënave shtesë dhe madje mbështetën iniciativa të tilla. Në finale të konkursit, dhjetë ekipe me zgjidhje të ndryshme konkurruan për çmimin kryesor, ku të gjitha ekipet përdorën të dhënat e ofruara nga kompania (pavarësisht mungesës së kufizimeve), të cilat tregonin potencial të mirë për marrjen e produkteve cilësore.
Morali
Nuk ka nevojë të kufizohet fluksi krijues i pjesëmarrësve. Si organizator, ju duhet të siguroni materiale dhe t'i besoni vizionit dhe profesionalizmit të tyre. Nëse jeni pjesëmarrës në një hackathon, çdo kufizim apo ndalim duhet t'ju alarmojë. Zakonisht kjo është dëshmi e organizimit të dobët (një shembull nga jeta reale është dëshira e vazhdueshme për të ngjitur një gardh diku). Nëse hasni kufizime, atëherë përgatituni për faktin se do t'ju duhet të krijoni një projekt në një pishinë me shumë konkurrencë. Në këtë rast, ju jeni të detyruar të merrni rreziqe: bëni diçka thelbësisht të re ose ofroni një "tipar vrasës" të pazakontë në mënyrë që të dilni nga rryma e projekteve monotone.
Hackathon nr. 2. Detyra të pamundura
Hackathon në Amador premtoi të ishte interesant. Kompania sponsorizuese, një prodhues i madh telefonash, filloi përgatitjet 4 muaj përpara datës së ngjarjes. PR për ngjarjen u krye në rrjetet sociale; pjesëmarrësit e mundshëm duhej të kalonin një test teknik dhe të shkruanin për projektet e tyre të kaluara në mënyrë që të përzgjidheshin për këtë ngjarje. Fondi i çmimeve ishte mjaft i madh. Disa ditë para hackathon-it, mentorët mbajtën një seancë teknike në mënyrë që pjesëmarrësit të kishin kohë të kuptonin specifikat e industrisë.
Në vetë ngjarjen, organizatorët siguruan një grup të dhënash të regjistrave të pajisjeve me një vëllim prej 8 GB, detyra ishte një klasifikim binar i prishjeve. Ata folën për kriteret e vlerësimit të projekteve – cilësinë e klasifikimit, kreativitetin në krijimin e veçorive, aftësinë për të punuar në ekip, etj. Është thjesht fat i keq - për 8 GB "veçori", kishte vetëm 20 shembuj në tren dhe 5 në provë. Gozhda e fundit në arkivolin e hackathon erdhi nga të dhënat: regjistrat e pajisjeve të marra të mërkurën përmbanin një gabim në funksionimin e pajisjeve, por ato të krijuara të enjten nuk e kishin (nga rruga, vetëm dy ekipe dinin për këtë, dhe të dy ishin nga Rusia, atdheu i minatorëve me përvojë të të dhënave). Edhe pse edhe njohja e etiketave të vërteta të testit nuk ndihmoi për të përcaktuar përgjigjen - detyra ishte e pazgjidhshme. Organizatorët nuk morën rezultatin e dëshiruar; pjesëmarrësit shpenzuan shumë kohë për të zgjidhur një problem të projektuar keq. Hackathon ishte një dështim.
Morali
Kryeni rishikime teknike të detyrave dhe kontrolloni detyrat tuaja për përshtatshmëri. Është më mirë të paguani shumë për një ekzaminim paraprak (në këtë rast, çdo shkencëtar i të dhënave do të theksonte menjëherë se është e pamundur të zgjidhet ky problem) sesa të pendoheni më vonë.
Në këtë rast, përveç kohës dhe parave të humbura, kompania humbi besueshmërinë me kandidatët e mundshëm dhe ndoshta ka shkruar për rezultatet. Nga rruga, jo vetëm pjesëmarrësit, por edhe kompania duhet të shkruajnë për rezultate të suksesshme, duke maksimizuar hackathon nga një këndvështrim PR. Fatkeqësisht, jo të gjitha kompanitë e bëjnë këtë, duke u kufizuar vetëm në një postim njoftimi dhe disa foto nga ngjarja në Twitter.
Hackathon nr. 3. Merre ose lëre
Së fundmi, ekipi ynë mori pjesë në një hackathon në Amsterdam. Meqenëse jam një inxhinier elektrik me trajnim (në fushën e burimeve të rinovueshme të energjisë), tema ishte e duhura për ne - energjia. Hackathon u mbajt online: na u dha një përshkrim i detyrës dhe një muaj për ta përfunduar atë. Organizatorët donin të shihnin një projekt të përfunduar që do të ndihmonte në rritjen e efikasitetit energjetik të shtëpive në Amsterdam.
Ne bëmë një projekt në të cilin parashikohej konsumi i energjisë elektrike (para kësaj, unë mora pjesë në një konkurs me këtë temë ku mora një zgjidhje pothuajse sota, për të cilën mund të lexoni ) dhe gjenerimi me panel diellor. Bazuar në këto parashikime, performanca e baterisë është optimizuar (kjo ide është marrë pjesërisht nga teza ime e masterit). Projekti ynë ishte në përputhje të mirë si me udhëzimet e organizatorëve (siç na dukej atëherë), ashtu edhe me politikën e administratës së Amsterdamit në fushën e burimeve të rinovueshme të energjisë për disa vitet e ardhshme.
Gjatë vlerësimit të projekteve, ne, si shumë ekipe, na u tha se kjo nuk ishte ajo që priste klienti, duke shtuar se ne duhej ta ribënim projektin nëse donim të konkurronim për çmimin. Nuk bëmë asgjë, duke pranuar humbjen. Nga dyzet skuadrat pjesëmarrëse, ne nuk arritëm as në top 7, megjithëse zgjedhja e organizatorëve, më duket, ishte mjaft e çuditshme. Për shembull, ata e lanë ekipin të kalonte në finale që bëri një aplikacion për llogaritjen e shpejtësisë së erës dhe rrezatimit diellor (SI) duke përdorur të dhëna nga sensorët e smartfonëve: një mikrofon për erën, një sensor drite për SI. Tipari vrasës ishte klasifikimi hotdog/jo hotdog në tre klasa: dielli, era, uji dhe shfaqja e artikullit përkatës në Wikipedia ().
Le të lëmë për një moment anën morale të çështjes: shantazhi i pjesëmarrësve me mundësinë e fitores është thjesht joetik. Meqenëse një nga motivimet për të marrë pjesë në hackathons (veçanërisht zhvilluesit me përvojë) është të realizojnë idetë e tyre, shumë pjesëmarrës të fortë thjesht mund të largohen nga ngjarja pasi të kenë dëgjuar reagime të tilla (që i ndodhi jo vetëm ekipit tonë, por edhe një numri të tjerëve që ndaluan përditësimin e projektit të faqes së tyre pasi të keni dëgjuar mentorin). Prapëseprapë, le të themi se u pajtuam me dëshirat e organizatorëve dhe rindërtuam projektin tonë për t'iu përshtatur kërkesave të tyre. Çfarë mund të ndodhë më pas?
Meqenëse organizatorët kanë kuptimin e tyre për "projektin ideal", të gjitha dëshirat (dhe, në përputhje me rrethanat, ndryshimet) do të na çojnë drejt këtij ideali. Konkurrentët do të humbasin kohën e tyre dhe do të jetë gjithnjë e më e vështirë për ta të refuzojnë pjesëmarrjen e mëtejshme (pasi ata tashmë kanë investuar përpjekjet e tyre dhe duket se janë pak larg fitores). Por në realitet, konkurrenca për çmime do të rritet dhe pjesëmarrësit gjithnjë e më shumë do të duhet të ripërtërijnë projektin bazuar në modifikimet nga organizatorët me shpresën për të fituar një çmim. Si rezultat, djemtë që nuk morën çmime, duke parë prapa, do të kuptojnë se ata morën pjesë në punë të pavarur pa para: ata bënë modifikime për klientin, por nuk morën asgjë në këmbim për këtë (përveç përvojës përkatëse, të kurs).
Morali
Shpesh urimet dhe reagimet nga organizatorët i vijnë në ndihmë projektit. Në të njëjtën kohë, megjithatë, pjesëmarrësit nuk duhet të mbështeten në këshillat e mentorëve si një i çalë mbi një kallam. Nëse dëgjoni reagime nga organizatorët për projektin tuaj në frymën e "heqeni, ne nuk e porositëm këtë", pjesëmarrja juaj në hackathon mund të konsiderohet e përfunduar.
Nëse po organizoni një hackathon me një vizion të qartë për projektin, por pa aftësi ose aftësi për ta zbatuar vetë, atëherë është më mirë të zyrtarizoni vizionin tuaj në formën e specifikimeve teknike për një profesionist të pavarur. Përndryshe, do të duhet të paguani dy herë - për hackathon dhe për shërbimet e profesionistit të pavarur.
Burimi: www.habr.com