Le côté obscur des hackathons

Dans la partie précédente de la trilogie J'ai examiné plusieurs raisons pour participer à des hackathons. La motivation d'apprendre beaucoup de choses nouvelles et de gagner des prix précieux attire beaucoup de monde, mais souvent, en raison des erreurs des organisateurs ou des entreprises sponsors, l'événement se termine mal et les participants repartent insatisfaits. Pour que de tels incidents désagréables se produisent moins souvent, j'ai rédigé ce post. La deuxième partie de la trilogie est consacrée aux erreurs des organisateurs.

Le post est organisé de la manière suivante : d'abord, je parle de l'événement, j'explique ce qui a mal tourné et quelles conséquences cela a eues (ou pourrait avoir à long terme). Ensuite, je donne mon avis sur ce qui s'est passé et ce que je ferais à la place des organisateurs. Comme j'ai participé à tous les événements, je ne peux que supposer la véritable motivation des organisateurs. En conséquence, mon avis peut être biaisé. Je n'exclus pas que certains points qui me semblent problématiques étaient en fait intentionnels.

À un certain moment, le lecteur pourrait penser que l'auteur a décidé de critiquer après la bataille. Mais je peux vous assurer que ce n'est pas le cas. Lors de certains des hackathons mentionnés, j'ai réussi à obtenir une place sur le podium, ce qui, pourtant, n'empêche pas de dire que l'événement était mal organisé.

Par respect pour les organisateurs et les participants, le post ne mentionnera pas d'entreprises spécifiques. Cependant, le lecteur attentif pourrait deviner (ou googler) de qui il s'agit.

Hackathon n° 1. Cadres stricts

Il y a six mois, une grande entreprise de télécommunications a organisé un hackathon sur l'analyse des données. 20 équipes se sont battues pour le prix. Lors de l'événement, un jeu de données a été fourni pour analyse, contenant des informations sur les demandes adressées au service client de l'entreprise, l'activité sur les réseaux sociaux et des données codées sur les utilisateurs (genre, âge, etc.). La partie la plus intéressante du jeu de données — les messages des utilisateurs et les réponses des opérateurs (données textuelles) — était assez « bruyante », et pour pouvoir l'utiliser, il était nécessaire de la nettoyer.

