Por Manu Fernández, de la agencia Human Scale City
En 2012, de manera bastante intuitiva, impulsé una serie de eventos, UrbApps, con la idea de hackear los hackatones. En paralelo a algunos primeros textos que cuestionaban el modelo inicial de los hackatones cívicos o urbanos (On hackatones and solutionism o Three Problems With Civic Hackatones) queríamos establecer una metodología para diseñar mejor las fases previas y posteriores a este tipo de encuentros, normalmente centrados en una actividad muy enfocada a la producción en un corto periodo de tiempo. Desde entonces, se ha seguido profundizando en esa línea crítica sobre el planteamiento tradicional de los hackatones y sus impactos reales.
En The Data Revolution: Big Data, Open Data, Data Infrastructures and Their Consequences (un magnífico libro de Rob Kitchin) se mencionan un par de artículos que leí en su momento, You Can’t Just Hack Your Way to Social Change, de Jake Porway y Hacking the hackathon, de Shauna Gordon-McKeon. Ambos destacan factores que estaban detrás de esas primeras inquietudes sobre cómo rediseñar los hackatones. Esto se puede relacionar con ideas como el solucionismo, el eventismo o el fetichismo tecnológico.
El segundo de los artículos es especialmente claro sobre algunas de las debilidades de este tipo de eventos: falta de diversidad en el perfil de los participantes, escasa atención al potencial de estas actividades como generadoras de miradas más amplias sobre la cuestión que se aborda, dificultades para mantener los procesos en el tiempo y la escasa conexión con las comunidades locales.
A continuación presento tres recomendaciones para repensar los hackatones:
1. Construir procesos
En Hackatones y solucionismo, o por qué importa más el proceso que el resultado ya comenté sobre la falta de diversidad de perfiles involucrados y las debilidades a la hora de enmarcar de forma sólida las preguntas a resolver como dos elementos que suelen estar detrás de la fatiga de los hackatones.
Es la fase de ideación y de definición de los problemas donde debería centrarse gran parte del esfuerzo no tecnológico pero sí conceptualmente valioso para acertar con apps y otras soluciones que supuestamente quieren ser de utilidad. Los resultados de los hackatones suelen enfocarse en cuestiones técnicas y de vinculación a procesos de apertura de datos. Ello deriva en un listado de páginas de recopilación de datos o en versiones 1.0 con apenas funcionalidad y que sólo en un porcentaje mínimo tienen desarrollos posteriores. Por eso su principal debilidad es la falta de continuidad. Ello se debe a que están basados en el voluntarismo y la ausencia de recursos y contextos estables de colaboración que den soporte al antes y, sobre todo, al después de la fase alfa o beta a la que normalmente llegan las aplicaciones desarrolladas en estos eventos. Aquí es donde, por ejemplo, las metodologías de Medialab Prado, de Etopia y tantos otros espacios de innovación social digital, no vinculadas a los hackatones en sentido estricto pero sí conexas, ofrecen un entorno apropiado para ello.
La falta de seguimiento posterior es, sin duda, la causa de la frustración inmediata que pueden generar en los participantes. La documentación de los procesos (y no sólo las especificaciones técnicas) cobra un papel relevante para que los proyectos sean entendibles, se puedan evaluar las decisiones dadas en cada momento y se puedan sumar personas o contribuciones posteriores, etc.
2. Promover mayor inclusión y diversidad
Sin embargo, me interesa más cómo repensar este tipo de actividades desde el punto de vista de quién participa en ellas.
Los hackatones sufren muchas veces de una falta de diversidad Su atractivo suele enmarcarse en soluciones técnicas, asunto al que se ven llamados o están en contacto un determinado perfil de personas (desarrolladores, ingenieros, movimiento del open data, etc.).
Además, es importante que tanto las personas que dan soporte como las que participan tengan un conocimiento amplio de cómo funcionan “los procesos de la Administración“. Ello es fundamental para poder articular las soluciones derivadas de los hackatones en los procedimientos administrativos, en los procesos de toma de decisiones públicas, en los puntos críticos o cuellos de botella donde la tecnología sí puede marcar la diferencia, etc.
3. Construir formas estables de colaboración
En Hackatones don´t solve problems encontramos otras claves interesantes vinculadas con la crítica a la grandilocuencia del solucionismo. Sí, tenemos un gran problema si vamos a confiar en la tecnología para solucionar los grandes problemas que tenemos.
Los hackatones y, por extensión, este tipo de prácticas de producción colaborativa, deberían funcionar como excusas para crear formas estables de colaboración y no como explosiones de optimismo productivo.
Por un lado, la evidencia ya nos dice que los resultados prácticos y el impacto de las “soluciones” que se pueden desarrollar en tan cortos periodos de tiempo son escasos. Así que, seguramente será mejor reducir las expectativas y poner muchos más recursos y entusiasmo en sedimentar -y por eso aquí juega un papel importante el quién y el dónde se promueven- las relaciones de colaboración creadas y el potencial de los proyectos planteados.
Por otro lado, para ofrecer soluciones es importante enmarcar bien los problemas. En el caso de los temas que suelen cubrir los hackatones cívicos o urbanos, estos son generalmente “problemas retorcidos” perversos y es en el proceso de desentrañar su complejidad donde más pueden aportar y aprender los participantes.
Por lo tanto, para afrontar los conflictos políticos que están detrás de los temas urbanos/sociales de los hackatones cívicos, es necesario más constructivismo y menos tecno-determinismo. Allí es donde diferentes metodologías basadas en procesos de aprendizaje y de compromiso a largo plazo (Citizen Canvas o Changify, entre muchas otras) pueden aportar mucho más a la hora de favorecer procesos creativos de implicación social en problemáticas concretas.
¿Qué otras recomendaciones consideras claves para repensar los hackatones y aumentar su efectividad?
Leave a Reply