В He mirat diverses raons per participar en hackatons. La motivació per aprendre moltes coses noves i guanyar premis valuosos atrau molts, però sovint, a causa d'errors dels organitzadors o empreses patrocinadores, l'esdeveniment acaba sense èxit i els participants marxen insatisfets. Per fer que incidents tan desagradables succeeixin amb menys freqüència, he escrit aquesta publicació. La segona part de la trilogia està dedicada als errors dels organitzadors.
El post s'organitza de la següent manera: al principi parlo de l'esdeveniment, explico què ha fallat i què ha portat (o pot comportar a la llarga). Després faig la meva valoració del que està passant i què faria si jo fos els organitzadors. Com que vaig participar en tots els esdeveniments, només puc assumir la veritable motivació dels organitzadors. Com a resultat, la meva valoració pot ser unilateral. No exclou que alguns punts que em semblen errònies estiguessin, de fet, pensats així.
En un moment determinat, el lector pot pensar que l'autor va decidir agitar els punys després d'una baralla. Però us puc assegurar que no és així. En alguns dels hackatons enumerats, vaig aconseguir endur-me un premi, la qual cosa, però, no impedeix dir que l'esdeveniment estava mal organitzat.
Per respecte als organitzadors i participants, no hi haurà referències a empreses concretes a la publicació. Un lector atent, però, pot endevinar (o Google) de qui estem parlant.
Hackathon núm. 1. Límits estrictes
Fa sis mesos, una gran empresa de telecomunicacions va organitzar un hackathon sobre anàlisi de dades. 20 equips van competir pel fons del premi. A l'acte es va facilitar per a l'anàlisi un conjunt de dades que contenia informació sobre trucades al servei d'assistència de l'empresa, activitat a les xarxes socials i informació codificada dels usuaris (sexe, edat, etc.). La part més interessant del conjunt de dades (missatges d'usuari i respostes de l'operador (dades de text)) era bastant sorollosa i s'havia de netejar per seguir treballant.
Els organitzadors van establir una tasca: fer alguna cosa interessant amb les dades proporcionades, i estava prohibit utilitzar conjunts de dades oberts addicionals de la xarxa o analitzar les dades vosaltres mateixos. També estava prohibit proposar idees no relacionades amb el conjunt de dades. Malauradament, les dades proporcionades eren bastant "pobres": era difícil obtenir-ne cap producte interessant i, a partir de la comunicació amb els mentors, va quedar clar que moltes de les idees proposades ja s'estan implementant (o s'implementaran en un futur proper). a l'empresa.
Com a resultat, el gran nombre d'equips (15 de 20) van crear chatbots. Durant les actuacions, la decisió d'un equip va ser poc diferent de l'anterior. Incapaç de suportar-ho, un dels membres del jurat va preguntar al següent equip que pujava a l'escenari: "Què, nois, també teniu un chatbot?" Com a resultat, de tres premis, el primer i segon lloc van ser per als equips que no feien chatbots.
Per comparar, anem a fer un hackathon organitzat per una empresa de consultoria internacional per a l'empresa Zvezdochka fa dos anys. Com que les especificitats de les activitats de l'empresa Zvezdochka eren desconegudes per a molts participants del hackathon, a l'inici de l'esdeveniment els organitzadors van parlar sobre les mètriques que s'utilitzen a l'empresa. Després d'això, es van proporcionar sis conjunts de dades de diferents tipus: text, taules, geolocalització: hi havia marge de maniobra per a tots els participants. Els organitzadors no van prohibir l'ús de conjunts de dades addicionals i fins i tot van donar suport a aquestes iniciatives. A les finals del concurs, deu equips amb diferents solucions van competir pel premi principal, tots els equips utilitzant dades facilitades per l'empresa (malgrat la manca de restriccions), que indicaven un bon potencial per obtenir productes de qualitat.
Moralitat
No cal limitar el flux creatiu dels participants. Com a organitzador, heu de proporcionar materials i confiar en la seva visió i professionalitat. Si participeu en un hackathon, qualsevol restricció o prohibició us hauria d'alarmar. En general, això és una prova d'una mala organització (un exemple de la vida real és el desig constant d'enganxar una tanca en algun lloc). Si trobeu restriccions, estigueu preparats per al fet que haureu de crear un projecte en una piscina amb molta competència. En aquest cas, esteu obligats a córrer riscos: fer alguna cosa fonamentalment nova o oferir una "funció assassina" inusual per tal de destacar del corrent de projectes monòtons.
Hackathon núm. 2. Tasques impossibles
El hackathon d'Amador prometia ser interessant. L'empresa patrocinadora, un gran fabricant de telèfons, va començar els preparatius 4 mesos abans de la data de l'esdeveniment. Les relacions públiques de l'esdeveniment es van dur a terme a les xarxes socials; els participants potencials van haver de superar una prova tècnica i escriure sobre els seus projectes passats per ser seleccionats per a aquest esdeveniment. El fons de premis era agradablement gran. Uns dies abans de l'hackathon, els mentors van realitzar una sessió tècnica perquè els participants tinguessin temps d'entendre les especificitats de la indústria.
A l'esdeveniment en si, els organitzadors van proporcionar un conjunt de dades de registres d'equips amb un volum de 8 GB, la tasca era una classificació binària de les avaries. Han parlat dels criteris d'avaluació dels projectes: qualitat de la classificació, creativitat en la creació de característiques, capacitat de treballar en equip, etc. Només és mala sort: per a 8 GB de "funcions", només hi havia 20 exemples al tren i 5 a la prova. El clau final del taüt de l'hackathon va venir de les dades: els registres de l'equip rebut dimecres contenien un error en el funcionament de l'equip, però els creats dijous no (per cert, només dos equips ho sabien, i tots dos eren de Rússia, la pàtria dels miners de dades experimentats). Tot i que fins i tot el coneixement de les veritables etiquetes de la prova no va ajudar a determinar la resposta, la tasca era insoluble. Els organitzadors no van obtenir el resultat desitjat; els participants van dedicar molt de temps a resoldre un problema mal dissenyat. El hackathon va ser un fracàs.
Moralitat
Realitzeu revisions tècniques de les tasques i comproveu la seva adequació. És millor pagar en excés per un examen preliminar (en aquest cas, qualsevol científic de dades assenyalaria immediatament que és impossible resoldre aquest problema) que lamentar-ho més tard.
En aquest cas, a més de perdre temps i diners, l'empresa va perdre credibilitat amb els possibles candidats i possiblement va escriure sobre els resultats. Per cert, no només els participants, sinó també l'empresa han d'escriure sobre els resultats d'èxit, maximitzant l'hackathon des del punt de vista de les relacions públiques. Malauradament, no totes les empreses ho fan, limitant-se només a una publicació d'anunci i un parell de fotos de l'esdeveniment a Twitter.
Hackathon núm. 3. Agafa-ho o deixa-ho
Més recentment, el nostre equip va participar en un hackathon a Amsterdam. Com que sóc enginyer elèctric de formació (en l'àmbit de les fonts d'energia renovables), el tema era adequat per a nosaltres: l'energia. El hackathon es va fer en línia: ens van donar una descripció de la tasca i un mes per completar-la. Els organitzadors volien veure un projecte acabat que ajudés a augmentar l'eficiència energètica de les cases d'Amsterdam.
Vam fer un projecte en el qual es preveia el consum d'electricitat (abans vaig participar en un concurs sobre aquest tema on vaig rebre una solució quasi sota, de la qual podeu llegir ) i generació per panell solar. A partir d'aquestes prediccions, s'optimitza el rendiment de la bateria (aquesta idea es va extreure en part del meu treball de fi de màster). El nostre projecte estava molt d'acord tant amb les instruccions dels organitzadors (tal com ens semblava aleshores), com amb la política de l'administració d'Amsterdam en l'àmbit de les energies renovables durant diversos anys.
Durant l'avaluació dels projectes, a nosaltres, com a molts equips, se'ns va dir que això no era el que esperava el client, afegint que havíem de refer el projecte si volíem competir pel premi. No vam refer res, acceptant la derrota. De quaranta equips participants, ni tan sols vam arribar als 7 primers, tot i que l'elecció dels organitzadors, em sembla, va ser força estranya. Per exemple, van permetre a l'equip passar a la final que va crear una aplicació per calcular la velocitat del vent i la radiació solar (SI) utilitzant dades dels sensors dels telèfons intel·ligents: un micròfon per al vent, un sensor de llum per al SI. La característica assassina va ser la classificació hotdog/no hotdog en tres classes: Sol, vent, aigua i visualització de l'article corresponent a la Viquipèdia ().
Deixem per un moment l'aspecte moral del tema: fer xantatge als participants amb la possibilitat de la victòria és simplement poc ètic. Atès que una de les motivacions per participar en hackathons (especialment desenvolupadors experimentats) és fer realitat les seves idees, molts participants forts simplement poden abandonar l'esdeveniment després d'escoltar aquests comentaris (que no només va passar al nostre equip, sinó també a un nombre d'altres que es van aturar). actualitzant el seu projecte de pàgina després d'escoltar el mentor). Tot i així, diguem que vam estar d'acord amb els desitjos dels organitzadors i vam refer el nostre projecte segons les seves necessitats. Què podria passar després?
Com que els organitzadors tenen la seva pròpia comprensió del "projecte ideal", tots els desitjos (i, en conseqüència, els canvis) ens portaran cap a aquest ideal. Els competidors perdran el seu temps i cada cop els costarà més rebutjar la participació (ja que ja han invertit els seus esforços, i sembla que estan una mica lluny de guanyar). Però en realitat, la competència per als premis augmentarà, i els participants hauran de refer cada cop més el projecte a partir de les edicions dels organitzadors amb l'esperança de guanyar un premi. Com a resultat, els nois que no van guanyar premis, mirant enrere, entendran que van participar en autònoms sense diners: van fer edicions per al client, però no van rebre res a canvi d'això (excepte l'experiència corresponent, de curs).
Moralitat
Sovint, els desitjos i comentaris dels organitzadors ajuden el projecte. Al mateix temps, però, els participants no haurien de confiar en els consells dels mentors com un coix amb un bastó. Si escolteu comentaris dels organitzadors sobre el vostre projecte amb l'esperit de "emporta't-ho, no l'hem encarregat", la teva participació a la hackathon es considerarà completada.
Si organitzeu un hackathon amb una visió clara del projecte, però sense les habilitats ni la capacitat per implementar-lo vosaltres mateixos, és millor formalitzar la vostra visió en forma d'especificacions tècniques per a un autònom. En cas contrari, haureu de pagar dues vegades: per l'hackathon i pels serveis de l'autònom.
Font: www.habr.com