Les organisateurs avaient pour mission de créer quelque chose d'intéressant avec les données fournies, il était interdit d'utiliser des ensembles de données ouverts supplémentaires provenant d'Internet ou de récupérer les données soi-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 assez "pauvres" : il était difficile d'en tirer des produits intéressants, et au cours des échanges avec les mentors, il est devenu évident que de nombreuses idées proposées étaient déjà mises en oeuvre (ou allaient l'être dans un avenir proche) au sein de l'entreprise.

En conséquence, la grande majorité des équipes (15 sur 20) ont créé des chatbots. Au cours des présentations, la solution d'une équipe était à peine différente de la précédente. Ne supportant plus cela, un membre du jury a demandé à la prochaine équipe montant sur scène : "Eh bien, les gars, vous avez aussi un chatbot ?" Finalement, parmi les trois places récompensées, la première et la deuxième ont été attribuées aux équipes qui n'ont pas créé de chatbots.

Pour comparaison, prenons le hackathon organisé par une société de conseil internationale pour la société "Étoile" il y a deux ans. Étant donné que la spécificité des activités de la société "Étoile" était inconnue de nombreux participants au hackathon, au début de l'événement, les organisateurs ont expliqué les métriques utilisées par l'entreprise. Après cela, six ensembles de données de différentes orientations ont été fournis : textes, tableaux, géolocalisation - tous les participants avaient une grande marge de manœuvre. Les organisateurs n'interdisaient pas l'utilisation d'ensembles de données supplémentaires et soutenaient même de telles initiatives. À la fin de la compétition, dix équipes avec des solutions différentes luttaient pour le grand prix, et toutes les équipes utilisaient les données fournies par l'entreprise (malgré l'absence d'interdictions), ce qui témoignait d'un bon potentiel pour obtenir des produits de qualité.

Moralité

Il ne faut pas limiter le flux créatif des participants. En tant qu'organisateur, vous devez fournir les matériaux et faire confiance à leur point de vue et à leur professionnalisme. Si vous êtes participant au hackathon, toute restriction ou interdiction doit vous alerter. Cela témoigne souvent d'une mauvaise organisation (un exemple du monde réel : le désir constant d'implanter une barrière quelque part). Cependant, si vous êtes confronté à des restrictions, préparez-vous à devoir créer un projet dans un environnement très compétitif. Dans ce cas, vous devez prendre des risques : faire quelque chose de fondamentalement nouveau ou proposer une fonctionnalité “tueur” originale pour vous démarquer de la multitude de projets uniformes.

Hackathon n°2. Tâches irréalisables

Le hackathon à Amador promettait d'être intéressant. L'entreprise sponsor — un grand fabricant de téléphones — a commencé sa préparation quatre mois avant la date de l'événement. Une campagne de relations publiques a eu lieu sur les réseaux sociaux, et les participants potentiels devaient passer un test technique et décrire leurs projets précédents pour être sélectionnés pour cet événement. Le prix en jeu était agréablement élevé. Quelques jours avant le hackathon, les mentors ont organisé une session technique afin que les participants aient le temps de s'imprégner des spécificités du secteur.

Lors de l'événement, les organisateurs ont fourni un ensemble de données de journaux d'équipement d'une taille de 8 Go, avec comme tâche la classification binaire des pannes. Ils ont expliqué les critères d'évaluation des projets — qualité de classification, créativité dans la création de fonctionnalités, capacité à travailler en équipe, etc. Cependant, il y avait un petit problème : sur 8 Go de “fonctionnalités”, il n'y avait que 20 exemples dans le train et 5 dans le test. Le clou final dans le cercueil du hackathon a été enfoncé par un problème dans les données : les journaux d'équipement obtenus mercredi contenaient une erreur de fonctionnement, tandis que ceux créés jeudi n'en contenaient pas (à propos, seules deux équipes étaient au courant, toutes deux venant de Russie — le pays des Data Miners expérimentés). Même connaître les véritables étiquettes de test n'a pas aidé à ajuster la réponse — la tâche était insoluble. Les organisateurs n'ont pas obtenu le résultat souhaité, et les participants ont perdu énormément de temps à résoudre un problème mal formulé. Le hackathon a été un échec.

Moralité

Réalisez des expertises techniques des tâches et vérifiez la validité de vos missions. Il est préférable de payer un peu plus pour une expertise préliminaire (dans ce cas, n'importe quel data scientist aurait immédiatement signalé l'impossibilité de résoudre ce problème) plutôt que de le regretter par la suite.

Dans ce cas, en plus du temps et de l'argent dépensés, l'entreprise a perdu la confiance des candidats potentiels et peut-être même écrire sur les résultats. D'ailleurs, les bons résultats devraient être rapportés non seulement par les participants, mais aussi par l'entreprise, maximisant ainsi le hackathon du point de vue des relations publiques. Malheureusement, toutes les entreprises ne le font pas, se limitant à un post d'annonce et à quelques photos de l'événement sur Twitter.

Hackathon n°3. À prendre ou à laisser.

Tout récemment, notre équipe a participé à un hackathon à Amsterdam. Étant donné que je suis ingénieur en énergie (dans le domaine des sources d'énergie renouvelables), le sujet était parfaitement adapté pour nous — l'énergie. Le hackathon s'est déroulé en format en ligne : nous avons reçu la description de la tâche et un mois pour la réaliser. Les organisateurs souhaitaient voir un projet final qui aiderait à augmenter l'efficacité énergétique des maisons d'Amsterdam.

Nous avons élaboré un projet qui prédit la consommation d'électricité (auparavant, j'avais participé à un concours sur ce thème où j'ai obtenu une solution assez avancée, dont on peut lire) ici) et la génération par panneau solaire. Sur la base de ces prévisions, le fonctionnement de la batterie est optimisé (cette idée a été en partie tirée de mon mémoire de maîtrise). Notre projet était bien aligné tant avec la tâche des organisateurs (ce que nous pensions à l'époque) qu'avec la politique de l'administration d'Amsterdam concernant les sources d'énergie renouvelables pour les prochaines années.

Lors de l'évaluation des projets, nous, comme de nombreuses équipes, avons été informés que ce n'était pas ce que le client attendait, ajoutant que nous devions retravailler le projet si nous voulions rivaliser pour les prix. Nous n'avons rien modifié, acceptant notre défaite. Sur quarante équipes participantes, nous ne sommes même pas parvenus dans le top 7, bien que le choix des organisateurs, à mon avis, ait été assez étrange. Par exemple, ils ont laissé passer en finale une équipe qui a développé une application pour calculer la vitesse du vent et l'irradiation solaire (SI) à partir des capteurs de smartphone : un microphone pour le vent, un capteur de luminosité pour le SI. La killer feature était la classification hotdog/non hotdog en trois classes : Soleil, vent, eau et affichage de l'article correspondant sur Wikipédia.une démo).

Laissons de côté un instant l'aspect moral de la question : faire pression sur les participants avec la perspective de gagner est tout simplement contraire à l'éthique. Puisque l'une des motivations à participer aux hackathons (surtout pour les développeurs expérimentés) est la réalisation de leurs idées, de nombreux participants talentueux pourraient simplement quitter l'événement en entendant des commentaires de ce type (ce qui s'est produit non seulement avec notre équipe, mais aussi avec plusieurs autres qui ont cessé de mettre à jour la page de leur projet après la séance de mentorat). Cela dit, supposons que nous avons accepté les demandes des organisateurs et retravaillé notre projet selon leurs exigences. Que pourrait-il se passer ensuite ?

Puisque les organisateurs ont leur propre vision du « projet idéal », toutes les demandes (et donc les changements) nous orienteront vers cet idéal. Les concurrents perdront du temps et il leur sera de plus en plus difficile de renoncer à leur participation (car des efforts ont déjà été investis, et il semble qu'il ne reste que peu pour gagner). Mais en réalité, la compétition pour les prix augmentera, et les participants devront de plus en plus retravailler leur projet selon les ajustements des organisateurs dans l'espoir de recevoir un prix. Au final, les personnes qui n'ont pas remporté de prix, en regardant en arrière, réaliseront qu'elles ont participé à un projet de freelance sans argent : elles ont apporté des modifications demandées par le client, mais n'ont rien reçu en retour (à part l'expérience correspondante bien sûr).

Moralité

Les souhaits et retours des organisateurs sont souvent utiles au projet. Cependant, les participants ne doivent pas s'appuyer sur les conseils des mentors comme un boiteux sur une canne. Si vous entendez des retours de la part des organisateurs dans le sens de « retirez cela, nous ne l'avons pas commandé » — votre participation au hackathon peut alors être considérée comme terminée.

Si vous organisez un hackathon avec une vision claire du projet, mais sans compétences ou capacité à le réaliser vous-même, il est préférable de formuler votre vision sous la forme d'un cahier des charges pour un freelance. Sinon, vous devrez payer deux fois — pour le hackathon et pour les services du freelance.

Source : habr.com