vipink1203/hackathon-ideen

Was macht hackathon-ideen?

Wir entwickeln Ideen, die ein echtes Problem an seiner Ursache lösen, für eine bestimmte Person, gestützt auf Belege dafür, dass das Problem existiert, und basierend auf einer Einsicht: der nicht offensichtlichen Tatsache, die diese Lösung dort funktionieren lässt, wo übliche Ansätze scheitern. Klein und einfach ist willkommen; gewöhnlich nicht. Eine Idee verdient ihren Platz nur, wenn sie auch nach dem Hackathon noch von Bedeutung wäre und ein Jurymitglied sie nicht allein anhand des Track-Namens erraten hätte.

Ein Hackathon wird durch seine Bewertungskriterien, innerhalb seiner Deadline und durch einen Demo-Moment gewonnen: die wenigen Sekunden im Video oder Live-Demo, in denen ein Jurymitglied die funktionierende Sache sieht und versteht. Jede Tatsache über den Hackathon stammt von seinen offiziellen Seiten, zitiert mit Link.

Schritte

1. Das Briefing lesen. Von der offiziellen Hackathon-Seite, den Regeln und FAQ (nach dem Link fragen, falls nicht vorhanden), mit Quell-Links aufzeichnen: Tracks und Preise, Bewertungskriterien und deren Gewichtung, erforderliche oder Sponsor-Technologie, Teilnahmeberechtigung und disqualifizierende Regeln (Teamgröße, vorhandener Code, Region, Lizenzierung), Einreichungsanforderungen (Videolänge, Repository, Live-Demo, Dokumentation) sowie die Deadline mit der verbleibenden Zeit. Dann den Benutzer in maximal 3 Fragen bitten, was das Briefing nicht verraten kann: Teamgröße und -fähigkeiten, verfügbare Stunden sowie ein Bereich, den sie aus erster Hand kennen, oder ein Track, zu dem sie tendieren. Abgeschlossen, wenn jedes oben genannte Feld einen zitierten Wert hat oder als „nicht veröffentlicht“ markiert ist. Wenn keine Bewertungskriterien veröffentlicht sind, vier gleiche Kriterien verwenden, die in Hackathon-Bewertungsrastern üblich sind (Ideenoriginalität, technische Umsetzung, potenzielle Auswirkung, Design und Präsentation) und diese im Output als unseren Fallback kennzeichnen.
2. Die offensichtliche Liste schreiben. Vor jeglicher Recherche die 10 Ideen notieren, die die meisten Teams für diese Tracks und diese Technologie einreichen werden: die ersten Dinge, die jedem einfallen würden. Diese Ideen und alles, was eine leichte Abwandlung davon ist, werden in Schritt 5 gestrichen.
3. Echte Probleme finden. Dies ist der tiefgründigste Schritt; hier den größten Aufwand betreiben. Dorthin gehen, wo Menschen ihre Probleme in ihren eigenen Worten beschreiben, innerhalb der Bereiche, auf die die Tracks und das Fachwissen des Teams hinweisen: Foren, Subreddits, GitHub-Issues, Support- und Community-Threads, App-Store-Bewertungen, Berufsgruppen, öffentliche Beschwerden und Regulierungsberichte. Besonders auf Workarounds achten: Tabellenkalkulationen, Skripte, manuelle Doppelerfassung, Ausdrucke, Gruppenchats, bezahlte Assistenten, die die Arbeit einer Maschine erledigen; jeder Workaround markiert ein Problem, für das Menschen bereits mit ihrer Zeit bezahlen. Bei jedem Problem so lange nach dem „Warum“ fragen, bis eine strukturelle Ursache erreicht ist, nicht ein Symptom. Abgeschlossen, wenn die Notizen mindestens 10 verschiedene Probleme enthalten, jedes mit einer bestimmten Person und Situation, mindestens einem Zitat oder Datenpunkt mit Link, dem heutigen Workaround und der Ursache.
4. Das Feld recherchieren. Frühere Gewinner dieses Hackathons oder dieser Serie lesen (z. B. deren Projektgalerie auf Devpost), die letzten Veröffentlichungen des Sponsors und deren erklärte Wünsche für die erforderliche Technologie sowie alle öffentlichen Einreichungen dieser Ausgabe. Abgeschlossen, wenn die Notizen mindestens fünf frühere oder aktuelle Projekte und die erklärten Prioritäten des Sponsors auflisten, alle mit Links.
5. Generieren, dann hart streichen. Mindestens 20 Ideen schreiben, jede basierend auf einem Problem aus Schritt 3. Jede Idee benennt: die Person und Situation, den Beleg-Link, die Ursache, die sie beseitigt, die Einsicht, was sie tut, ihren Demo-Moment und welchen Beitrag die erforderliche Technologie leistet, den die Lösung nicht entbehren könnte. Dann jede Idee mit einem einzeiligen Grund streichen, die:
   • auf der offensichtlichen Liste steht oder eine leichte Abwandlung davon ist;
   • keine bestimmte Person und Situation nennen kann oder keinen Beleg-Link hat;
   • ein Symptom behandelt, während die Ursache bestehen bleibt;
   • eine dünne Hülle ist, bei der die erforderliche Technologie oder KI durch ein Formular, ein Suchfeld oder eine Vorlage mit geringem Verlust ersetzt werden könnte;
   • eine Einsicht hat, die jeder zuerst nennen würde;
   • einem bestehenden Produkt, einem früheren Gewinner oder einer aktuellen Einreichung sehr ähnelt (nach nächsten Nachbarn suchen und notieren);
   • gegen eine Regel verstößt oder mit den Fähigkeiten dieses Teams in der verbleibenden Zeit keinen funktionierenden Demo-Moment erreichen kann. Abgeschlossen, wenn jede Idee mit einem Grund gestrichen oder behalten wurde und mindestens fünf behalten sind; falls weniger überleben, zu Schritt 3 zurückkehren, um mehr Probleme zu finden, anstatt die Streichungen zu lockern.
