В J'ai envisagé plusieurs raisons de participer à des hackathons. La motivation d'apprendre beaucoup de nouvelles choses et de gagner des prix précieux en attire beaucoup, mais souvent en raison des erreurs des organisateurs ou des entreprises sponsors, l'événement se termine sans succès et les participants repartent insatisfaits. Pour que de tels cas désagréables surviennent moins souvent, j'ai écrit ce post. La deuxième partie de la trilogie est consacrée aux erreurs des organisateurs.
Le post est organisé comme suit : au début, je parle de l'événement, j'explique ce qui n'a pas fonctionné et à quoi cela a conduit (ou pourrait conduire à long terme). Ensuite, je donne mon évaluation de ce qui se passe et de ce que je ferais à la place des organisateurs. Puisque j'ai participé à tous les événements en tant que participant, je ne peux qu'assumer la véritable motivation des organisateurs. En conséquence, mon évaluation pourrait s’avérer unilatérale. Je n’exclus pas que certains points que je considère comme erronés aient en réalité été intentionnels.
À un moment donné, le lecteur peut penser que l'auteur a décidé de lever les 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 à remporter un prix, ce qui ne nous empêche cependant pas de dire que l'événement était mal organisé.
Par respect pour les organisateurs et les participants, il n’y aura aucune référence à des entreprises spécifiques dans le message. Un lecteur attentif, cependant, peut deviner (ou rechercher sur Google) de qui il s’agit.
Hackathon numéro 1. Encadrement strict
Il y a six mois, une grande entreprise de télécommunications a organisé un hackathon d'analyse de données. 20 équipes se sont battues pour le prix. Lors de l'événement, un ensemble de données a été fourni pour analyse, contenant 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 de l'utilisateur et la réponse de l'opérateur (données textuelles) - était assez « bruyante », elle devait être nettoyée pour des travaux ultérieurs.
Les organisateurs se sont donné pour tâche de faire quelque chose d'intéressant avec les données fournies, et il était interdit d'utiliser des ensembles de données ouverts supplémentaires du réseau ou d'analyser les données vous-même. Il était également interdit de proposer des idées sans rapport avec l'ensemble de données. Malheureusement, les données fournies étaient plutôt « pauvres » : il était difficile d'en obtenir des produits intéressants, et de la communication avec les mentors, il est devenu clair que bon nombre des idées proposées sont déjà mises en œuvre (ou le seront dans un avenir proche). dans l'entreprise.
Résultat, la grande majorité des équipes (15 sur 20) ont créé des chatbots. Lors des représentations, la décision d'une équipe était peu différente de la précédente. Incapable de le supporter, l’un des membres du jury a demandé à l’équipe suivante entrant sur scène : « Quoi, les gars, vous avez aussi un chatbot ? ». En conséquence, sur trois prix, les première et deuxième places sont allées aux équipes qui n'ont pas encore commencé à créer des chatbots.
A titre de comparaison, prenons un hackathon organisé par une société de conseil internationale pour Zvezdochka il y a deux ans. Étant donné que les détails des activités de Zvezdochka n'étaient pas familiers à de nombreux participants au hackathon, les organisateurs ont parlé au début de l'événement des paramètres utilisés dans l'entreprise. Après cela, six ensembles de données de différentes directions ont été fournis : texte, tableaux, géolocalisations - 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 initiatives. Lors de la finale du concours, dix équipes proposant des solutions différentes se sont affrontées pour le prix principal, toutes les équipes utilisant les données fournies par l'entreprise (malgré l'absence d'interdictions), ce qui indique un bon potentiel pour obtenir des produits de qualité.
Moralité
Ne limitez pas le flux créatif des participants. En tant qu'organisateur, vous devez fournir du matériel et faire confiance à leur vision et à leur professionnalisme. Si vous participez au hackathon, toute restriction ou interdiction devrait vous alerter, ce qui témoigne généralement d'une mauvaise organisation (un exemple concret est le désir constant de coller une clôture quelque part). Si vous rencontrez toujours des restrictions, préparez-vous au fait que vous devrez créer un projet dans un pool très concurrentiel. Dans ce cas, il faut prendre des risques : faire quelque chose de fondamentalement nouveau ou proposer une « fonctionnalité qui tue » inhabituelle afin de se démarquer du flux de projets monotones.
Hackathon #2. Tâches impossibles
Le hackathon d'Amadora s'annonçait intéressant. La société sponsor, un important fabricant de téléphones, a commencé les préparatifs 4 mois avant la date de l'événement. Les relations publiques de l'événement ont été réalisées sur 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. Le fonds du prix était agréablement important. Quelques jours avant le hackathon, les mentors ont organisé une séance technique afin que les participants aient le temps de ressentir les spécificités de l'industrie.
Lors de l'événement lui-même, les organisateurs ont fourni un ensemble de données de 8 Go de journaux d'équipement, la tâche consistait en une classification binaire des pannes. Ils ont évoqué les critères d'évaluation des projets - la qualité du classement, la créativité de création de fonctionnalités, la capacité à travailler en équipe, etc. C'est juste pas de chance - 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 cercueil du hackathon a été enfoncé par une fuite de données : les journaux d'équipement reçus mercredi contenaient une erreur dans le fonctionnement de l'équipement, et ceux créés jeudi n'en contenaient pas (d'ailleurs, seules deux équipes savaient à ce sujet, et tous deux venaient de Russie, patrie des dataminers expérimentés). Bien que même connaître les véritables étiquettes du test n'ait pas aidé à ajuster la réponse, le problème était insoluble. Les organisateurs n'ont pas obtenu le résultat escompté, les participants ont passé beaucoup de temps à résoudre un problème mal formulé. Le hackathon a échoué.
Moralité
Effectuer des examens techniques des missions et vérifier leur adéquation. Il vaut mieux payer trop cher pour un examen préliminaire (dans ce cas, tout data scientist ferait immédiatement remarquer qu'il est impossible de résoudre ce problème) que de regretter plus tard.
Dans ce cas, en plus du temps et de l’argent perdus, l’entreprise a perdu sa crédibilité auprès des candidats potentiels et éventuellement de la rédaction des résultats. À propos, non seulement les participants devraient écrire sur les résultats réussis, mais également l'entreprise, qui met en œuvre le hackathon autant que possible en termes de relations publiques. Malheureusement, toutes les entreprises ne le font pas, se limitant à une simple post-annonce et à quelques photos de l'événement sur Twitter.
Hackathon n°3. À prendre ou a laisser
Plus récemment, notre équipe a participé à un hackathon à Amsterdam. Comme je suis ingénieur en énergie électrique de formation (dans le domaine des sources d'énergie renouvelables), le sujet était juste pour nous : l'énergie. Le hackathon s'est déroulé en ligne : nous avons reçu une description de la tâche et un mois pour la réaliser. Les organisateurs voulaient voir un projet achevé qui contribuerait à accroître l'efficacité énergétique des maisons d'Amsterdam.
Nous avons réalisé un projet qui prédit la consommation électrique (avant cela, j'ai participé à un concours sur ce sujet où j'ai reçu une solution proche de la sota, que vous pouvez lire sur ) et génération par panneau solaire. Sur la base de ces prédictions, les performances de la batterie sont optimisées (cette idée est en partie tirée de mon mémoire de maîtrise). Notre projet était en bon accord à la fois avec la tâche des organisateurs (comme cela nous semblait alors) et 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, on nous a dit, comme beaucoup d'équipes, que ce n'était pas ce que le client attendait, tout en ajoutant qu'il fallait refaire le projet si nous voulions concourir pour le prix. Nous n’avons rien changé, résignés à la défaite. Sur la quarantaine d'équipes participantes, nous n'avons même pas atteint le top 7, même si le choix des organisateurs me semble assez étrange. Ils ont par exemple raté la dernière équipe, qui a réalisé une application permettant de calculer la vitesse du vent et le rayonnement solaire (SI) à l'aide de capteurs de smartphone : un microphone pour le vent, un capteur de lumière pour SI. La fonctionnalité qui tue était la classification des hotdogs/non hotdogs en trois classes : Soleil, vent, eau et l'affichage de l'article Wikipédia correspondant ().
Laissons un instant le côté moral de la question : faire chanter les participants en leur offrant la possibilité de gagner 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 de mettre en œuvre leurs idées, de nombreux participants forts peuvent simplement quitter l'événement après avoir entendu de tels retours (ce qui s'est produit non seulement avec notre équipe, mais aussi avec un certain nombre d'autres qui ont arrêté mise à jour de leur page).projet après avoir écouté le mentor). Pourtant, disons que nous avons accepté les souhaits des organisateurs et repensé notre projet pour répondre à leurs exigences. 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 concurrents perdront leur temps et il leur sera de plus en plus difficile de refuser une participation ultérieure (puisque les forces ont déjà été investies et qu'il semble qu'il y ait très peu de choses avant la victoire). Mais en réalité, la compétition pour les prix va s'intensifier, et les participants devront de plus en plus retravailler le projet avec les corrections des organisateurs dans l'espoir de remporter un prix. En conséquence, les gars qui n'ont pas remporté de prix, avec le recul, se rendront compte qu'ils ont participé au travail indépendant sans argent : ils ont apporté des modifications au client, mais en même temps n'ont rien reçu en retour (à l'exception du correspondant expérience, bien sûr).
Moralité
Souvent, les souhaits et les retours des organisateurs viennent en aide au projet. Ce faisant, cependant, les participants ne devraient pas se fier aux conseils de mentors comme un boiteux tenant une canne. Si vous entendez des commentaires des organisateurs sur votre projet dans l'esprit de « supprimez-le, nous ne l'avons pas commandé » - votre participation au hackathon peut être considérée comme terminée.
Si vous organisez un hackathon avec une vision claire du projet, mais sans les compétences ni la capacité de le mettre en œuvre vous-même, alors mieux vaut formater votre vision sous la forme d'un cahier des charges de freelance. Sinon, vous devrez payer deux fois : pour le hackathon et pour les services d'un pigiste.
Source: habr.com