Cómo redactar un reto que la gente quiera resolver

Un buen enunciado de reto nombra un problema real, a las personas que lo viven, por qué importa ahora, qué queda fuera de la mesa y qué hará el responsable con una buena respuesta, todo en una página. Es lo bastante concreto para que los equipos arranquen la primera mañana y lo bastante abierto para no dictar la solución. Los siete pasos siguientes te llevan hasta ahí en unas dos semanas de preparación.

Qué tiene que conseguir un enunciado de reto

El enunciado del reto es el documento más importante de cualquier hackathon, jam o reto de innovación abierta. Decide quién se inscribe, en qué trabaja, cómo puntúa el jurado y si algo sobrevive al evento. La mayoría fallan en una de dos direcciones:

• Demasiado amplio. «Mejorar la experiencia de cliente». Los equipos pasan el primer día eligiendo un problema y acaban con diez ideas inconexas que no se pueden comparar.
• Demasiado estrecho. «Construir un chatbot para el call center». La solución ya está elegida. Los equipos se convierten en proveedores sin sueldo y las mejores ideas nunca aparecen.

El objetivo está en medio: un problema claro, una persona clara, restricciones reales y libertad en el cómo. Es la versión, a escala de reto, del trabajo que describimos en cómo redactar un enunciado del problema; la diferencia es que un enunciado de reto tiene que funcionar para desconocidos que nunca han estado dentro de tu organización.

Siete pasos para redactar el reto

1. Empieza por el responsable, no por el tema. Encuentra a la persona que convive con el problema y tiene autoridad para actuar sobre una respuesta. Entrevístala durante una hora. Pregúntale qué sigue fallando, qué ha probado ya, qué no puede cambiar y qué haría el lunes con una buena idea. Si nadie encaja en esa descripción, para: un reto sin responsable produce un trabajo que nadie recibe, que es lo primero que tratamos en 9 errores que los organizadores de hackathons siguen repitiendo.

2. Baja un nivel por debajo del síntoma. Lo primero que describe el responsable suele ser un síntoma: «han subido las quejas», «las solicitudes tardan demasiado». Usa un árbol de problemas o una ronda de cinco porqués para encontrar la causa que sea a la vez real y abordable en el tiempo de que disponen los equipos. «Las solicitudes tardan demasiado» podría convertirse en «los solicitantes presentan expedientes incompletos y el caso se queda en cola esperando un documento que falta». Eso sí es algo para lo que un equipo puede diseñar.

3. Nombra a las personas afectadas, en palabras sencillas. Un reto sin persona es abstracto. ¿Quién vive exactamente el problema, y en qué momento? «Solicitantes primerizos que rellenan el formulario en el móvil, normalmente de noche» es mucho más útil que «clientes». Dos o tres entrevistas a partes interesadas con estas personas, aunque sean breves, te darán el lenguaje y los detalles que hacen que el enunciado se sienta real. Un enunciado de punto de vista (usuario, necesidad, insight) es una buena forma de sostenerlo.

4. Conviértelo en una pregunta que invite a muchas respuestas. Reformula el problema como una pregunta ¿Cómo podríamos?. Ponla a prueba: ¿podrían diez equipos distintos dar diez buenas respuestas realmente diferentes? Si solo encaja una respuesta, es demasiado estrecha. Si encaja cualquiera, es demasiado amplia. «¿Cómo podríamos ayudar a los solicitantes primerizos a presentar un expediente completo a la primera?» pasa la prueba. «¿Cómo podríamos construir un verificador de documentos?», no. «¿Cómo podríamos transformar los servicios públicos?», tampoco.

5. Escribe las restricciones con honestidad. Las restricciones no son enemigas de la creatividad; la vaguedad sí. Enumera lo que no puede cambiar (legislación, sistemas troncales, techo presupuestario, plazos), lo que está disponible (conjuntos de datos, API, tiempo del personal, usuarios reales disponibles) y lo que queda explícitamente fuera del alcance. Los equipos respetan un límite claro. Lo que les frustra es descubrirlo en el pitch, cuando alguien del jurado dice «eso no lo podríamos hacer nunca».

6. Explica por qué importa y qué pasa después. Dedica una o dos frases a por qué este problema importa ahora, mejor en boca de las personas afectadas que de los documentos de estrategia. Después di claramente a qué se compromete el responsable: un piloto en un servicio concreto, un desarrollo de 90 días con un equipo, una prueba financiada. Esto es lo que hace que la gente quiera resolver tu reto y no el de otro. Si el compromiso es modesto, dilo con honestidad. Los equipos prefieren un siguiente paso pequeño y real a una promesa vaga de «posible implantación».

