Im
vorherigen Teil der Trilogie habe ich verschiedene Gründe für die Teilnahme an Hackathons untersucht. Die Motivation, viel zu lernen und wertvolle Preise zu gewinnen, zieht viele an, aber oft endet die Veranstaltung aufgrund der Fehler der Organisatoren oder Sponsorenunternehmen erfolglos und die Teilnehmer verlassen sie unzufrieden. Damit solche unangenehmen Fälle seltener auftreten, habe ich diesen Beitrag geschrieben. Der zweite Teil der Trilogie ist den Fehlern der Organisatoren gewidmet.
Der Beitrag ist wie folgt organisiert: Zu Beginn spreche ich über das Ereignis, erkläre, was schief gelaufen ist und wozu es geführt hat (oder auf lange Sicht führen kann). Dann gebe ich meine Einschätzung darüber, was passiert und wie ich anstelle der Organisatoren handeln würde. Da ich bei allen Veranstaltungen als Teilnehmer aufgetreten bin, kann ich nur die wahre Motivation der Veranstalter übernehmen. Infolgedessen kann sich meine Einschätzung als einseitig herausstellen. Ich schließe nicht aus, dass einige der Punkte, die ich als falsch betrachte, tatsächlich konzipiert wurden.
Irgendwann mag es dem Leser so erscheinen, als hätte der Autor beschlossen, nach dem Kampf mit den Fäusten zu winken. Aber ich kann Ihnen versichern, dass dies nicht so ist. Bei einigen der aufgelisteten Hackathons konnte ich einen Preis gewinnen, was mich jedoch nicht daran hindert zu sagen, dass die Veranstaltung schlecht organisiert war.
Aus Respekt vor den Organisatoren und Teilnehmern werden in der Post keine spezifischen Unternehmen angegeben. Ein aufmerksamer Leser kann jedoch erraten (oder googeln), über wen er spricht.
Hackathon Nr. 1. Strenger Rahmen
Vor sechs Monaten organisierte ein großes Telekommunikationsunternehmen einen Datenanalyse-Hackathon. Um den Preisfonds kämpften 20 Teams. Bei der Veranstaltung wurde ein Datensatz zur Analyse bereitgestellt, der Informationen zu Anrufen beim Support-Service des Unternehmens, Aktivitäten in sozialen Netzwerken und verschlüsselte Informationen zu Benutzern (Geschlecht, Alter usw.) enthielt. Der interessanteste Teil des Datensatzes - Benutzernachrichten und Bedienerantworten (Textdaten) - war ziemlich "laut" und musste für weitere Arbeiten gereinigt werden.
Die Organisatoren haben sich die Aufgabe gestellt, mit den bereitgestellten Daten etwas Interessantes zu tun, und es war verboten, zusätzliche offene Datensätze aus dem Netzwerk zu verwenden oder die Daten selbst zu analysieren. Es war auch verboten, Ideen anzubieten, die nicht mit dem Datensatz zusammenhängen. Leider waren die bereitgestellten Daten eher „schlecht“: Es war schwierig, interessante Produkte von ihnen zu erhalten, und durch die Kommunikation mit Mentoren wurde deutlich, dass viele der vorgeschlagenen Ideen bereits im Unternehmen umgesetzt wurden (oder in naher Zukunft umgesetzt werden würden).
Infolgedessen machte die überwiegende Mehrheit der Teams (15 von 20) Chat-Bots. Während der Reden war die Entscheidung eines Teams nicht viel anders als die vorherige. Unerträglich fragte eines der Jurymitglieder das nächste Team auf der Bühne: "Was, Leute, habt ihr auch einen Chat-Bot?" Von den drei Preisen gingen die ersten und zweiten Plätze an Teams, die keine Chat-Bots machten.
Nehmen Sie zum Vergleich den Hackathon, der vor zwei Jahren von einem internationalen Beratungsunternehmen für die Firma Zvezdochka organisiert wurde. Da die Besonderheiten der Firma Zvezdochka vielen Hackathon-Teilnehmern nicht bekannt waren, sprachen die Organisatoren zu Beginn der Veranstaltung über die im Unternehmen verwendeten Metriken. Danach wurden sechs Datensätze mit unterschiedlichen Ausrichtungen bereitgestellt: Text, Tabellen, Geopositionen - für alle Teilnehmer gab es Handlungsspielraum. Die Organisatoren haben die Verwendung zusätzlicher Datensätze nicht verboten und solche Verpflichtungen sogar unterstützt. Im Finale des Wettbewerbs kämpften zehn Teams mit unterschiedlichen Entscheidungen um den Hauptpreis, und alle Teams verwendeten die vom Unternehmen bereitgestellten Daten (trotz fehlender Verbote), die auf ein gutes Potenzial für den Erhalt von Qualitätsprodukten hinwiesen.
Moral
Beschränken Sie nicht den kreativen Fluss der Teilnehmer. Als Veranstalter müssen Sie Materialien bereitstellen und deren Ansichten und Professionalität vertrauen. Wenn Sie Mitglied eines Hackathons sind, sollten Sie durch Einschränkungen oder Verbote benachrichtigt werden. Normalerweise ist dies ein Beweis für eine schlechte Organisation (ein Beispiel aus dem wirklichen Leben ist der ständige Wunsch, irgendwo einen Zaun zu stecken). Wenn Sie immer noch auf Einschränkungen stoßen, sollten Sie sich darauf einstellen, dass Sie ein Projekt im Pool mit großer Konkurrenz erstellen müssen. In diesem Fall müssen Sie Risiken eingehen: etwas grundlegend Neues tun oder eine ungewöhnliche „Killer-Funktion“ anbieten, um sich vom Fluss monotoner Projekte abzuheben.
Hackathon Nummer 2. Unmögliche Aufgaben
Der Hackathon in Amadore versprach interessant zu werden. Das Sponsorenunternehmen, ein bedeutender Hersteller von Telefonen, begann 4 Monate vor dem Veranstaltungstermin mit den Vorbereitungen. In sozialen Netzwerken fand eine soziale Veranstaltung statt. Potenzielle Teilnehmer mussten einen technischen Test bestehen und über ihre früheren Projekte schreiben, um für diese Veranstaltung ausgewählt zu werden. Der Preispool war angenehm groß. Einige Tage vor dem Hackathon hielten die Mentoren eine technische Sitzung ab, damit die Teilnehmer Zeit hatten, sich mit den Besonderheiten der Branche auseinanderzusetzen.
Bei der Veranstaltung stellten die Organisatoren einen 8-Gbit-Gerätedatensatz mit einer binären Klassifizierung der Pannen zur Verfügung. Sie sprachen über die Kriterien für die Bewertung von Projekten - die Qualität der Klassifizierung, die Kreativität beim Erstellen von Features, die Fähigkeit, in einem Team zu arbeiten usw. Das ist einfach Pech - für 8 GB „Features“ gab es nur 20 Beispiele im Zug und 5 im Test. Der letzte Nagel im Deckel des Sarges des Hackathons erzielte ein Gesicht in den Daten: Die am Mittwoch eingegangenen Ausrüstungsprotokolle enthielten einen Fehler im Betrieb der Ausrüstung, und die am Donnerstag erstellten enthielten keine (übrigens wussten nur zwei Teams davon, und beide stammten aus Russland - der Heimat erfahrener Datamener ) Obwohl es nicht hilfreich war, die wahren Bezeichnungen des Tests zu kennen, um die Antwort maßzuschneidern, war die Aufgabe unlösbar. Die Organisatoren haben nicht das gewünschte Ergebnis erzielt, die Teilnehmer haben viel Zeit damit verbracht, eine schlecht komponierte Aufgabe zu lösen. Der Hackathon war ein Fehlschlag.
Moral
Führen Sie technische Prüfungen von Aufgaben durch und überprüfen Sie Ihre Aufgaben auf Angemessenheit. Es ist besser, eine vorläufige Prüfung zu viel zu bezahlen (in diesem Fall würde jedes Rechenzentrum sofort darauf hinweisen, dass es unmöglich ist, dieses Problem zu lösen), als es später zu bereuen.
In diesem Fall hat das Unternehmen zusätzlich zu der aufgewendeten Zeit und dem aufgewendeten Geld ein Treuhanddarlehen von potenziellen Kandidaten verloren, und es ist möglich, über die Ergebnisse zu schreiben. Übrigens sollten nicht nur die Teilnehmer, sondern auch das Unternehmen über erfolgreiche Ergebnisse schreiben und den Hackathon aus Sicht der PR maximal realisieren. Leider tun dies nicht alle Unternehmen und beschränken sich nur auf eine Nachankündigung und ein paar Fotos von der Veranstaltung auf Twitter.
Hackathon Nummer 3. Nimm es oder lass es
Zuletzt hat unser Team an einem Hackathon in Amsterdam teilgenommen. Da ich ausgebildeter Elektrotechniker bin (auf dem Gebiet der erneuerbaren Energiequellen), war das Thema nur für uns - Energie. Der Hackathon wurde in einem Online-Format durchgeführt: Wir erhielten eine Beschreibung der Aufgabe und einen Monat Zeit, um sie abzuschließen. Die Organisatoren wollten ein abgeschlossenes Projekt, das zur Steigerung der Energieeffizienz von Amsterdamer Häusern beitragen soll.
Wir haben ein Projekt durchgeführt, bei dem der Stromverbrauch vorhergesagt wird (zuvor habe ich an einem Wettbewerb zu diesem Thema teilgenommen, bei dem ich eine Near-Sota-Lösung erhalten habe, über die hier nachgelesen
werden kann ) und die Erzeugung durch ein Solarpanel. Basierend auf diesen Vorhersagen wird die Batterieleistung optimiert (diese Idee wurde teilweise aus meinem Master-Diplom übernommen). Unser Projekt stimmte sowohl mit der Aufgabe der Organisatoren (wie es uns damals schien) als auch mit der Politik der Amsterdamer Verwaltung im Bereich der erneuerbaren Energien für die kommenden Jahre gut überein.
Bei der Bewertung von Projekten wurde uns, wie vielen Teams, mitgeteilt, dass dies nicht den Erwartungen des Kunden entsprach, und wir mussten das Projekt wiederholen, wenn wir um einen Preis kämpfen wollten. Wir haben nichts wiederholt, haben uns damit abgefunden, zu besiegen. Von den vierzig teilnehmenden Teams sind wir nicht einmal in die Top 7 gekommen, obwohl die Auswahl der Organisatoren meiner Meinung nach ziemlich seltsam war. Zum Beispiel haben sie das letzte Team verpasst, das eine Anwendung zur Berechnung der Windgeschwindigkeit und der Sonnenstrahlung (SI) nach Smartphone-Sensoren erstellt hat: Mikrofon für Wind, Lichtsensor für SI. Der Feature-Killer hatte eine Klassifizierung von Hotdog / Nicht-Hotdog in drei Klassen: Sonne, Wind, Wasser und die Anzeige des entsprechenden Wikipedia-Artikels (
Demo ).
Lassen Sie uns für einen Moment die moralische Seite des Problems verlassen: Die Erpressung von Teilnehmern mit der Möglichkeit eines Sieges ist einfach unethisch. Da eine der Motive für die Teilnahme an Hackathons (insbesondere erfahrene Entwickler) die Umsetzung ihrer Ideen ist, können viele starke Teilnehmer die Veranstaltung einfach verlassen, nachdem sie solche Rückmeldungen erhalten haben (was nicht nur bei unserem Team, sondern auch bei einer Reihe anderer, die die Aktualisierung der Seite eingestellt haben, geschehen ist Ihres Projekts nach dem Hören des Mentors). Nehmen wir jedoch an, wir haben uns mit den Organisatoren einverstanden erklärt und unser Projekt an ihre Anforderungen angepasst. Was könnte als nächstes passieren?
Da die Organisatoren das „ideale Projekt“ selbst verstehen, werden uns alle Wünsche (und dementsprechend Änderungen) zu diesem Ideal führen. Die Teilnehmer werden ihre Zeit verbringen und es wird immer schwieriger für sie, sich zu weigern, weiter teilzunehmen (da sie bereits ihre Kraft investiert haben und es scheint, dass sie vorher nicht gewinnen können). In Wirklichkeit wird der Wettbewerb um Preise jedoch zunehmen, und die Teilnehmer müssen das Projekt zunehmend wiederholen, um Korrekturen von den Organisatoren zu erhalten, in der Hoffnung, einen Preis zu erhalten. Infolgedessen werden die Jungs, die im Rückblick keine Preise gewonnen haben, feststellen, dass sie ohne Geld freiberuflich tätig waren: Sie haben Änderungen am Kunden vorgenommen, aber gleichzeitig nichts dafür erhalten (außer natürlich der entsprechenden Erfahrung).
Moral
Oft helfen Wünsche und Rückmeldungen der Organisatoren dem Projekt. In diesem Fall sollten sich die Teilnehmer jedoch nicht auf den Rat von Mentoren verlassen, die lahm auf einem Stock sind. Wenn Sie von den Organisatoren das Feedback zu Ihrem Projekt im Sinne von „Nehmen Sie es weg, wir haben es nicht bestellt“ hören, kann Ihre Teilnahme am Hackathon als abgeschlossen angesehen werden.
Wenn Sie einen Hackathon mit einer klaren Vision des Projekts organisieren, aber nicht über die Fähigkeiten oder die Fähigkeit verfügen, es selbst umzusetzen, ist es besser, Ihre Vision in Form einer technischen Aufgabe für einen Freiberufler zu entwerfen. Andernfalls müssen Sie zweimal bezahlen - für den Hackathon und für die Dienste eines Freiberuflers.