Ideas de hackathones
Creamos ideas que resuelven un problema real en su causa raíz, para una persona específica, respaldadas por evidencia de que el problema existe, y apoyadas en un detalle clave (insight): el hecho no obvio que hace que esta solución funcione donde los enfoques habituales fallan. Lo pequeño y simple es bienvenido; lo común no. Una idea merece un lugar solo si sigue siendo relevante después del hackathon, y si un juez no podría haberla adivinado solo por el nombre de la pista.
Un hackathon se gana con sus criterios de evaluación, dentro de su plazo, a través de un momento demo: los pocos segundos del video o demo en vivo donde un juez ve la cosa funcionar y la entiende. Cada hecho sobre el hackathon proviene de sus páginas oficiales, citado con un enlace.
Pasos
- Lee el brief. Desde la página oficial del hackathon, reglas y FAQ (pide el enlace si no lo tienes), registra con enlaces a las fuentes: pistas y premios, criterios de evaluación y sus pesos, tecnología requerida o del patrocinador, elegibilidad y reglas que puedan descalificar (tamaño del equipo, código preexistente, región, licencias), requisitos de envío (duración del video, repositorio, demo en vivo, texto), y la fecha límite con el tiempo restante. Luego pregunta al usuario, en máximo 3 preguntas, lo que el brief no puede decirte: tamaño del equipo y habilidades, horas disponibles, y cualquier dominio que conozcan de primera mano o una pista hacia la que se inclinen. Hecho cuando cada campo anterior tenga un valor citado o esté marcado como "no publicado". Cuando no se publiquen criterios de evaluación, usa cuatro criterios iguales comunes en las rúbricas de hackathones (originalidad de la idea, implementación técnica, impacto potencial, diseño y presentación), y etiquétalos como nuestro respaldo en la salida.
- Escribe la lista obvia. Antes de cualquier investigación, escribe las 10 ideas que la mayoría de los equipos presentarán para estas pistas y esta tecnología: lo primero que cualquiera diría. Estas ideas, y cualquier variación ligera de ellas, se eliminan en el paso 5.
- Encuentra problemas reales. Este es el paso más profundo; dedica el mayor esfuerzo aquí. Ve a donde las personas describen sus problemas con sus propias palabras, dentro de los dominios que señalan las pistas y el conocimiento de primera mano del equipo: foros, subreddits, issues de GitHub, hilos de soporte y comunidad, reseñas de tiendas de aplicaciones, grupos profesionales, quejas públicas e informes regulatorios. Busca especialmente soluciones alternativas (workarounds): hojas de cálculo, scripts, doble entrada manual, impresiones, chats grupales, asistentes pagados haciendo el trabajo de una máquina; cada solución alternativa marca un problema por el que la gente ya paga con tiempo. Para cada problema, pregunta por qué hasta llegar a una causa estructural, no un síntoma. Hecho cuando las notas contengan al menos 10 problemas distintos, cada uno con una persona y situación específica, al menos una cita o dato con un enlace, la solución alternativa que usan hoy, y la causa raíz.
- Investiga el campo. Lee ganadores anteriores de este hackathon o serie (su galería de proyectos, por ejemplo en Devpost), los lanzamientos recientes del patrocinador y sus deseos declarados para la tecnología requerida, y cualquier envío público ya existente en esta edición. Hecho cuando las notas enumeren al menos cinco proyectos pasados o actuales y las prioridades declaradas del patrocinador, todo con enlaces.
- Genera, luego recorta sin piedad. Escribe al menos 20 ideas, cada una construida a partir de un problema del paso 3.
Cada idea nombra: la persona y situación, el enlace de evidencia, la causa raíz que elimina, el detalle clave (insight), lo que hace, su momento demo, y lo que la tecnología requerida aporta que la solución no podría hacer sin ello.
Luego elimina, con una razón de una línea cada una, toda idea que:
- esté en la lista obvia o sea una variación ligera de ella;
- no pueda nombrar una persona y situación específica, o no tenga un enlace de evidencia;
- trate un síntoma mientras la causa raíz permanece;
- sea una capa delgada, donde la tecnología requerida o IA podría ser reemplazada por un formulario, un cuadro de búsqueda o una plantilla con poca pérdida;
- tenga un detalle clave (insight) que cualquiera diría primero;
- coincida estrechamente con un producto existente, un ganador anterior o un envío actual (busca sus vecinos más cercanos y regístralos);
- rompa una regla, o no pueda alcanzar un momento demo funcional en el tiempo restante con las habilidades de este equipo. Hecho cuando cada idea esté eliminada con una razón o conservada, y al menos cinco estén conservadas; cuando sobrevivan menos, vuelve al paso 3 para más problemas en lugar de aflojar los recortes.
- Puntúa los supervivientes. Puntúa cada idea conservada del 1 al 5 en cada criterio de evaluación, con los pesos del hackathon y una justificación de una línea por puntuación, más tres propios: profundidad (fortaleza de la evidencia y qué tan completamente elimina la causa raíz), factibilidad de construcción en el tiempo restante, y fortaleza del demo. Ordena por la puntuación ponderada de evaluación más profundidad, desempatando por factibilidad de construcción.
- Escribe la shortlist. Para las tres mejores, escribe:
- Pitch: una frase que un juez repetiría.
- El problema: la persona, la situación, las citas de evidencia con enlaces, la solución alternativa actual, y la causa raíz.
- El detalle clave (insight): el hecho no obvio, y por qué las herramientas existentes lo pasan por alto.
- Vecinos más cercanos: los productos o proyectos existentes más parecidos encontrados, y la diferencia concreta.
- Objetivos: pista y premios por los que compite.
- Puntuaciones: la tabla de puntuación del paso 6.
- Guión demo: lo que sucede en los primeros 30 segundos del video, mostrando el problema de la persona y luego su eliminación.
- Límite de corte (cut line): lo que debe funcionar para el demo, y lo que es bueno tener, para que el equipo sepa qué dejar de lado cuando el tiempo se acorte.
- Supuesto más arriesgado: la apuesta técnica o de producto con más probabilidades de fallar, y un spike de una hora o menos que la ponga a prueba antes de comprometerse.
Salida
Escribe un archivo por hackathon en docs/hackathons/<event-slug>.md, actualizado en el lugar en ejecuciones posteriores: el brief con enlaces, la lista obvia, las notas del problema con evidencia, la investigación de campo, todas las ideas generadas con sus razones de eliminación, la tabla de puntuación y la shortlist.
En la sesión, muestra la shortlist y la fecha límite, luego pide al usuario que elija una idea.
Cuando el equipo se comprometa con una idea, pasa por el skill app-compliance antes de que alguien fuera de los jueces la use, y el skill showcase hace su video demo y README para el envío.