Die dunkle Seite von Hackathons

Im der vorherigen Teil der Trilogie Ich habe mehrere Gründe für die Teilnahme an Hackathons betrachtet. Die Motivation, viel Neues zu lernen und wertvolle Preise zu gewinnen, zieht viele an, doch oft endet die Veranstaltung aufgrund von Fehlern der Organisatoren oder der sponsoren Unternehmen unglücklich und die Teilnehmer verlassen unzufrieden. Um solche unerfreulichen Fälle seltener zu machen, habe ich diesen Beitrag geschrieben. Der zweite Teil der Trilogie ist den Fehlern der Organisatoren gewidmet.

Der Beitrag ist folgendermaßen organisiert: Zunächst erzähle ich über die Veranstaltung, erkläre, was schiefgelaufen ist und wohin das geführt hat (oder langfristig führen könnte). Dann gebe ich meine Einschätzung der Situation ab und wie ich an der Stelle der Organisatoren gehandelt hätte. Da ich auf allen Veranstaltungen als Teilnehmer aufgetreten bin, kann ich nur die wahre Motivation der Organisatoren vermuten. Daher könnte meine Einschätzung einseitig sein. Ich schließe nicht aus, dass einige Punkte, die ich als fehlerhaft ansehe, tatsächlich so beabsichtigt waren.

Zu einem bestimmten Zeitpunkt könnte der Leser das Gefühl bekommen, dass der Autor nach dem Streit mit den Fäusten wedelt. Aber ich kann Sie beruhigen, dass dem nicht so ist. In einigen der genannten Hackathons gelang es mir, einen Preis zu gewinnen, was jedoch nicht davon abhörte, dass die Veranstaltung schlecht organisiert war.

Aus Respekt vor den Organisatoren und Teilnehmern wird der Beitrag keine Hinweise auf konkrete Unternehmen enthalten. Ein aufmerksamer Leser kann jedoch erraten (oder googeln), um wen es sich handelt.

Hackathon Nr. 1. Strenge Vorgaben

Vor einem halben Jahr organisierte ein großes Telekommunikationsunternehmen einen Hackathon zur Datenanalyse. Um den Preisfonds kämpften 20 Teams. Bei der Veranstaltung wurde ein Datensatz zur Analyse bereitgestellt, der Informationen über Kundenanfragen an den Support des Unternehmens, Aktivitäten in sozialen Medien und codierte Informationen über die Benutzer (Geschlecht, Alter usw.) enthielt. Der interessanteste Teil des Datensatzes – die Nachrichten der Benutzer und die Antworten der Betreiber (Textdaten) – war ziemlich "rauschend", was bedeutete, dass er für die weitere Bearbeitung gereinigt werden musste.

Die Organisatoren haben die Aufgabe gestellt, etwas Interessantes mit den bereitgestellten Daten zu machen, wobei die Verwendung zusätzlicher offener Datensätze aus dem Netz oder das selbständige Parsen von Daten verboten war. Es war auch nicht erlaubt, Ideen vorzuschlagen, die nicht mit dem Datensatz verbunden waren. Leider waren die bereitgestellten Daten ziemlich "arm": Es war schwierig, interessante Produkte daraus zu entwickeln, und aus der Kommunikation mit den Mentoren wurde klar, dass viele der vorgeschlagenen Ideen bereits realisiert werden (oder in naher Zukunft realisiert werden) in der Firma.

In der Folge haben überwältigende 15 von 20 Teams Chatbots erstellt. Während der Präsentationen war die Lösung eines Teams kaum von der vorherigen zu unterscheiden. Einer der Jurymitglieder konnte nicht widerstehen und fragte das nächste Team auf der Bühne: „Was, Leute, habt ihr auch einen Chatbot?“ Letztendlich gingen die ersten und zweiten Plätze an Teams, die keine Chatbots erstellt hatten.

Zum Vergleich nehmen wir einen Hackathon, der vor zwei Jahren von einer internationalen Beratungsfirma für die Firma „Zvezdochka“ organisiert wurde. Da die spezifische Tätigkeit der Firma „Zvezdochka“ vielen Teilnehmern des Hackathons nicht bekannt war, erklärten die Organisatoren zu Beginn der Veranstaltung die Metriken, die im Unternehmen verwendet werden. Danach wurden sechs Datensätze unterschiedlicher Art bereitgestellt: Texte, Tabellen, Geopositionen — es gab für alle Teilnehmer viel Handlungsspielraum. Die Organisatoren erlaubten die Verwendung zusätzlicher Datensätze und unterstützten sogar solche Vorhaben. Im Finale kämpften zehn Teams mit unterschiedlichen Lösungen um den Hauptpreis, und alle Teams nutzten die vom Unternehmen bereitgestellten Daten (trotz der fehlenden Verbote), was auf das gute Potenzial zur Erstellung qualitativ hochwertiger Produkte hinwies.

