Dans la
partie précédente de la trilogie, j'ai examiné plusieurs raisons de participer à des hackathons. La motivation à apprendre beaucoup et à gagner des prix précieux en attire beaucoup, mais souvent à cause des erreurs des organisateurs ou des sociétés sponsors, l'événement se termine sans succès et les participants repartent insatisfaits. Pour que ces cas désagréables se produisent moins souvent, j'ai écrit ce post. La deuxième partie de la trilogie est consacrée aux erreurs des organisateurs.
Le message est organisé comme suit: au début, je parle de l'événement, explique ce qui s'est mal passé et ce qu'il a conduit (ou peut conduire à long terme). Ensuite, je donne mon évaluation de ce qui se passe et comment j'agirais à la place des organisateurs. Puisque j'ai agi en tant que participant à tous les événements, je ne peux qu'assumer la véritable motivation des organisateurs. À la suite de cela, mon évaluation peut se révéler unilatérale. Je n'exclus pas que certains des points que je considère comme erronés ont effectivement été conçus.
À un moment donné, il peut sembler au lecteur que l'auteur a décidé de brandir ses poings après le combat. Mais je peux vous assurer que ce n'est pas le cas. Dans certains des hackathons répertoriés, j'ai réussi à décrocher un prix, ce qui ne m'empêche cependant pas de dire que l'événement était mal organisé.
En raison du respect des organisateurs et des participants, la publication n'indiquera pas d'entreprises spécifiques. Un lecteur attentif, cependant, peut deviner (ou google) de qui ils parlent.
Hackathon n ° 1. Cadre strict
Il y a six mois, une grande entreprise de télécommunications a organisé un hackathon d'analyse de données. Pour le fonds de prix a combattu 20 équipes. Lors de l'événement, un ensemble de données a été fourni pour l'analyse, qui contenait des informations sur les appels au service d'assistance de l'entreprise, l'activité sur les réseaux sociaux et des informations codées sur les utilisateurs (sexe, âge, etc.). La partie la plus intéressante de l'ensemble de données - les messages des utilisateurs et la réponse de l'opérateur (données texte) - était assez «bruyante», elle devait être nettoyée pour un travail ultérieur.
Les organisateurs ont fixé la tâche - faire quelque chose d'intéressant avec les données fournies, et il était interdit d'utiliser des jeux de données ouverts supplémentaires à partir du réseau ou d'analyser les données vous-même. Il était également interdit de proposer des idées non liées à l'ensemble de données. Malheureusement, les données fournies étaient plutôt «médiocres»: il était difficile d'en obtenir des produits intéressants, et en communiquant avec les mentors, il est devenu clair que de nombreuses idées proposées étaient déjà mises en œuvre (ou le seraient dans un proche avenir) dans l'entreprise.
En conséquence, la grande majorité des équipes (15 sur 20) ont créé des robots de discussion. Lors des discours, la décision d'une équipe n'était pas très différente de la précédente. Insupportable, l'un des membres du jury a demandé à la prochaine équipe sur scène: "Quoi, les gars, vous avez aussi un chat bot?" En conséquence, sur les trois prix, les première et deuxième places ont été attribuées à des équipes qui n'ont pas créé de chat bots.
À titre de comparaison, prenez le hackathon, organisé par une société de conseil internationale, pour la société Zvezdochka il y a deux ans. Étant donné que les spécificités de la société Zvezdochka n'étaient pas familières à de nombreux participants au hackathon, au début de l'événement, les organisateurs ont parlé des paramètres utilisés dans l'entreprise. Après cela, six ensembles de données de diverses orientations ont été fournis: texte, tableaux, géo-positions - il y avait une marge de manœuvre pour tous les participants. Les organisateurs n'ont pas interdit l'utilisation d'ensembles de données supplémentaires et ont même soutenu de telles entreprises. Lors de la finale du concours, dix équipes aux décisions différentes se sont disputées le premier prix, et toutes les équipes ont utilisé les données fournies par l'entreprise (malgré l'absence d'interdictions), ce qui indiquait un bon potentiel pour obtenir des produits de qualité.
Moral
Ne limitez pas le flux créatif des participants. En tant qu'organisateur, vous devez fournir du matériel et faire confiance à leurs opinions et à leur professionnalisme. Si vous êtes membre d'un hackathon, toute restriction ou interdiction devrait vous alerter. Habituellement, cela témoigne d'une mauvaise organisation (un exemple de la vie réelle est un désir constant de coller une clôture quelque part). Si vous rencontrez toujours des restrictions, préparez-vous au fait que vous devez créer un projet dans la piscine avec une grande concurrence. Dans ce cas, vous devez prendre des risques: faire quelque chose de fondamentalement nouveau ou proposer une «fonctionnalité tueur» inhabituelle afin de vous démarquer du flux de projets monotones.
Hackathon numéro 2. Tâches impossibles
Le hackathon d'Amadore s'annonçait intéressant. L'entreprise commanditaire, un important fabricant de téléphones, a entamé les préparatifs 4 mois avant la date de l'événement. Un événement social a eu lieu dans les réseaux sociaux, les participants potentiels ont dû passer un test technique et écrire sur leurs projets passés afin d'être sélectionnés pour cet événement. La cagnotte était agréablement grande. Quelques jours avant le hackathon, les mentors ont tenu une séance technique afin que les participants aient le temps de pénétrer les spécificités de l'industrie.
Lors de l'événement, les organisateurs ont fourni un ensemble de données d'équipement de 8 Go avec une classification binaire des pannes. Ils ont parlé des critères d'évaluation des projets - la qualité de la classification, la créativité de créer des fonctionnalités, la capacité de travailler en équipe, etc. C'est juste de la malchance - pour 8 Go de «fonctionnalités», il n'y avait que 20 exemples dans le train et 5 dans le test. Le dernier clou dans le couvercle du cercueil du hackathon a marqué un visage dans les données: les journaux d'équipement reçus mercredi contenaient une erreur dans le fonctionnement de l'équipement, et ceux créés jeudi ne contenaient pas (d'ailleurs, seules deux équipes le savaient, et les deux étaient de Russie - la patrie de datameners expérimentés ) Bien que même connaître les véritables étiquettes du test n'a pas aidé à adapter la réponse, la tâche était insoluble. Les organisateurs n'ont pas obtenu le résultat souhaité, les participants ont passé beaucoup de temps à résoudre une tâche mal composée. Le hackathon a été un échec.
Moral
Effectuez des examens techniques des affectations et vérifiez que vos affectations sont adéquates. Il vaut mieux payer trop cher pour un examen préliminaire (dans ce cas, tout centre de données indiquerait immédiatement qu’il est impossible de résoudre ce problème) que de le regretter plus tard.
Dans ce cas, en plus du temps et de l'argent dépensés, l'entreprise a perdu un prêt fiduciaire de candidats potentiels et il est possible d'écrire sur les résultats. Soit dit en passant, non seulement les participants, mais aussi l'entreprise devraient écrire sur les résultats positifs, en réalisant au maximum le hackathon du point de vue des relations publiques. Malheureusement, toutes les entreprises ne le font pas, se limitant à une post-annonce et à quelques photos de l'événement sur Twitter.
Hackathon numéro 3. A prendre ou à laisser
Plus récemment, notre équipe a participé à un hackathon à Amsterdam. Comme je suis ingénieur électricien de formation (dans le domaine des énergies renouvelables), le sujet était juste pour nous - l'énergie. Le hackathon s'est déroulé dans un format en ligne: on nous a donné une description de la mission et un mois à compléter. Les organisateurs souhaitaient voir un projet terminé qui contribuera à augmenter l'efficacité énergétique des maisons d'Amsterdam.
Nous avons fait un projet dans lequel la consommation d'électricité est prédite (avant cela, j'ai participé à un concours sur ce sujet où j'ai obtenu une solution quasi-sota, qui peut être lue
ici ) et la production par un panneau solaire. Sur la base de ces prédictions, les performances de la batterie sont optimisées (cette idée a été partiellement reprise du diplôme de mon master). Notre projet était en bon accord tant avec la tâche des organisateurs (comme il nous semblait alors) qu'avec la politique de l'administration d'Amsterdam dans le domaine des énergies renouvelables pour plusieurs années à venir.
Lors de l'évaluation des projets, nous avons été informés, comme de nombreuses équipes, que ce n'était pas ce que le client attendait, ajoutant que nous devions refaire le projet si nous voulions concourir pour un prix. Nous n'avons rien refait, résigné à la défaite. Sur les quarante équipes participantes, nous ne sommes même pas entrées dans le top 7, même si le choix des organisateurs, me semble-t-il, était plutôt étrange. Par exemple, ils ont raté l'équipe finale, qui a fait une application pour calculer la vitesse du vent et le rayonnement solaire (SI) selon les capteurs du smartphone: microphone pour le vent, capteur de lumière pour SI. Le tueur de fonctionnalités avait une classification de hotdog / not hotdog en trois classes: le soleil, le vent, l'eau et l'affichage de l'article Wikipedia correspondant (
démo ).
Laissons un instant le côté moral de la question: faire chanter les participants avec la possibilité d'une victoire est tout simplement contraire à l'éthique. Étant donné que l'une des motivations pour participer aux hackathons (en particulier les développeurs expérimentés) est la réalisation de leurs idées, de nombreux participants forts peuvent simplement quitter l'événement après avoir entendu de tels commentaires (ce qui s'est produit non seulement avec notre équipe, mais aussi avec un certain nombre d'autres qui ont cessé de mettre à jour la page de votre projet après avoir écouté le mentor). Néanmoins, disons que nous avons convenu avec les organisateurs et repensé notre projet en fonction de leurs besoins. Que pourrait-il se passer ensuite?
Puisque les organisateurs ont leur propre compréhension du «projet idéal», tous les souhaits (et, par conséquent, les changements) nous mèneront à cet idéal. Les candidats passeront leur temps et il leur sera de plus en plus difficile de refuser de participer davantage (car ils ont déjà investi leurs forces et il semble qu’ils ne pourront pas gagner avant). Mais en réalité, la concurrence pour les prix augmentera et les participants devront de plus en plus refaire le projet de correction des organisateurs dans l'espoir de recevoir un prix. En conséquence, les gars qui n'ont pas pris de prix, avec le recul, se rendront compte qu'ils ont participé à des indépendants sans argent: ils ont apporté des modifications au client, mais en même temps n'ont rien reçu en retour (à l'exception de l'expérience pertinente, bien sûr).
Moral
Souvent, les souhaits et les commentaires des organisateurs viennent en aide au projet. Dans ce cas, cependant, les participants ne devraient pas compter sur les conseils de mentors comme un boiteux sur une canne. Si vous entendez les commentaires des organisateurs sur votre projet dans l'esprit de "emporter, nous ne l'avons pas commandé" - votre participation au hackathon à ce sujet peut être considérée comme terminée.
Si vous organisez un hackathon avec une vision claire du projet, mais sans les compétences ou la capacité de le mettre en œuvre vous-même, il est préférable de concevoir votre vision sous la forme d'une tâche technique pour un pigiste. Sinon, vous devrez payer deux fois - pour le hackathon et pour les services d'un pigiste.