Hackeando el Hackathon

A lo largo de los últimos meses hemos estado presentes en varios hackathons alrededor de México como organizadores, mentores y jueces. Lo que nos ha llevado a observar varios anti-patrones que los participantes repiten en cada evento, y que podríamos modificar para tener mejores resultados.

1 Desconexión total con la raíz del problema

MAL

La falla más importante que he observado en algunos equipos es que no concentran su trabajo alrededor de una clara definición del problema (o área de oportunidad). Basta con acercarse y preguntarles: “¿qué problema van a resolver?”, a lo que contestan “Vamos a hacer una plataforma que...”. Parece obvio, pero nuestro proceso cognitivo busca salidas fáciles, y la mayoría de las veces corre por la primera idea “cool” que evalúa. Les presento al solucionismo.

CONSEJO

En la mayoría de los eventos, además de mentores, existen expertos en el dominio de ciertos problemas, p.ej. organizaciones civiles o dependencias de gobierno que entienden muy bien lo que necesitan y buscan estos espacios para encontrar makers. Acércate a ellos, ya que evaluar un problema desde la perspectiva del experto logrará que la solución que propongas no tenga disonancia; velo como una validación del modelo.

Más importante aún es definir el problema antes de pensar en cualquier solución. Como bonus, maneja sesiones de brainstorming en silencio para que la discusión no sea guiada por el que habla más. Desde hace poco estoy implementando en mis equipos el design sprint de Google Ventures para sacar el mayor provecho a las sesiones de ideas, sin contaminar la dirección de este espacio de creatividad.

2 La lluvia de ideas fatiga al equipo

MAL

Uno de los anti-patrones que más dañan el desempeño del equipo es tener la sesión inicial de brainstorming el día del evento. Además de hacer tambalear al equipo de un lado para otro, este proceso genera incertidumbre y es agotador por naturaleza. Las discusiones se pueden extender por horas y es difícil empezar a trabajar un ciclo de más de 24 horas después de una sesión como ésta.

CONSEJO

Por experiencia personal, los mejores resultados los he tenido cuando nos reunimos un día antes y definimos el alcance del proyecto; de tal manera que al inicio del hackathon directamente comenzamos a trabajar, aprovechando así la energía para construir el prototipo o prueba de concepto.

3 La fiebre de oro

MAL

Yo también fui víctima de la fiebre de oro del consumer web y las app stores. Cuentos de hadas de cómo una app o plataforma cambió el mundo al tener millones de usuarios. Lo que he visto en la mayoría de las propuestas es que tratan de masificar la solución para que tenga resultado. Cuando les cuestiono: “¿cómo me vas a convencer de utilizar un nuevo app, cuando ya tengo cientos en mi teléfono?”, el equipo contesta con cliché como “gamificar”, “viralizar”, y un sinfín de growth hacks.

CONSEJO

La tecnología es una herramienta, y en ciertos contextos y nichos una muy útil, una que hace más eficiente el trabajo, automatiza ciertos procesos y genera riqueza. Darás en el clavo cuando la solución resuelva claramente el problema de una audiencia en particular. P.ej. recientemente un equipo tuvo una propuesta interesante para monitorear el desempeño del conductor de ciertas rutas de autobuses. Su propuesta original consistía en una app móvil con un diseño y gamification tan atractivo, que aquellos usuarios del transporte público con iPhone no se resistirían en generar datos importantes para el sistema de transporte. ¿Por qué no mejor enfocarse en un grupo de inspectores del servicio? Bastaría con exponer el caso de negocio a las autoridades competentes, en lugar de convencer a la minoría de la población que porta iPhone. De esta manera tendríamos mejores resultados con 10 inspectores que con 10,000 usuarios regulares.

UPDATE:
Este artículo se centra particularmente en los hackathons orientados a resolver ciertas temáticas, como open data, open government, etc. El hackathon por naturaleza es un evento libre y sólo pretende reunir gente para crear cosas.