Moral

Es ist nicht ratsam, den kreativen Fluss der Teilnehmer einzuschränken. Als Organisator sollten Sie Materialien bereitstellen und deren Ansichten und Professionalität vertrauen. Wenn Sie Teilnehmer eines Hackathons sind, sollten Sie über jegliche Einschränkungen oder Verbote besorgt sein. Das ist oft ein Zeichen für eine schlechte Organisation (ein reales Beispiel: das ständige Bestreben, ein Zaun irgendwo aufzustellen). Sollten Sie dennoch auf Einschränkungen stoßen, seien Sie bereit, dass Sie ein Projekt in einem Umfeld mit großer Konkurrenz entwickeln müssen. In solchen Fällen sind Sie verpflichtet, Risiken einzugehen: etwas grundsätzlich Neues zu machen oder ein ungewöhnliches „Killer-Feature“ anzubieten, um sich von der Masse der ähnlichen Projekte abzuheben.

Hackathon Nr. 2. Unmögliche Aufgaben

Der Hackathon in Amador versprach interessant zu werden. Der Sponsor, ein großer Telefonhersteller, begann 4 Monate vor dem Veranstaltungstermin mit den Vorbereitungen. In den sozialen Medien wurde das Event beworben, potenzielle Teilnehmer mussten einen technischen Test bestehen und über ihre früheren Projekte schreiben, um für die Veranstaltung ausgewählt zu werden. Der Preispool war erfreulich groß. Einige Tage vor dem Hackathon hielten die Mentoren eine technische Sitzung ab, damit die Teilnehmer Zeit hatten, sich mit den Besonderheiten der Branche vertraut zu machen.

Bei der Veranstaltung stellten die Organisatoren ein 8 GB großes Datenset mit Gerälogdaten zur Verfügung, die Aufgabe bestand in der binären Klassifizierung von Fehlern. Es wurden Kriterien zur Bewertung der Projekte erläutert – die Qualität der Klassifizierung, die Kreativität bei der Erstellung von Features, Teamarbeit usw. Das Problem war nur, dass es von 8 GB „Features“ nur 20 Beispiele im Training und 5 im Test gab. Der endgültige Nagel zum Sarg des Hackathons waren die Daten: Die am Mittwoch erfassten Gerälogdaten wiesen einen Fehler in der Funktionsweise der Geräte auf, die am Donnerstag erstellten Daten hatten keinen (darüber wussten übrigens nur zwei Teams, und beide kamen aus Russland – der Heimat erfahrener Data-Miner). Obwohl selbst das Wissen um die wahren Labels des Tests nicht half, die Antwort zu optimieren – die Aufgabe war unlösbar. Die Organisatoren erhielten nicht das gewünschte Ergebnis, die Teilnehmer verbrachten eine Menge Zeit mit der Lösung einer schlecht formulierten Aufgabe. Der Hackathon war ein Misserfolg.

Moral

Führen Sie technische Gutachten für Aufgaben durch und überprüfen Sie Ihre Aufgaben auf Angemessenheit. Es ist besser, für eine vorab Prüfung mehr zu bezahlen (in diesem Fall hätte jeder Data Scientist sofort auf die Unmöglichkeit dieser Aufgabe hingewiesen), als später zu bereuen.

In diesem Fall hat die Firma neben der verlorenen Zeit und dem Geld auch das Vertrauen potenzieller Kandidaten verloren und möglicherweise nicht über die Ergebnisse berichtet. Übrigens sollten nicht nur die Teilnehmer über erfolgreiche Ergebnisse berichten, sondern auch die Firma, um das Hackathon-Maximum aus PR-Sicht zu realisieren. Leider tun das nicht alle Unternehmen, die sich auf einen Ankündigungsbeitrag und ein paar Fotos von der Veranstaltung auf Twitter beschränken.

Hackathon Nr. 3. Take it or leave it

Kürzlich hat unser Team an einem Hackathon in Amsterdam teilgenommen. Da ich im Bereich Erneuerbare Energien als Elektroingenieur ausgebildet wurde, war das Thema genau das Richtige für uns – Energieverbrauch. Der Hackathon fand online statt: Wir erhielten eine Aufgabenbeschreibung und einen Monat Zeit für die Umsetzung. Die Organisatoren wollten ein fertiges Projekt sehen, das die Energieeffizienz der Häuser in Amsterdam steigert.

