В Mi rigardis plurajn kialojn por partopreni en hakatonoj. La instigo lerni multajn novajn aferojn kaj gajni valorajn premiojn allogas multajn, sed ofte, pro eraroj de la organizantoj aŭ sponsorantaj kompanioj, la aranĝo finiĝas malsukcese kaj la partoprenantoj foriras malkontentaj. Por ke tiaj malagrablaj okazaĵoj okazu malpli ofte, mi skribis ĉi tiun afiŝon. La dua parto de la trilogio estas dediĉita al la eraroj de la organizantoj.
La afiŝo estas organizita jene: komence mi parolas pri la evento, klarigas kio misfunkciis kaj al kio ĝi kondukis (aŭ povas konduki longtempe). Poste mi donas mian takson pri tio, kio okazas, kaj kion mi farus se mi estus la organizantoj. Ĉar mi partoprenis ĉiujn aranĝojn, mi povas nur supozi la veran motivadon de la organizantoj. Rezulte, mia takso povas esti unuflanka. Mi ne ekskludas, ke iuj punktoj, kiuj ŝajnas al mi eraraj, estis fakte celitaj tiel.
Je certa punkto, la leganto povas pensi, ke la aŭtoro decidis svingi la pugnojn post batalo. Sed mi povas certigi vin, ke tio ne estas la kazo. En kelkaj el la listigitaj hakatonoj mi sukcesis preni premion, kio tamen ne malhelpas nin diri, ke la aranĝo estis malbone organizita.
Pro respekto al la organizantoj kaj partoprenantoj, ne estos referencoj al specifaj kompanioj en la afiŝo. Atenta leganto tamen povas diveni (aŭ Guglo) pri kiu ni parolas.
Hackathon n-ro 1. Striktaj kadroj
Antaŭ ses monatoj, unu granda teleentrepreno organizis hakatonon pri datuma analizo. 20 teamoj konkuris pri la premiofonduso. Ĉe la evento, datumaro estis disponigita por analizo, kiu enhavis informojn pri alvokoj al la subtena servo de la firmao, agado en sociaj retoj kaj kodigitaj informoj pri uzantoj (sekso, aĝo, ktp.). La plej interesa parto de la datumaro—uzantmesaĝoj kaj operaciistrespondoj (tekstaj datumoj)—estis sufiĉe brua kaj bezonis esti purigita por plua laboro.
La organizantoj starigis taskon - fari ion interesan per la provizitaj datumoj, kaj estis malpermesite uzi pliajn malfermitajn datumarojn de la reto aŭ analizi la datumojn mem. Estis ankaŭ malpermesite proponi ideojn ne rilatajn al la datumaro. Bedaŭrinde, la donitaj datumoj estis sufiĉe "malbonaj": estis malfacile akiri interesajn produktojn de ili, kaj de komunikado kun mentoroj evidentiĝis, ke multaj el la proponitaj ideoj jam estas efektivigitaj (aŭ estos efektivigitaj en proksima estonteco) en la kompanio.
Kiel rezulto, la superforta nombro da teamoj (15 el 20) faris babilrotojn. Dum la prezentoj, la decido de unu teamo estis malmulte diferenca de la antaŭa. Ne povante elteni tion, unu el la ĵurianoj demandis la sekvan teamon sur la scenejon: "Kion, uloj, ĉu vi ankaŭ havas babilejon?" Kiel rezulto, el tri premioj, la unua kaj dua lokoj iris al la teamoj kiuj ne faris babilbots.
Por komparo, ni prenu hakatonon organizitan de internacia konsulta kompanio por la kompanio Zvezdochka antaŭ du jaroj. Ĉar la specifaĵoj de la agadoj de la kompanio Zvezdochka estis nekonataj al multaj partoprenantoj de hackathon, komence de la evento la organizantoj parolis pri la metrikoj uzataj en la kompanio. Post tio, ses datumseroj de malsamaj tipoj estis disponigitaj: teksto, tabeloj, geolokigo - estis loko por manovro por ĉiuj partoprenantoj. La organizantoj ne malpermesis la uzon de pliaj datumaroj kaj eĉ subtenis tiajn iniciatojn. En la finalo de la konkurso, dek teamoj kun malsamaj solvoj konkuris por la ĉefa premio, kun ĉiuj teamoj utiligante datumojn disponigitajn de la firmao (malgraŭ la manko de restriktoj), kiuj indikis bonan potencialon por akirado de kvalitaj produktoj.
Moralo
Ne necesas limigi la krean fluon de partoprenantoj. Kiel la organizanto, vi devas provizi materialojn kaj fidi ilian vizion kaj profesiismon. Se vi partoprenas en hakatono, iuj limigoj aŭ malpermesoj devas alarmi vin. Kutime ĉi tio estas pruvo de malbona organizo (ekzemplo el la reala vivo estas la konstanta deziro ie alglui barilon). Se vi renkontas limigojn, tiam estu preta por la fakto, ke vi devos krei projekton en naĝejo kun multe da konkurenco. En ĉi tiu kazo, vi estas devigata riski: fari ion fundamente novan aŭ proponi nekutiman "mortigan funkcion" por elstari el la fluo de monotonaj projektoj.
Hackatono n-ro 2. Neeblaj taskoj
La hakatono en Amador promesis esti interesa. La sponsoranta firmao, granda telefonfabrikisto, komencis preparojn 4 monatojn antaŭ la dato de la evento. PR por la evento estis farita en sociaj retoj; eblaj partoprenantoj devis pasigi teknikan teston kaj skribi pri siaj pasintaj projektoj por esti elektitaj por ĉi tiu evento. La premiofonduso estis agrable granda. Kelkajn tagojn antaŭ la hakatono, la mentoroj okazigis teknikan sesion, por ke la partoprenantoj havu tempon kompreni la specifaĵojn de la industrio.
Ĉe la evento mem, la organizantoj disponigis datumaron de ekipaĵaj protokoloj kun volumeno de 8 GB, la tasko estis binara klasifiko de paneoj. Ili parolis pri la kriterioj por taksi projektojn - kvalito de klasifiko, kreivo en kreado de funkcioj, kapablo labori en teamo ktp. Estas nur malbonŝanco - por 8 GB de "trajtoj", estis nur 20 ekzemploj en la trajno kaj 5 en la testo. La fina najlo en la ĉerko de la hakatono venis de la datumoj: la ekipaĵprotokoloj ricevitaj merkrede enhavis eraron en la funkciado de la ekipaĵo, sed tiuj kreitaj ĵaŭde ne faris (cetere, nur du teamoj sciis pri tio, kaj ambaŭ estis el Rusio, la patrujo de spertaj datumministoj). Kvankam eĉ scio pri la veraj etikedoj de la testo ne helpis determini la respondon - la tasko estis nesolvebla. La organizantoj ne ricevis la deziratan rezulton; la partoprenantoj pasigis multe da tempo solvante malbone desegnitan problemon. La hakatono estis fiasko.
Moralo
Faru teknikajn recenzojn de taskoj kaj kontrolu viajn taskojn por taŭgeco. Pli bone estas tropagi por antaŭ-ekzameno (en ĉi tiu kazo, iu ajn datuma sciencisto tuj atentigus, ke estas neeble solvi ĉi tiun problemon) ol bedaŭri ĝin poste.
En ĉi tiu kazo, krom malŝparita tempo kaj mono, la kompanio perdis kredindecon kun eblaj kandidatoj kaj eble skribis pri la rezultoj. Cetere, ne nur la partoprenantoj, sed ankaŭ la kompanio devus skribi pri sukcesaj rezultoj, maksimumigante la hakatonon de PR-perspektivo. Bedaŭrinde, ne ĉiuj kompanioj faras tion, limigante sin al nur anonca afiŝo kaj kelkaj fotoj de la evento en Twitter.
Hackathon n-ro 3. Prenu aŭ lasu ĝin
Plej lastatempe, nia teamo partoprenis en hakatono en Amsterdamo. Ĉar mi estas elektra inĝeniero per trejnado (en la kampo de renoviĝantaj energifontoj), la temo estis ĝuste por ni - energio. La hakatono okazis interrete: ni ricevis priskribon de la tasko kaj monaton por plenumi ĝin. La organizantoj volis vidi finitan projekton, kiu helpus pliigi la energian efikecon de Amsterdamaj domoj.
Ni faris projekton en kiu estis antaŭvidita elektrokonsumo (antaŭ tio, mi partoprenis konkurson pri ĉi tiu temo, kie mi ricevis preskaŭ-sotan solvon, pri kiu vi povas legi ) kaj generacio per sunpanelo. Surbaze de ĉi tiuj antaŭdiroj, bateria rendimento estas optimumigita (ĉi tiu ideo estis parte prenita de mia majstra tezo). Nia projekto estis bona akorda kaj kun la instrukcioj de la organizantoj (kiel tiam ŝajnis al ni), kaj kun la politiko de la Amsterdama administracio en la kampo de renoviĝantaj energifontoj dum kelkaj jaroj.
Dum la taksado de projektoj, ni, kiel multaj teamoj, estis rakontitaj, ke tio ne estas tio, kion la kliento atendas, aldonante, ke ni devas refari la projekton se ni volas konkuri por la premio. Ni nenion refaris, akceptante malvenkon. El la kvardek partoprenantaj teamoj, ni eĉ ne atingis la suprajn 7, kvankam la elekto de la organizantoj, ŝajnas al mi, estis sufiĉe stranga. Ekzemple, ili lasis la teamon tra la finalo kiu faris aplikon por kalkulado de ventorapideco kaj suna radiado (SI) uzante datenojn de saĝtelefonsensiloj: mikrofono por la vento, lumsensilo por la SI. La mortiga trajto estis la hotdog/ne hotdog-klasifiko en tri klasojn: Suno, vento, akvo kaj montrado de la ekvivalenta artikolo en Vikipedio ().
Ni lasu por momento la moralan flankon de la afero: ĉantaĝi partoprenantojn kun ebleco de venko estas simple maletika. Ĉar unu el la instigoj por partopreni en hakatonoj (precipe spertaj programistoj) estas realigi siajn ideojn, multaj fortaj partoprenantoj povas simple forlasi la eventon aŭdinte tiajn rimarkojn (kio okazis ne nur al nia teamo, sed ankaŭ al kelkaj aliaj, kiuj ĉesis). ĝisdatigante sian paĝprojekton post aŭskultado de la mentoro). Tamen, ni diru, ke ni konsentis kun la deziroj de la organizantoj kaj refaris nian projekton laŭ iliaj postuloj. Kio povus okazi poste?
Ĉar la organizantoj havas propran komprenon pri la "ideala projekto", ĉiuj deziroj (kaj, sekve, ŝanĝoj) kondukos nin al ĉi tiu idealo. La konkurantoj malŝparos sian tempon kaj estos pli kaj pli malfacile por ili rifuzi pluan partoprenon (ĉar ili jam investis siajn klopodojn, kaj ŝajnas, ke ili estas nur iomete for de venko). Sed fakte, konkurenco por premioj pliiĝos, kaj partoprenantoj ĉiam pli devos refari la projekton surbaze de redaktoj de la organizantoj kun la espero gajni premion. Rezulte, la uloj, kiuj ne prenis premiojn, retrorigardante, komprenos, ke ili partoprenis en liberlaborado sen mono: ili faris redaktojn por la kliento, sed nenion ricevis kontraŭ tio (krom la koncerna sperto, de kompreneble).
Moralo
Ofte deziroj kaj rimarkoj de la organizantoj venas al la helpo de la projekto. Samtempe, tamen, partoprenantoj ne fidi al la konsilo de mentoroj kiel lamulo sur bastono. Se vi aŭdas komentojn de la organizantoj pri via projekto en la spirito de "forprenu ĝin, ni ne mendis ĉi tion", via partopreno en la hakatono povas esti konsiderata finita.
Se vi organizas hakatonon kun klara vizio por la projekto, sed sen la kapabloj aŭ kapablo efektivigi ĝin mem, tiam estas pli bone formaligi vian vizion en la formo de teknikaj specifoj por sendependa dungito. Alie, vi devos pagi dufoje - por la hakatono kaj por la servoj de la sendependa dungito.
fonto: www.habr.com