6. Die Überlebenden bewerten. Jede behaltene Idee mit 1 bis 5 in jedem Bewertungskriterium bewerten, mit der Gewichtung des Hackathons und einer einzeiligen Begründung pro Punktzahl, plus drei eigenen Kriterien: Tiefe (Stärke der Belege und wie vollständig die Ursache beseitigt wird), Umsetzbarkeit in der verbleibenden Zeit und Demo-Stärke. Nach der gewichteten Bewertung plus Tiefe sortieren, Gleichstände nach Umsetzbarkeit auflösen.
7. Die Shortlist schreiben. Für die Top Drei schreiben:
   • Pitch: Ein Satz, den ein Jurymitglied wiederholen würde.
   • Das Problem: Die Person, die Situation, die Beleg-Zitate mit Links, der heutige Workaround und die Ursache.
   • Die Einsicht: Die nicht offensichtliche Tatsache und warum bestehende Werkzeuge sie übersehen.
   • Nächste Nachbarn: Die nächstgelegenen gefundenen Produkte oder Projekte und der konkrete Unterschied.
   • Ziel-Tracks: Tracks und Preise, für die die Idee konkurriert.
   • Bewertungen: Die Bewertungstabelle aus Schritt 6.
   • Demo-Skript: Was in den ersten 30 Sekunden des Videos passiert, das das Problem der Person und dann dessen Beseitigung zeigt.
   • Schnittlinie: Was für die Demo funktionieren muss und was nice-to-have ist, damit das Team weiß, was es fallen lassen kann, wenn die Zeit knapp wird.
   • Riskanteste Annahme: Die technische oder produktseitige Wette, die am wahrscheinlichsten scheitert, und ein kurzer Test (eine Stunde oder weniger), der sie vor der Entscheidung überprüft.

Output

Pro Hackathon eine Datei unter docs/hackathons/<event-slug>.md schreiben, bei späteren Läufen aktualisiert: das Briefing mit Links, die offensichtliche Liste, die Problem-Notizen mit Belegen, die Feldrecherche, alle generierten Ideen mit ihren Streichgründen, die Bewertungstabelle und die Shortlist. In der Sitzung die Shortlist und die Deadline anzeigen, dann den Benutzer bitten, eine Idee auszuwählen. Wenn sich das Team für eine Idee entscheidet, durchläuft sie das app-compliance-Skill, bevor sie von Personen außerhalb der Jury genutzt wird, und das showcase-Skill erstellt ihr Demo-Video und die README für die Einreichung.