В Hackathonetan parte hartzeko hainbat arrazoi aztertu ditut. Gauza berri asko ikasteko eta sari baliotsuak irabazteko motibazioa asko erakartzen du, baina askotan, antolatzaileek edo enpresa babesleek egindako akatsak direla eta, ekitaldia arrakastarik gabe amaitzen da eta parte hartzaileak pozik irteten dira. Horrelako gertakari desatseginak gutxiagotan gertatzeko, mezu hau idatzi dut. Trilogiaren bigarren zatia antolatzaileen akatsei eskainia dago.
Posta honela dago antolatuta: hasieran gertakariari buruz hitz egiten dut, zer gertatu den oker eta zer ekarri duen (edo epe luzera ekar dezakeen) azaltzen dut. Gero, nire balorazioa ematen dut gertatzen ari denaz, eta zer egingo nukeen antolatzaileak banintz. Ekitaldi guztietan parte hartu nuenez, antolatzaileen benetako motibazioa besterik ezin dut bere gain hartu. Ondorioz, nire balorazioa alde bakarrekoa izan daiteke. Ez dut baztertzen oker iruditzen zaizkidan puntu batzuk hain zuzen ere horrela pentsatuta egotea.
Une jakin batean, irakurleak pentsa dezake egileak borroka baten ostean ukabilak astintzea erabaki zuela. Baina ziurtatu dezaket ez dela horrela. Zerrendatutako hackathon batzuetan sari bat hartzea lortu nuen, eta horrek ez du eragozten ekitaldia gaizki antolatuta zegoela esatea.
Antolatzaile eta parte-hartzaileekiko errespetuagatik, postuan ez da enpresa zehatzen erreferentziarik izango. Irakurle adi batek, ordea, asma dezake (edo Googlen) nori buruz ari garen.
Hackathon 1. zk. Esparru zorrotzak
Duela sei hilabete, telekomunikazio-enpresa handi batek datuen analisiari buruzko hackathon bat antolatu zuen. 20 talde lehiatu ziren sarietarako. Ekitaldian, analisirako datu-multzo bat eskaini zen, non enpresaren laguntza-zerbitzurako deien, sare sozialetako jarduera eta erabiltzaileei buruzko informazio kodetua (generoa, adina, etab.) buruzko informazioa jasota. Datu-multzoaren zatirik interesgarriena —erabiltzaileen mezuak eta operadoreen erantzunak (testu datuak)— nahiko zaratatsua zen eta lan gehiago egiteko garbitu behar zen.
Antolatzaileek zeregin bat ezarri zuten: emandako datuekin zerbait interesgarria egitea, eta debekatuta zegoen sareko datu multzo ireki gehigarriak erabiltzea edo datuak zuk zeuk analizatzea. Halaber, debekatuta zegoen datu multzoarekin zerikusirik ez duten ideiak proposatzea. Zoritxarrez, emandako datuak nahiko “eskasak” ziren: zaila zen haiengandik produktu interesgarririk lortzea, eta tutoreekin komunikatuta argi geratu zen proposatutako ideia asko jada gauzatzen ari direla (edo etorkizun hurbilean gauzatuko direla). enpresan.
Ondorioz, talde kopuru ikaragarriak (15tik 20) chatbot-ak egin zituen. Emanaldietan, talde baten erabakia aurrekoaren aldean gutxi ezberdina izan zen. Jasan ezinik, oholtzara igotzen zen hurrengo taldeari galdetu zion epaimahaikideetako batek: «Zer, mutilak, zuek ere txatbot bat duzue?». Ondorioz, hiru sarietatik, lehen eta bigarren postuak txatbotak egiten ez zituzten taldeentzat izan ziren.
Konparazio baterako, har dezagun duela bi urte nazioarteko aholkularitza-enpresa batek Zvezdochka enpresarentzat antolatutako hackaton bat. Zvezdochka konpainiaren jardueren berezitasunak hackaton parte-hartzaile askorentzat ezezagunak zirenez, ekitaldiaren hasieran antolatzaileek enpresan erabiltzen diren neurketei buruz hitz egin zuten. Horren ostean, mota ezberdinetako sei datu-multzo eman ziren: testua, taulak, geokokapena - parte hartzaile guztientzat maniobrarako tartea zegoen. Antolatzaileek ez zuten debekatu datu-multzo osagarriak erabiltzea eta horrelako ekimenak ere onartzen zituzten. Lehiaketaren finalean, irtenbide ezberdinetako hamar talde lehiatu ziren sari nagusia lortzeko, talde guztiek enpresak emandako datuak erabiliz (murrizketarik ez izan arren), eta horrek kalitatezko produktuak lortzeko ahalmen ona adierazten zuen.
Morala
Ez dago parte-hartzaileen sormen-fluxua mugatu beharrik. Antolatzaile gisa, materialak eman behar dituzu eta haien ikuskera eta profesionaltasuna fidatu behar dituzu. Hackathon batean parte hartzen baduzu, edozein murrizketek edo debekuek kezkatu beharko zaituzte.Normalean, antolakuntza eskasaren froga da (bizitza errealeko adibide bat hesi bat nonbait itsatsi nahia da etengabe). Murrizketak aurkitzen badituzu, prest egon lehiakortasun handia duen igerileku batean proiektu bat sortu beharko duzulako. Kasu honetan, arriskuak hartzera behartuta zaude: funtsean zerbait berria egin edo ezohiko "funtzio hiltzaile" bat eskaini proiektu monotonoen korrontetik bereizteko.
Hackathon 2. zenbakia. Ezinezko zereginak
Amadorko hackatona interesgarria izango zela agindu zuen. Enpresa babeslea, telefono fabrikatzaile handi bat, ekitaldiaren data baino 4 hilabete lehenago hasi zen prestatzen. Ekitaldirako PR sare sozialetan egin zen; parte hartzaileek proba tekniko bat gainditu eta iraganeko proiektuei buruz idatzi behar izan zuten ekitaldi honetarako hautatu ahal izateko. Sari-funtsa oso handia zen. Hackatona baino egun batzuk lehenago, tutoreek saio tekniko bat egin zuten, parte hartzaileek industriaren berezitasunak ulertzeko denbora izan zezaten.
Ekitaldian bertan, antolatzaileek ekipoen erregistroen datu-multzo bat eman zuten 8 GB-ko bolumenarekin, zeregina matxuren sailkapen bitar bat zen. Proiektuak ebaluatzeko irizpideei buruz hitz egin dute –sailkapenaren kalitatea, ezaugarriak sortzeko sormena, taldean lan egiteko gaitasuna, etab. Zorte txarra besterik ez da - 8 GB-ren "ezaugarrietarako", trenean 20 adibide baino ez zeuden eta proban 5. Hackathoneko hilkutxako azken iltzea datuetatik atera zen: asteazkenean jasotako ekipoen erregistroetan akats bat zegoen ekipoaren funtzionamenduan, baina ostegunean sortutakoek ez (bide batez, bi taldek bakarrik zekiten horren berri, eta biak Errusiakoak ziren, esperientziadun data meatzarien aberria). Nahiz eta probaren benetako etiketen ezagutzak erantzuna zehazten lagundu ez zuen - zeregina konpon ezina zen. Antolatzaileek ez zuten lortu nahi zuten emaitza; parte hartzaileek denbora asko eman zuten gaizki diseinatutako arazo bat konpontzen. Hackatona porrota izan zen.
Morala
Egin lanen berrikuspen teknikoak eta egiaztatu zure lanak egokiak diren. Hobe da aurretiazko azterketa batengatik gehiegi ordaintzea (kasu honetan, edozein datu zientzialari berehala adieraziko luke arazo hau konpontzea ezinezkoa dela) geroago damutzea baino.
Kasu honetan, denbora eta dirua xahutzeaz gain, konpainiak sinesgarritasuna galdu zuen hautagai potentzialekiko eta baliteke emaitzei buruz idatzi zuen. Bide batez, parte-hartzaileek ez ezik, konpainiak ere emaitza arrakastatsuei buruz idatzi beharko lukete, hackatona PR ikuspegitik maximizatuz. Zoritxarrez, enpresa guztiek ez dute horrelakorik egiten, iragarki bat eta Twitterren ekitaldiko argazki pare batera soilik mugatuz.
Hackathon 3. zenbakia. Hartu edo utzi
Duela gutxi, gure taldeak Amsterdameko hackaton batean parte hartu zuen. Prestakuntzaz ingeniari elektrikoa naizenez (energia berriztagarrien alorrean), gaia egokia zen guretzat: energia. Hackatona sarean egin zen: zereginaren deskribapena eta hilabete bat eman ziguten burutzeko. Antolatzaileek Amsterdameko etxeen energia-eraginkortasuna areagotzen lagunduko lukeen proiektu bukatua ikusi nahi zuten.
Elektrizitate-kontsumoa aurreikusten zen proiektu bat egin genuen (aurretik, gai honi buruzko lehiaketa batean parte hartu nuen, non ia-sota irtenbide bat jaso nuen, zeina irakur dezakezue ) eta eguzki panelen bidez sortzea. Iragarpen hauetan oinarrituta, bateriaren errendimendua optimizatzen da (ideia hau, neurri batean, nire master-tesitik atera zen). Gure proiektua ados zegoen bai antolatzaileen argibideekin (orduan iruditu zitzaigun bezala), bai Amsterdameko administrazioak energia berriztagarrien alorrean hainbat urtetan izan zuen politikarekin.
Proiektuen balorazioan, talde askoren antzera, bezeroak espero zuena ez zela esan ziguten, eta gaineratu genuen proiektua berriro egin behar genuela saria lortzeko lehiatu nahi bagenuen. Ez genuen ezer berregin, porrota onartuz. Parte hartu zuten berrogei taldeetatik, 7 lehenen artean ere ez ginen sartu, nahiz eta antolatzaileen aukeraketa arraro samarra iruditu zitzaidan. Esaterako, haizearen abiadura eta eguzki-erradiazioa (SI) kalkulatzeko aplikazio bat egin zuten finalerdietara utzi zuten, smartphone-en sentsoreen datuak erabiliz: haizerako mikrofono bat, SIrako argi sentsore bat. Hiltzaileen ezaugarria hotdog/ez hotdog hiru klasetan sailkatzea izan zen: Eguzkia, haizea, ura eta dagokion artikuluaren bistaratzea Wikipedian ().
Utz dezagun une batez gaiaren alde morala: parte-hartzaileei garaipena lortzeko aukerarekin xantaia egitea etikoa besterik ez da. Hackathonetan (batez ere esperientziadun garatzaileei) parte hartzeko motibazioetako bat beren ideiak gauzatzea denez, parte hartzaile indartsu askok gertaera irten dezakete iritzi hori entzun ondoren (gure taldeari ez ezik, gelditu egin ziren beste batzuei ere gertatu zitzaiena). beren orriaren proiektua eguneratzea tutoreari entzun ondoren). Hala ere, demagun antolatzaileen nahiekin bat egin genuela eta gure proiektua berritu genuela haien eskakizunetara egokitzeko. Zer gerta liteke gero?
Antolatzaileek “proiektu idealaren” euren ulermena dutenez, nahi guztiek (eta, horren arabera, aldaketak) ideal horretara eramango gaituzte. Lehiakideek denbora alferrik galduko dute eta gero eta zailagoa izango zaie parte hartzeari uko egitea (dagoeneko ahalegina inbertitu baitute, eta badirudi irabazteko apur bat falta zaiela). Baina, egia esan, sarietarako lehia areagotu egingo da, eta parte hartzaileek gero eta gehiago egin beharko dute egitasmoa antolatzaileen edizioetan oinarrituta, sari bat irabazteko asmoz. Ondorioz, saririk hartu ez zuten mutilek, atzera begira, freelancing-ean dirurik gabe parte hartu zutela ulertuko dute: bezeroarentzako aldaketak egin zituzten, baina ez zuten ezer jaso horren truke (dagokion esperientzia izan ezik, ikastaroa).
Morala
Askotan antolatzaileen nahiak eta iritziak etortzen dira proiektuaren lagungarri. Aldi berean, dena den, parte hartzaileek ez lukete mentoreen aholkuetan oinarritu behar kanaberako gizon herren batek bezala. Antolatzaileen iritzia entzuten baduzu zure proiektuari buruz, "eraman ezazu, ez dugu hau agindu" izpirituan, hackaton parte hartzea amaitutzat jo daiteke.
Proiektuaren ikuspegi argi batekin hackathon bat antolatzen ari bazara, baina zuk zeuk ezartzeko trebetasunik edo gaitasunik gabe, hobe da zure ikuspegia formalizatzea freelance baten zehaztapen teknikoen moduan. Bestela, bi aldiz ordaindu beharko duzu: hackathonagatik eta autonomoaren zerbitzuengatik.
Iturria: www.habr.com