Wir haben ein Projekt entwickelt, das den Stromverbrauch vorhersagt (zuvor nahm ich an einem Wettbewerb zu diesem Thema teil, wo ich eine etwa-Best Lösung erzielte, über die man lesen kann hier) und die Erzeugung durch Solarpanel. Basierend auf diesen Vorhersagen wird der Betrieb der Batterien optimiert (diese Idee wurde teilweise aus meiner Masterarbeit übernommen). Unser Projekt stimmte sowohl mit der Aufgabenstellung der Organisatoren überein (wie es uns damals schien) als auch mit der Politik der Stadt Amsterdam in Bezug auf erneuerbare Energien für die kommenden Jahre.

Bei der Bewertung von Projekten wurde uns, wie vielen anderen Teams, gesagt, dass dies nicht dem entsprach, was der Kunde erwartet hatte, und dass wir das Projekt überarbeiten müssten, wenn wir um die Preise konkurrieren wollten. Wir beschlossen, nichts zu ändern und akzeptierten die Niederlage. Von vierzig teilnehmenden Teams kamen wir nicht einmal unter die Top 7, obwohl ich fand, dass die Auswahl der Organisatoren ziemlich seltsam war. Zum Beispiel schaffte es ein Team ins Finale, das eine Anwendung zur Berechnung der Windgeschwindigkeit und der Solarstrahlung (SI) basierend auf den Daten von Smartphones entwickelt hatte: ein Mikrofon für den Wind und einen Lichtsensor für die SI. Das Killer-Feature war die Klassifizierung hotdog/not hotdog in drei Klassen: Sonne, Wind, Wasser und die Anzeige des entsprechenden Artikels in Wikipedia.Demo).

Lassen wir für einen Moment die moralische Seite des Themas beiseite: Die Teilnehmer mit der Möglichkeit des Gewinns zu erpressen, ist einfach unethisch. Da eine der Motivation zur Teilnahme an Hackathons (insbesondere für erfahrene Entwickler) die Umsetzung ihrer Ideen ist, könnten viele starke Teilnehmer die Veranstaltung einfach verlassen, wenn sie solch ein Feedback hören (was nicht nur bei unserem Team, sondern auch bei mehreren anderen passierte, die aufhörten, die Seite ihres Projekts nach dem Mentoring-Feedback zu aktualisieren). Angenommen, wir hätten uns den Wünschen der Organisatoren gefügt und unser Projekt nach ihren Anforderungen umgestaltet. Was könnte als Nächstes passieren?

Da die Organisatoren eine eigene Vorstellung von "dem idealen Projekt" haben, werden alle Wünsche (und damit die Änderungen) uns in Richtung dieses Ideals lenken. Die Teilnehmer werden ihre Zeit vertreiben, und es wird immer schwieriger für sie, sich von einer weiteren Teilnahme zurückzuziehen (da bereits Anstrengungen investiert wurden, und es scheint, als sei der Sieg fast zum Greifen nah). In Wirklichkeit wird der Wettbewerb um die Preise jedoch zunehmen, und die Teilnehmer werden immer häufiger ihr Projekt nach den Änderungen der Organisatoren überarbeiten müssen, in der Hoffnung, einen Preis zu gewinnen. Letztendlich werden die Leute, die keine Preise gewonnen haben, zurückblickend erkennen, dass sie an einem Freelance-Projekt ohne Bezahlung teilgenommen haben: Sie brachten die Änderungen des Kunden ein, erhielten jedoch nichts im Gegenzug dafür (außer dem entsprechenden Erfahrung, selbstverständlich).

Moral

Häufig kommen Wünsche und Rückmeldungen von den Organisatoren dem Projekt zugute. Dabei sollten die Teilnehmer jedoch nicht auf Ratschläge von Mentoren angewiesen sein, wie ein Lahmer auf einen Stock. Wenn Sie von den Organisatoren Feedback zu Ihrem Projekt in der Art von „Nehmen Sie das weg, das haben wir nicht bestellt“ hören – dann können Sie Ihre Teilnahme am Hackathon als beendet betrachten.

Wenn Sie einen Hackathon mit einer klaren Vision des Projekts organisieren, aber nicht die Fähigkeiten oder die Möglichkeit haben, es selbst umzusetzen, sollten Sie Ihre Vision besser in Form eines technischen Auftrags für einen Freiberufler formulieren. Andernfalls müssen Sie zweimal bezahlen – für den Hackathon und für die Dienstleistungen des Freiberuflers.

Quelle: habr.com