В Ek het na verskeie redes gekyk om aan hackathons deel te neem. Die motivering om baie nuwe dinge te leer en waardevolle pryse te wen lok baie, maar dikwels, weens foute deur die organiseerders of borgmaatskappye, eindig die geleentheid onsuksesvol en die deelnemers vertrek ontevrede. Om sulke onaangename insidente minder gereeld te laat gebeur, het ek hierdie pos geskryf. Die tweede deel van die trilogie word gewy aan die foute van die organiseerders.
Die pos is soos volg georganiseer: aan die begin praat ek oor die gebeurtenis, verduidelik wat verkeerd geloop het en waartoe dit gelei het (of tot op die lang termyn kan lei). Dan gee ek my beoordeling van wat gebeur, en wat ek sou doen as ek die organiseerders was. Aangesien ek aan al die byeenkomste deelgeneem het, kan ek net die ware motivering van die organiseerders aanvaar. Gevolglik kan my beoordeling eensydig wees. Ek sluit nie uit dat sommige punte wat vir my foutief lyk, in werklikheid so bedoel was nie.
Op 'n sekere punt kan die leser dink dat die skrywer besluit het om sy vuiste te waai na 'n bakleiery. Maar ek kan jou verseker dat dit nie die geval is nie. In sommige van die gelyste hackathons het ek daarin geslaag om 'n prys te wen, wat ons egter nie verhinder om te sê die geleentheid was swak georganiseer nie.
Uit respek vir die organiseerders en deelnemers sal daar geen verwysings na spesifieke maatskappye in die pos wees nie. ’n Oplettende leser kan egter raai (of Google) van wie ons praat.
Hackathon No 1. Streng perke
Ses maande gelede het een groot telekommunikasiemaatskappy 'n hackathon oor data-analise gereël. 20 spanne het om die prysfonds meegeding. By die geleentheid is 'n datastel vir ontleding verskaf, wat inligting bevat het oor oproepe na die maatskappy se ondersteuningsdiens, aktiwiteit op sosiale netwerke en gekodeerde inligting oor gebruikers (geslag, ouderdom, ens.). Die interessantste deel van die datastel—gebruikersboodskappe en operateurantwoorde (teksdata)—was nogal raserig en moes skoongemaak word vir verdere werk.
Die organiseerders het 'n taak gestel - om iets interessants te doen met die verskafde data, en dit was verbode om addisionele oop datastelle van die netwerk te gebruik of die data self te ontleed. Dit was ook verbied om idees voor te stel wat nie met die datastel verband hou nie. Ongelukkig was die data wat verskaf is taamlik "swak": dit was moeilik om enige interessante produkte van hulle te verkry, en uit kommunikasie met mentors het dit duidelik geword dat baie van die voorgestelde idees reeds geïmplementeer word (of in die nabye toekoms geïmplementeer sal word). in die maatskappy.
Gevolglik het die oorweldigende aantal spanne (15 uit 20) chatbots gemaak. Tydens die vertonings was die besluit van een span min verskil van die vorige een. Nie in staat om dit te verduur nie, vra een van die jurielede die volgende span wat op die verhoog klim: "Wat, ouens, het julle ook 'n chatbot?" Gevolglik het die eerste en tweede plekke uit drie pryse gegaan aan die spanne wat nie chatbots gemaak het nie.
Ter vergelyking, kom ons neem 'n hackathon wat twee jaar gelede deur 'n internasionale konsultasiemaatskappy vir die Zvezdochka-maatskappy gereël is. Aangesien die besonderhede van die Zvezdochka-maatskappy se aktiwiteite vir baie hackathon-deelnemers onbekend was, het die organiseerders aan die begin van die geleentheid gepraat oor die maatstawwe wat in die maatskappy gebruik word. Hierna is ses datastelle van verskillende tipes verskaf: teks, tabelle, geoligging – daar was beweegruimte vir alle deelnemers. Die organiseerders het nie die gebruik van bykomende datastelle verbied nie en selfs sulke inisiatiewe ondersteun. In die eindronde van die kompetisie het tien spanne met verskillende oplossings om die hoofprys meegeding, met alle spanne wat data gebruik het wat deur die maatskappy verskaf is (ten spyte van die gebrek aan beperkings), wat gedui het op goeie potensiaal om kwaliteit produkte te bekom.
Moraliteit
Dit is nie nodig om die kreatiewe vloei van deelnemers te beperk nie. As die organiseerder moet jy materiaal verskaf en hul visie en professionaliteit vertrou. As jy 'n deelnemer aan 'n hackathon is, behoort enige beperkings of verbods jou alarm te maak. Gewoonlik is dit 'n bewys van swak organisasie ('n voorbeeld uit die werklike lewe is die voortdurende begeerte om iewers 'n heining te plak). As jy wel beperkings teëkom, wees dan voorbereid daarop dat jy 'n projek in 'n swembad met baie mededinging sal moet skep. In hierdie geval moet u risiko's neem: doen iets fundamenteel nuuts of bied 'n ongewone "moordenaar-funksie" om uit die stroom eentonige projekte te staan.
Hackathon nr. 2. Onmoontlike take
Die hackathon in Amador het beloof om interessant te wees. Die borgmaatskappy, 'n groot telefoonvervaardiger, het 4 maande voor die datum van die geleentheid met voorbereidings begin. PR vir die geleentheid is op sosiale netwerke uitgevoer; potensiële deelnemers moes 'n tegniese toets slaag en skryf oor hul vorige projekte om vir hierdie geleentheid gekies te word. Die prysfonds was aangenaam groot. ’n Paar dae voor die hackathon het die mentors ’n tegniese sessie gehou sodat die deelnemers tyd gehad het om die besonderhede van die bedryf te verstaan.
By die geleentheid self het die organiseerders 'n datastel van toerustinglogboeke met 'n volume van 8 GB verskaf, die taak was 'n binêre klassifikasie van onklaarrakings. Hulle het gepraat oor die kriteria vir die evaluering van projekte - kwaliteit van klassifikasie, kreatiwiteit in die skep van kenmerke, vermoë om in 'n span te werk, ens. Dit is net slegte geluk - vir 8 GB se "kenmerke" was daar net 20 voorbeelde in die trein en 5 in die toets. Die laaste spyker in die kis van die hackathon kom uit die data: die toerustinglogboeke wat Woensdag ontvang is, bevat 'n fout in die werking van die toerusting, maar dié wat Donderdag geskep is, het nie (terloops, net twee spanne het hiervan geweet, en albei was van Rusland, die tuisland van ervare data-myners). Alhoewel selfs kennis van die ware etikette van die toets nie gehelp het om die antwoord te bepaal nie - was die taak onoplosbaar. Die organiseerders het nie die gewenste resultaat gekry nie; die deelnemers het baie tyd spandeer om 'n swak ontwerpte probleem op te los. Die hackathon was 'n mislukking.
Moraliteit
Voer tegniese hersiening van werkopdragte uit en kontroleer jou werkopdragte vir toereikendheid. Dit is beter om te veel te betaal vir 'n voorlopige ondersoek (in hierdie geval sal enige datawetenskaplike dadelik daarop wys dat dit onmoontlik is om hierdie probleem op te los) as om later spyt te wees.
In hierdie geval het die maatskappy, benewens tyd en geld gemors, geloofwaardigheid verloor met potensiële kandidate en moontlik oor die resultate geskryf. Terloops, nie net die deelnemers nie, maar ook die maatskappy moet oor suksesvolle resultate skryf en die hackathon uit 'n PR-oogpunt maksimeer. Ongelukkig doen nie alle maatskappye dit nie, en beperk hulle tot slegs 'n aankondigingsplasing en 'n paar foto's van die geleentheid op Twitter.
Hackathon nr. 3. Vat dit of los dit
Onlangs het ons span aan 'n hackathon in Amsterdam deelgeneem. Aangesien ek 'n elektriese ingenieur van opleiding is (op die gebied van hernubare energiebronne), was die onderwerp net reg vir ons - energie. Die hackathon is aanlyn gehou: ons het 'n beskrywing van die taak gekry en 'n maand om dit te voltooi. Die organiseerders wou 'n voltooide projek sien wat sal help om die energiedoeltreffendheid van Amsterdamse huise te verhoog.
Ons het 'n projek gemaak waarin elektrisiteitsverbruik voorspel is (voor dit het ek aan 'n kompetisie oor hierdie onderwerp deelgeneem waar ek 'n naby-sota-oplossing ontvang het, waaroor u kan lees ) en opwekking deur sonpaneel. Gebaseer op hierdie voorspellings, word batterywerkverrigting geoptimaliseer (hierdie idee is gedeeltelik uit my magistertesis geneem). Ons projek was in goeie ooreenstemming sowel met die instruksies van die organiseerders (soos dit toe vir ons gelyk het), en met die beleid van die Amsterdamse administrasie op die gebied van hernubare energiebronne vir etlike jare wat kom.
Tydens die evaluering van projekte is ons, soos baie spanne, meegedeel dat dit nie is wat die kliënt verwag het nie, en bygevoeg dat ons die projek moet oordoen as ons vir die prys wil meeding. Ons het niks oorgedoen nie en die nederlaag aanvaar. Van die veertig deelnemende spanne het ons nie eers die top 7 gehaal nie, hoewel die keuse van die organiseerders, lyk dit my, nogal vreemd was. Hulle het byvoorbeeld die span deurgelaat na die eindronde wat 'n toepassing gemaak het vir die berekening van windspoed en sonstraling (SI) met behulp van data van slimfoonsensors: 'n mikrofoon vir die wind, 'n ligsensor vir die SI. Die moordende kenmerk was die worsbroodjie/nie-worsbroodjie-klassifikasie in drie klasse: Son, wind, water en vertoon van die ooreenstemmende artikel op Wikipedia ().
Kom ons los die morele kant van die saak vir ’n oomblik: om deelnemers af te pers met die moontlikheid van oorwinning is eenvoudig oneties. Aangesien een van die motiverings vir deelname aan hackathons (veral ervare ontwikkelaars) is om hul idees te verwesenlik, kan baie sterk deelnemers die geleentheid eenvoudig verlaat nadat hulle sulke terugvoer gehoor het (wat nie net met ons span gebeur het nie, maar ook met 'n aantal ander wat opgehou het hul bladsyprojek op te dateer nadat hulle na die mentor geluister het). Tog, kom ons sê ons het saamgestem met die wense van die organiseerders en ons projek hervorm om aan hul vereistes te voldoen. Wat kan volgende gebeur?
Aangesien die organiseerders hul eie begrip van die "ideale projek" het, sal alle wense (en gevolglik veranderinge) ons na hierdie ideaal lei. Die mededingers sal hul tyd mors en dit sal vir hulle al hoe moeiliker wees om verdere deelname te weier (aangesien hulle reeds hul pogings belê het, en dit blyk dat hulle net 'n bietjie weg is om te wen). Maar in werklikheid sal mededinging om pryse toeneem, en deelnemers sal toenemend die projek moet oordoen op grond van wysigings van die organiseerders in die hoop om 'n prys te wen. As gevolg hiervan sal die ouens wat nie pryse ontvang het nie, as hulle terugkyk, verstaan dat hulle sonder geld aan vryskut deelgeneem het: hulle het wysigings vir die kliënt gemaak, maar niks daarvoor ontvang nie (behalwe vir die relevante ervaring, van kursus).
Moraliteit
Dikwels kom wense en terugvoer van die organiseerders die projek te hulp. Terselfdertyd moet deelnemers egter nie op die raad van mentors staatmaak soos 'n lam man op 'n kierie nie. As jy terugvoer van die organiseerders oor jou projek hoor in die gees van "neem dit weg, ons het dit nie bestel nie", kan jou deelname aan die hackathon as voltooi beskou word.
As jy 'n hackathon organiseer met 'n duidelike visie vir die projek, maar sonder die vaardighede of vermoë om dit self te implementeer, dan is dit beter om jou visie te formaliseer in die vorm van tegniese spesifikasies vir 'n vryskut. Andersins sal jy twee keer moet betaal – vir die hackathon en vir die vryskutdienste.
Bron: will.com