In habe ich einige Gründe für die Teilnahme an Hackathons betrachtet. Die Motivation, viel Neues zu lernen und wertvolle Preise zu gewinnen, zieht viele an, aber oft enden Veranstaltungen aufgrund von Fehlern der Organisatoren oder der Sponsorunternehmen unglücklich, und die Teilnehmer verlassen sie unzufrieden. Um solche unangenehmen Vorfälle seltener zu machen, habe ich diesen Beitrag verfasst. Der zweite Teil der Trilogie befasst sich mit den Fehlern der Organisatoren.
Der Beitrag ist wie folgt strukturiert: Zu Beginn erläutere ich die Veranstaltung, erkläre, was schiefgelaufen ist und welche Folgen dies hatte (oder langfristig haben könnte). Dann gebe ich meine Bewertung der Ereignisse ab und erläutere, wie ich anstelle der Organisatoren gehandelt hätte. Da ich bei allen Veranstaltungen als Teilnehmer dabei war, kann ich nur die wahre Motivation der Organisatoren vermuten. Daher könnte meine Einschätzung einseitig sein. Ich schließe nicht aus, dass einige Aspekte, die mir fehlerhaft erscheinen, tatsächlich so geplant waren.
Zu einem bestimmten Zeitpunkt könnte der Leser den Eindruck gewinnen, dass der Autor nach dem Streit mit den Fäusten fuchtelt. Ich kann Sie jedoch beruhigen, das ist nicht der Fall. In einigen der genannten Hackathons konnte ich Preise gewinnen, was allerdings nicht bedeutet, dass die Veranstaltung gut organisiert war.
Aus Respekt vor den Organisatoren und Teilnehmern werden im Beitrag keine spezifischen Unternehmen erwähnt. Aufmerksame Leser könnten jedoch erraten (oder googeln), von wem die Rede ist.
Hackathon Nr. 1. Strenge Rahmenbedingungen
Vor einem halben Jahr veranstaltete ein großes Telekommunikationsunternehmen einen Hackathon zur Datenanalyse. 20 Teams kämpften um den Preisfonds. Bei der Veranstaltung wurde ein Datensatz zur Analyse bereitgestellt, der Informationen über Kundenanfragen beim Support, Aktivitäten in sozialen Medien und codierte Informationen über die Benutzer (Geschlecht, Alter usw.) enthielt. Der interessanteste Teil des Datensatzes – die Nutzer-Nachrichten und die Antworten der Betreiber (Textdaten) – war ziemlich "geräuschvoll" und musste für die weitere Verarbeitung gereinigt werden.
Die Organisatoren hatten die Aufgabe gestellt, etwas Interessantes mit den bereitgestellten Daten zu machen, wobei die Verwendung zusätzlicher offener Datensätze aus dem Internet oder das Selbstparsen der Daten verboten war. Es war ebenfalls untersagt, Ideen vorzuschlagen, die nicht mit dem Datensatz in Verbindung standen. Leider waren die bereitgestellten Daten recht "arm"; es war schwierig, interessante Produkte daraus zu entwickeln, und aus Gesprächen mit den Mentoren wurde klar, dass viele der vorgeschlagenen Ideen bereits umgesetzt werden oder in naher Zukunft im Unternehmen umgesetzt werden sollen.
In der Folge haben die überwiegende Mehrheit der Teams (15 von 20) Chatbots erstellt. Während der Präsentationen war die Lösung eines Teams kaum von der vorherigen zu unterscheiden. Unmütig fragte ein Jurymitglied das nächste Team, das auf die Bühne trat: "Was, Leute, habt ihr auch einen Chatbot?" Letztendlich gingen die ersten und zweiten Plätze an Teams, die keine Chatbots erstellt hatten.
Nehmen wir als Vergleich einen Hackathon, der vor zwei Jahren von einem internationalen Beratungsunternehmen für die Firma "Zvezdochka" organisiert wurde. Da die spezifische Tätigkeit von "Zvezdochka" vielen Teilnehmern des Hackathons nicht vertraut war, erläuterten die Veranstalter zu Beginn der Veranstaltung die Metriken, die im Unternehmen verwendet werden. Anschließend wurden sechs Datensätze mit unterschiedlichen Ausrichtungen bereitgestellt: Texte, Tabellen, Geopositionen – für alle Teilnehmer war reichlich Spielraum vorhanden. Die Organisatoren untersagten nicht die Nutzung zusätzlicher Datensätze und förderten solche Initiativen sogar. Im Finale des Wettbewerbs traten zehn Teams mit verschiedenen Lösungen gegeneinander an, um den Hauptpreis zu gewinnen. Alle Teams nutzten die Daten, die vom Unternehmen bereitgestellt wurden (obwohl es keine Verbote gab), was auf ein gutes Potenzial zur Erstellung qualitativ hochwertiger Produkte hinwies.
Moral
Begrenzen Sie nicht den kreativen Fluss der Teilnehmer. Als Organisator sollten Sie Materialien bereitstellen und sich auf deren Perspektive und Professionalität verlassen. Wenn Sie an einem Hackathon teilnehmen, sollten Sie bei jeglichen Einschränkungen oder Verboten skeptisch sein. Dies ist oft ein Zeichen für schlechte Organisation (ein Beispiel aus der Praxis ist das ständige Bedürfnis, irgendwo einen Zaun aufzustellen). Sollten Sie dennoch auf Einschränkungen stoßen, seien Sie darauf vorbereitet, in einem Umfeld mit starker Konkurrenz zu arbeiten. In diesem Fall müssen Sie Risiken eingehen: etwas grundlegend Neues schaffen oder ein außergewöhnliches "Killer-Feature" anbieten, um sich von der Flut einheitlicher Projekte abzuheben.
Hackathon Nr. 2. Unlösbare Aufgaben
Der Hackathon in Amadora versprach spannend zu werden. Der Hauptsponsor, ein großer Hersteller von Smartphones, begann bereits vier Monate vor dem Event mit den Vorbereitungen. In den sozialen Medien wurde für die Veranstaltung Werbung gemacht; potenzielle Teilnehmer mussten einen technischen Test ablegen und über ihre bisherigen Projekte berichten, um für die Teilnahme ausgewählt zu werden. Der Preispool war erfreulich großzügig. Einige Tage vor dem Hackathon führten Mentoren eine technische Sitzung durch, damit die Teilnehmer die Branche besser kennenlernen konnten.
Auf der Veranstaltung haben die Organisatoren einen Log-Datensatz der Ausrüstung mit einem Volumen von 8 GB bereitgestellt, die Aufgabe war die binäre Klassifikation von Ausfällen. Es wurden Kriterien zur Bewertung der Projekte vorgestellt – die Qualität der Klassifikation, die Kreativität bei der Erstellung von Features, Teamarbeit usw. Das Problem war jedoch, dass es bei 8 GB "Features" nur 20 Beispiele im Training und 5 im Test gab. Der letzte Nagel im Sarg des Hackathons war die Datenlage: Die Log-Daten der Ausrüstung, die am Mittwoch erfasst wurden, enthielten einen Fehler, während die, die am Donnerstag erfasst wurden, keinen enthielten (nur zwei Teams, beide aus Russland, wussten übrigens darüber Bescheid – das Land erfahrener Data-Miner). Obwohl das Wissen um die tatsächlichen Testlabels nicht half, das Ergebnis anzupassen – die Aufgabe war unlösbar. Die Organisatoren erhielten nicht das gewünschte Ergebnis, die Teilnehmer haben viel Zeit mit der Lösung einer schlecht formulierten Aufgabe verschwendet. Der Hackathon war ein Misserfolg.
Moral
Führen Sie technische Prüfungen der Aufgaben durch und überprüfen Sie die Angemessenheit Ihrer Aufgaben. Es ist besser, für eine Vorprüfung (in diesem Fall hätte jeder Data Scientist sofort auf die Unmöglichkeit dieser Aufgabe hingewiesen) mehr zu bezahlen, als später bereuen zu müssen.
In diesem Fall hat das Unternehmen neben der investierten Zeit und Geld auch das Vertrauen von potenziellen Kandidaten verloren und könnte möglicherweise über die Ergebnisse berichten. Übrigens sollten nicht nur die Teilnehmer über erfolgreiche Ergebnisse berichten, sondern auch das Unternehmen, um den Hackathon aus PR-Sicht maximal zu nutzen. Leider tun dies nicht alle Unternehmen und beschränken sich lediglich auf einen Ankündigungspost und ein paar Fotos von der Veranstaltung auf Twitter.
Hackathon Nr. 3. Nehmen oder lassen
Unsere Mannschaft hat kürzlich an einem Hackathon in Amsterdam teilgenommen. Da ich ausgebildeter Elektroingenieur im Bereich erneuerbare Energien bin, war das Thema perfekt für uns – Energie. Der Hackathon fand im Online-Format statt: Wir erhielten eine Aufgabenbeschreibung und einen Monat Zeit zur Umsetzung. Die Organisatoren wollten ein fertiges Projekt sehen, das dazu beiträgt, die Energieeffizienz von Wohnhäusern in Amsterdam zu steigern.
Wir haben ein Projekt entwickelt, das den Energieverbrauch vorhersagt (zuvor habe ich an einem Wettbewerb zu diesem Thema teilgenommen, bei dem ich eine Art-SoTAS-Lösung erhielt, über die man lesen kann) ) und die Erzeugung durch die Solarzelle. Auf Basis dieser Vorhersagen wird die Leistung der Batterie optimiert (die Idee stammt teilweise aus meiner Masterarbeit). Unser Projekt stimmte gut mit den Anforderungen der Organisatoren überein (wie wir damals dachten) und auch mit der Politik der Amsterdamer Verwaltung in Bezug auf erneuerbare Energien für die kommenden Jahre.
Während der Bewertung der Projekte wurde uns, wie vielen anderen Teams, gesagt, dass dies nicht den Erwartungen des Auftraggebers entsprach, und dass wir das Projekt überarbeiten sollten, wenn wir um einen Preis konkurrieren wollten. Wir entschieden uns, nichts zu überarbeiten und akzeptierten unsere Niederlage. Von vierzig teilnehmenden Teams erreichten wir nicht einmal die Top-7, obwohl die Auswahl der Organisatoren, meiner Meinung nach, ziemlich seltsam war. Zum Beispiel schaffte es ein Team ins Finale, das eine App zur Berechnung der Windgeschwindigkeit und der Sonnenstrahlung (SI) basierend auf Smartphone-Sensordaten entwickelt hatte: Mikrofon für Wind, Lichtsensor für SI. Ein Killerfeature war die Klassifizierung hotdog/nicht hotdog in drei Klassen: Sonne, Wind, Wasser und die Anzeige des entsprechenden Artikels in Wikipedia.).
Lassen wir einmal die moralische Seite der Frage beiseite: Es ist einfach unethisch, Teilnehmer mit der Aussicht auf einen Sieg zu erpressen. Eine der Motivationen für die Teilnahme an Hackathons (insbesondere für erfahrene Entwickler) ist die Umsetzung ihrer Ideen. Viele talentierte Teilnehmer könnten einfach die Veranstaltung verlassen, nachdem sie solches Feedback gehört haben (was nicht nur mit unserem Team, sondern auch mit anderen passiert ist, die aufgehört haben, ihre Projektseite nach dem Feedback des Mentors zu aktualisieren). Angenommen, wir haben den Wünschen der Organisatoren zugestimmt und unser Projekt an ihre Anforderungen angepasst. Was könnte dann passieren?
Da die Veranstalter ihre eigene Vorstellung vom „idealen Projekt“ haben, werden alle Wünsche (und entsprechend Änderungen) uns diesem Ideal näherbringen. Die Teilnehmer werden ihre Zeit investieren und es wird immer schwieriger für sie, eine weitere Teilnahme abzulehnen (da bereits Kraft investiert wurde und es den Anschein hat, dass der Sieg zum Greifen nah ist). In Wirklichkeit wird jedoch der Wettbewerb um die vorderen Plätze zunehmen, und die Teilnehmer werden zunehmend gezwungen sein, ihre Projekte aufgrund von Änderungen der Veranstalter zu überarbeiten, in der Hoffnung, einen Preis zu gewinnen. Letztendlich werden die Teilnehmer, die keinen Preis gewonnen haben, zurückblicken und erkennen, dass sie am Freelancing ohne finanziellen Gewinn teilgenommen haben: sie haben die Änderungen des Auftraggebers umgesetzt, aber nichts im Gegenzug erhalten (außer natürlich wertvoller Erfahrung).
Moral
Häufig kommen Wünsche und Feedback von den Veranstaltern dem Projekt zugute. Allerdings sollten die Teilnehmer nicht wie ein Gehbehinderter auf den Rat der Mentoren angewiesen sein. Wenn Sie vom Veranstalter Feedback zu Ihrem Projekt hören wie „entfernen Sie es, das haben wir nicht bestellt“ – können Sie Ihre Teilnahme am Hackathon als beendet betrachten.
Wenn Sie einen Hackathon mit einer klaren Projektvision organisieren, aber nicht über die Fähigkeiten oder Ressourcen verfügen, um ihn selbst umzusetzen, sollten Sie Ihre Vision besser in Form eines technischen Pflichtenhefts für einen Freiberufler festhalten. Andernfalls müssen Sie zweimal bezahlen – für den Hackathon und für die Dienstleistungen des Freiberuflers.
Quelle: habr.com
