В Ich habe mir mehrere Gründe für die Teilnahme an Hackathons angesehen. Die Motivation, viel Neues zu lernen und wertvolle Preise zu gewinnen, zieht viele an, doch oft endet die Veranstaltung aufgrund von Fehlern der Veranstalter oder Sponsorfirmen erfolglos und die Teilnehmer gehen unzufrieden zurück. Damit solche unangenehmen Vorfälle seltener passieren, habe ich diesen Beitrag geschrieben. Der zweite Teil der Trilogie ist den Fehlern der Veranstalter gewidmet.
Der Beitrag ist wie folgt aufgebaut: Zu Beginn spreche ich über das Ereignis, erkläre, was schief gelaufen ist und wozu es geführt hat (oder langfristig führen kann). Dann gebe ich meine Einschätzung ab, was passiert und was ich tun würde, wenn ich der Organisator wäre. Da ich an allen Veranstaltungen teilgenommen habe, kann ich die wahre Motivation der Veranstalter nur vermuten. Daher kann meine Einschätzung einseitig sein. Ich schließe nicht aus, dass einige Punkte, die mir falsch erscheinen, tatsächlich so gemeint waren.
An einem bestimmten Punkt könnte der Leser denken, dass der Autor nach einem Kampf beschlossen hat, mit den Fäusten zu wedeln. Aber ich kann Ihnen versichern, dass dies nicht der Fall ist. Bei einigen der aufgeführten Hackathons konnte ich einen Preis gewinnen, was uns jedoch nicht daran hindert, zu sagen, dass die Veranstaltung schlecht organisiert war.
Aus Respekt vor den Veranstaltern und Teilnehmern wird im Beitrag auf Hinweise auf bestimmte Unternehmen verzichtet. Ein aufmerksamer Leser kann jedoch erraten (oder Google), um wen es sich handelt.
Hackathon Nr. 1. Strenge Grenzen
Vor sechs Monaten organisierte ein großes Telekommunikationsunternehmen einen Hackathon zum Thema Datenanalyse. 20 Teams konkurrierten um den Preisfonds. Bei der Veranstaltung wurde ein Datensatz zur Analyse bereitgestellt, der Informationen über Anrufe beim Support-Service des Unternehmens, Aktivitäten in sozialen Netzwerken und codierte Informationen über Benutzer (Geschlecht, Alter usw.) enthielt. Der interessanteste Teil des Datensatzes – Benutzernachrichten und Bedienerantworten (Textdaten) – war ziemlich verrauscht und musste für weitere Arbeiten bereinigt werden.
Die Organisatoren stellten sich die Aufgabe, 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 vorzuschlagen, die nichts mit dem Datensatz zu tun hatten. Leider waren die bereitgestellten Daten recht „dürftig“: Es war schwierig, interessante Produkte von ihnen zu erhalten, und aus der Kommunikation mit Mentoren wurde deutlich, dass viele der vorgeschlagenen Ideen bereits umgesetzt werden (oder in naher Zukunft umgesetzt werden). im Unternehmen.
Infolgedessen entwickelte die überwiegende Zahl der Teams (15 von 20) Chatbots. Während der Auftritte unterschied sich die Entscheidung einer Mannschaft kaum von der vorherigen. Unfähig, es zu ertragen, fragte einer der Jurymitglieder das nächste Team auf der Bühne: „Was, Leute, habt ihr auch einen Chatbot?“ Infolgedessen gingen von den drei Preisen der erste und zweite Platz an die Teams, die keine Chatbots entwickelten.
Nehmen wir zum Vergleich einen Hackathon, den ein internationales Beratungsunternehmen vor zwei Jahren für die Firma Zvezdochka organisiert hat. Da die Besonderheiten der Aktivitäten des Unternehmens Zvezdochka vielen Hackathon-Teilnehmern unbekannt waren, sprachen die Organisatoren zu Beginn der Veranstaltung über die Kennzahlen, die im Unternehmen verwendet werden. Anschließend wurden sechs Datensätze unterschiedlichen Typs bereitgestellt: Text, Tabellen, Geolokalisierung – es gab Handlungsspielraum für alle Teilnehmer. Die Organisatoren haben die Verwendung zusätzlicher Datensätze nicht verboten und solche Initiativen sogar unterstützt. Im Finale des Wettbewerbs konkurrierten zehn Teams mit unterschiedlichen Lösungen um den Hauptpreis, wobei alle Teams (trotz fehlender Einschränkungen) die vom Unternehmen bereitgestellten Daten nutzten, was auf ein gutes Potenzial für den Erhalt von Qualitätsprodukten hinwies.
Moral
Es besteht keine Notwendigkeit, den kreativen Fluss der Teilnehmer einzuschränken. Als Veranstalter müssen Sie Materialien bereitstellen und auf seine Vision und Professionalität vertrauen. Wenn Sie an einem Hackathon teilnehmen, sollten Sie etwaige Beschränkungen oder Verbote beunruhigen. Normalerweise ist dies ein Beweis für schlechte Organisation (ein Beispiel aus dem wirklichen Leben ist der ständige Wunsch, irgendwo einen Zaun zu errichten). Wenn Sie auf Einschränkungen stoßen, müssen Sie damit rechnen, dass Sie ein Projekt in einem Pool mit viel Konkurrenz erstellen müssen. In diesem Fall sind Sie gezwungen, Risiken einzugehen: Machen Sie etwas grundlegend Neues oder bieten Sie ein ungewöhnliches „Killer-Feature“ an, um aus dem Strom der eintönigen Projekte herauszustechen.
Hackathon Nr. 2. Unmögliche Aufgaben
Der Hackathon in Amador versprach interessant zu werden. Das Sponsorunternehmen, ein großer Telefonhersteller, begann vier Monate vor dem Veranstaltungstermin mit den Vorbereitungen. Die PR für die Veranstaltung wurde in sozialen Netzwerken betrieben; potenzielle Teilnehmer mussten einen technischen Test bestehen und über ihre vergangenen Projekte schreiben, um für diese Veranstaltung ausgewählt zu werden. Der Preisfonds war erfreulich groß. Einige Tage vor dem Hackathon hielten die Mentoren eine technische Sitzung ab, damit die Teilnehmer Zeit hatten, die Besonderheiten der Branche zu verstehen.
Bei der Veranstaltung selbst stellten die Organisatoren einen Datensatz von Geräteprotokollen mit einem Volumen von 8 GB zur Verfügung, die Aufgabe bestand in einer binären Klassifizierung von Ausfällen. Sie sprachen über die Kriterien zur Bewertung von Projekten – Qualität der Klassifizierung, Kreativität bei der Erstellung von Features, Fähigkeit zur Teamarbeit usw. Es ist einfach Pech – für 8 GB an „Features“ waren nur 20 Exemplare im Zug und 5 im Test. Der letzte Nagel im Sarg des Hackathons kam aus den Daten: Die am Mittwoch eingegangenen Geräteprotokolle enthielten einen Fehler im Betrieb der Geräte, die am Donnerstag erstellten jedoch nicht (übrigens wussten nur zwei Teams davon, und beide kamen aus Russland, der Heimat erfahrener Data-Miner. Obwohl selbst die Kenntnis der wahren Bezeichnungen des Tests nicht zur Lösung der Antwort beitrug, war die Aufgabe unlösbar. Die Organisatoren erzielten nicht das gewünschte Ergebnis; die Teilnehmer verbrachten viel Zeit damit, ein schlecht konzipiertes Problem zu lösen. Der Hackathon war ein Misserfolg.
Moral
Führen Sie technische Überprüfungen von Aufgaben durch und überprüfen Sie Ihre Aufgaben auf Angemessenheit. Es ist besser, für eine Voruntersuchung zu viel zu bezahlen (in diesem Fall würde jeder Datenwissenschaftler sofort darauf hinweisen, dass es unmöglich ist, dieses Problem zu lösen), als es später zu bereuen.
In diesem Fall verschwendete das Unternehmen nicht nur Zeit und Geld, sondern verlor auch an Glaubwürdigkeit bei potenziellen Kandidaten und schrieb möglicherweise über die Ergebnisse. Über erfolgreiche Ergebnisse sollten übrigens nicht nur die Teilnehmer, sondern auch das Unternehmen schreiben und so den Hackathon aus PR-Sicht maximieren. Leider tun dies nicht alle Unternehmen und beschränken sich auf einen Ankündigungsbeitrag und ein paar Fotos von der Veranstaltung auf Twitter.
Hackathon Nr. 3. Nimm es oder lass es
Zuletzt nahm unser Team an einem Hackathon in Amsterdam teil. Da ich gelernter Elektrotechniker bin (im Bereich erneuerbare Energien), war das Thema genau das Richtige für uns – Energie. Der Hackathon fand online statt: Wir bekamen eine Beschreibung der Aufgabe und einen Monat Zeit, um sie zu erledigen. Die Organisatoren wollten ein fertiges Projekt sehen, das dazu beitragen würde, die Energieeffizienz von Amsterdamer Häusern zu steigern.
Wir haben ein Projekt erstellt, bei dem der Stromverbrauch vorhergesagt wurde (davor habe ich an einem Wettbewerb zu diesem Thema teilgenommen, bei dem ich eine sotanahe Lösung erhalten habe, über die Sie lesen können). ) und Erzeugung durch Solarpanel. Basierend auf diesen Vorhersagen wird die Batterieleistung optimiert (diese Idee stammt teilweise aus meiner Masterarbeit). Unser Projekt stimmte sowohl mit den Anweisungen der Organisatoren (wie es uns damals schien) als auch mit der Politik der Amsterdamer Verwaltung im Bereich der erneuerbaren Energiequellen für die kommenden Jahre gut überein.
Bei der Bewertung von Projekten wurde uns, wie vielen anderen Teams auch, mitgeteilt, dass dies nicht den Erwartungen des Kunden entsprochen habe, und hinzugefügt, dass wir das Projekt wiederholen müssten, wenn wir um den Preis konkurrieren wollten. Wir haben nichts wiederholt und die Niederlage akzeptiert. Von den vierzig teilnehmenden Teams haben wir es nicht einmal unter die Top 7 geschafft, obwohl mir die Wahl der Veranstalter eher seltsam vorkam. Sie führten beispielsweise das Team ins Finale, das eine Anwendung zur Berechnung von Windgeschwindigkeit und Sonneneinstrahlung (SI) mithilfe von Daten von Smartphone-Sensoren entwickelte: ein Mikrofon für den Wind, ein Lichtsensor für den SI. Das Killerfeature war die Hotdog/Nicht-Hotdog-Einteilung in drei Klassen: Sonne, Wind, Wasser und Anzeige des entsprechenden Artikels auf Wikipedia ().
Lassen wir die moralische Seite des Themas für einen Moment außer Acht: Teilnehmer mit der Möglichkeit eines Sieges zu erpressen, ist einfach unethisch. Da eine der Motivationen für die Teilnahme an Hackathons (insbesondere für erfahrene Entwickler) die Verwirklichung ihrer Ideen ist, können viele starke Teilnehmer die Veranstaltung einfach verlassen, nachdem sie ein solches Feedback gehört haben (was nicht nur unserem Team passiert ist, sondern auch einer Reihe anderer, die aufgehört haben). Aktualisierung ihres Seitenprojekts, nachdem sie dem Mentor zugehört haben). Nehmen wir jedoch an, wir haben den Wünschen der Organisatoren zugestimmt und unser Projekt an ihre Anforderungen angepasst. Was könnte als nächstes passieren?
Da die Organisatoren ein eigenes Verständnis des „idealen Projekts“ haben, werden uns alle Wünsche (und damit auch Änderungen) zu diesem Ideal führen. Die Konkurrenten werden ihre Zeit verschwenden und es wird für sie immer schwieriger, eine weitere Teilnahme abzulehnen (da sie bereits ihre Anstrengungen investiert haben und es scheint, dass sie nur noch ein kleines Stück vom Sieg entfernt sind). Aber in Wirklichkeit wird der Wettbewerb um Preise zunehmen, und die Teilnehmer werden in der Hoffnung, einen Preis zu gewinnen, zunehmend das Projekt auf der Grundlage von Änderungen der Organisatoren wiederholen müssen. Infolgedessen werden die Jungs, die keine Preise entgegengenommen haben, im Nachhinein verstehen, dass sie ohne Geld an der freiberuflichen Tätigkeit teilgenommen haben: Sie haben Änderungen für den Kunden vorgenommen, dafür aber keine Gegenleistung erhalten (außer der entsprechenden Erfahrung, von Kurs).
Moral
Oftmals kommen Wünsche und Rückmeldungen der Veranstalter dem Projekt zugute. Gleichzeitig sollten sich die Teilnehmer jedoch nicht wie ein Lahmer am Stock auf die Ratschläge von Mentoren verlassen. Wenn Sie von den Organisatoren eine Rückmeldung zu Ihrem Projekt im Sinne von „Nehmen Sie es weg, das haben wir nicht bestellt“ erhalten, kann Ihre Teilnahme am Hackathon als abgeschlossen betrachtet werden.
Wenn Sie einen Hackathon mit einer klaren Vision für das Projekt organisieren, aber nicht über die Fähigkeiten oder die Fähigkeit verfügen, es selbst umzusetzen, dann ist es besser, Ihre Vision in Form von technischen Spezifikationen für einen Freelancer zu formalisieren. Andernfalls müssen Sie doppelt bezahlen – für den Hackathon und für die Leistungen des Freelancers.
Source: habr.com