7. Pruébalo con alguien de fuera. Entrega el borrador a dos o tres personas que no sepan nada del problema, idealmente el tipo de gente que esperas que participe. Pídeles que te expliquen el reto con sus propias palabras y que digan la primera idea que probarían. Si lo malinterpretan, o todas las ideas son iguales, reescríbelo. Un mapa de supuestos de lo que el enunciado da por hecho es una última comprobación útil.

Una plantilla de una página

Usa estos apartados, en este orden, y que todo quepa en una página:

1. El reto: la pregunta ¿Cómo podríamos?, en una frase.
2. A quién afecta: las personas, el momento, una cita si la tienes.
3. Lo que sabemos: de tres a cinco hechos u observaciones, con su origen.
4. Por qué ahora: una o dos frases.
5. Lo que puedes usar: datos, sistemas, personas disponibles.
6. Lo que queda fuera de la mesa: las restricciones, con honestidad.
7. Cómo es un buen resultado: los criterios de evaluación, publicados ya (consulta criterios de evaluación que eligen al ganador correcto).
8. Qué pasa después: el compromiso del responsable, con nombre.

Qué hacer y qué no

Qué hacer

• Escribe en el lenguaje de las personas afectadas, no en el de tu estrategia.
• Incluye al menos un dato que los equipos no podrían haber adivinado.
• Publica los criterios y el compromiso posterior al evento en el mismo documento.
• Haz que el responsable presente el reto en persona la primera mañana.

Qué no hacer

• No nombres la tecnología. «Con IA» o «con blockchain» en la pregunta estrecha las respuestas antes de que nadie haya pensado.
• No ocultes restricciones para que el reto parezca más emocionante.
• No combines dos problemas en un enunciado para contentar a dos patrocinadores; redacta dos retos o elige uno.
• No uses siglas internas ni nombres de departamentos que la gente de fuera no conoce.

Ejemplo ilustrativo

Ilustrativo. La red de bibliotecas municipales de un país del norte de Europa quería lanzar un reto abierto sobre «la biblioteca del futuro». El primer borrador decía: «¿Cómo podríamos reinventar la biblioteca para la era digital?». Al probarlo con tres estudiantes salieron tres versiones de la misma app.

El equipo volvió a hablar con la responsable de servicios de sucursales, que gestionaba el presupuesto para cambios en las sedes. En una hora descubrieron el problema real: las visitas de adolescentes por la tarde habían caído, mientras las sucursales seguían abiertas hasta las ocho con personal que tenía poco que hacer. Una sesión de cinco porqués con el personal de las sucursales apuntó a una causa: los adolescentes veían la biblioteca como un lugar para estudiar en silencio durante los exámenes y nada más.

El enunciado revisado decía: «¿Cómo podríamos dar a jóvenes de 14 a 18 años un motivo para ir a su biblioteca de barrio una tarde cualquiera entre semana?». Restricciones: sin obras, solo el personal existente, un pequeño presupuesto para materiales. Disponible: dos sucursales dispuestas a probar, cinco adolescentes disponibles durante el evento, datos de visitas por hora de los dos últimos años. Compromiso: la responsable de servicios de sucursales llevaría la idea ganadora a dos sucursales durante un trimestre escolar. Se presentaron veintidós equipos; las ideas fueron desde un intercambio de ayuda con los deberes hasta un repair café por las tardes. Todas podían compararse con la misma pregunta.

Preguntas frecuentes

¿Qué diferencia hay entre un enunciado del problema y un enunciado de reto? Un enunciado del problema describe lo que falla, sobre todo para el equipo que es responsable de ello. Un enunciado de reto convierte ese problema en una invitación para personas de fuera del equipo: añade la pregunta, las restricciones, los recursos y lo que pasará con una buena respuesta.

¿Qué extensión debe tener el reto de un hackathon? Una página. La pregunta en sí debe ser una sola frase. Si necesitas más de una página, probablemente tienes dos retos o estás explicando tu organización en lugar del problema.

¿Conviene dar ejemplos de posibles soluciones en el reto? Normalmente no. Los ejemplos anclan a los equipos, y muchos se limitarán a construir el ejemplo. Si no queda otra, da dos muy distintos y deja claro que son ilustraciones, no expectativas.

Por dónde seguir

El reto forma parte de un diseño más amplio; consulta cómo organizar un hackathon que produzca algo real y el mapa de formatos en hackathons, jams y retos: todos los tipos explicados. Para hacer bien la preparación, usa las guías de árbol de problemas, cinco porqués, enunciado de punto de vista y ¿Cómo podríamos?.