Cuanto más tiempo pasa, más consciente soy de que con UrbApps allá en 2012, de manera meramente intutitiva, íbamos por buen camino, en línea con alguno de los primeros textos que apuntaban en el cuestionamiento de los hackathons, como On hackathons and solutionism o Three Problems With Civic Hackathons. Desde entonces, se ha seguido profundizando en esa línea crítica sobre el planteamiento tradicional de los hackathons y sus impactos reales.
Estos días estoy leyendo The Data Revolution: Big Data, Open Data, Data Infrastructures and Their Consequences (un magnífico libro de Rob Kitchin sobre el que próximamente escribiré algo más en el blog) y en él vuelvo a encontrarme mencionados 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 apuntan cosas que estaban detrás de esas primeras inquietudes sobre cómo rediseñar los hackathons. Ahora, todo más consolidado, lo enlazo 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.
En Hackathons 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 hackathons. Es la fase de ideación y de definición de los problemas donde debería centrarse gran parte del esfuerzo no técnico pero sí conceptualmente valioso para acertar con apps y otras soluciones que supuestamente quieren ser de utilidad. Su enfoque demasiado centrado en cuestiones técnicas y su vinculación a procesos de apertura de datos convierten los resultados de los hackathons en sus diferentes vertientes, la mayoría de las veces, 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 al estar 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, no vinculadas a los hackathons en sentido estricto pero sí conexas, ofrecen un entorno apropiado para ello. Esta falta de seguimiento posterior es, sin duda, la causa de la frustración inmediata que pueden generar en los participantes. Por eso también, la documentación de los procesos (y no sólo las especificaciones técnicas) cobran un papel relevante para que los proyectos sean entendibles, se puedan evaluar las decisiones dadas en cada momento, se puedan sumar personas o contribuciones posteriores, etc.
Sin embargo, me interesa más cómo repensar este tipo de actividades desde el punto de vista de quién participa en ellas. Sufren, en primer lugar, de una evidente falta de diversidad, debido fundamentalmente a que 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, la presencia de personas, tanto dando soporte como participando propiamente, que tengan un conocimiento amplia de cómo fucnionan "las cosas de la Administración" es fundamental para poder encajar las soluciones derivadas de los hackathons 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.
Desde entonces he ido guardando otros artículos que profundizan en esas primeras sensaciones, junto a otros que también analizan su potencial. Bajo un críptico título, The trouble with White hats, de Melissa Gregg and Carl DiSalvo, se esconde un fantástico texto del que extraigo algunas líneas:
También en Hackathons don´t solve problems encontramos algunas claves interesantes, un texto directamente vinculado con la crítica a la grandilocuencia del solucionismo y el buenismo de la ideología californiana:
Bonus tracks. Aquí van otras tres sugerencias relacionadas:
 |
| TEDxShelburneFalls (CC BY-NC-ND 2.0) |
En Hackathons 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 hackathons. Es la fase de ideación y de definición de los problemas donde debería centrarse gran parte del esfuerzo no técnico pero sí conceptualmente valioso para acertar con apps y otras soluciones que supuestamente quieren ser de utilidad. Su enfoque demasiado centrado en cuestiones técnicas y su vinculación a procesos de apertura de datos convierten los resultados de los hackathons en sus diferentes vertientes, la mayoría de las veces, 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 al estar 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, no vinculadas a los hackathons en sentido estricto pero sí conexas, ofrecen un entorno apropiado para ello. Esta falta de seguimiento posterior es, sin duda, la causa de la frustración inmediata que pueden generar en los participantes. Por eso también, la documentación de los procesos (y no sólo las especificaciones técnicas) cobran un papel relevante para que los proyectos sean entendibles, se puedan evaluar las decisiones dadas en cada momento, se puedan sumar personas o contribuciones posteriores, etc.
Sin embargo, me interesa más cómo repensar este tipo de actividades desde el punto de vista de quién participa en ellas. Sufren, en primer lugar, de una evidente falta de diversidad, debido fundamentalmente a que 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, la presencia de personas, tanto dando soporte como participando propiamente, que tengan un conocimiento amplia de cómo fucnionan "las cosas de la Administración" es fundamental para poder encajar las soluciones derivadas de los hackathons 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.
Desde entonces he ido guardando otros artículos que profundizan en esas primeras sensaciones, junto a otros que también analizan su potencial. Bajo un críptico título, The trouble with White hats, de Melissa Gregg and Carl DiSalvo, se esconde un fantástico texto del que extraigo algunas líneas:
Hackathons attempt to imagine and enact a future democratic condition, allowing individuals to contribute to what it might be in the process. Too often though, this potentially profound speculation gets tied to a limited, if not naïve, understanding of politics as the mechanics of government. “What might be” is almost always simply a version of the now — just faster, more efficient, and preferably mobile-enabled.Civic hackathons reflect changes to the nature of work, volunteerism, collectivity, and belonging. The production process is configured to appear friendly, informal, and ad hoc, leading to new kinds of social identities and relationships. At civic hackathons, new ecosystems for innovation, design, micro-manufacturing, and city revitalization are made to cohere in the course of a day or a weekend.
(...)
Civic hackathons are limited to addressing problems that contain technically actionable solutions. For instance, addressing problems of public-transportation access in communities of need is reduced to the challenge of providing real-time bus data. And the problems each hackathon hopes to solve get readjusted in real time to suit actual conditions and who and what skills are at hand. So whether the bus data is displayed on a mobile device or a visualization will depend not on the community’s need or desire but on what programming languages the coders at the hackathon know. This ad hoc adjustment, which is an inevitable outcome of hackathons’ opportunistic approach to time and skill, parochializes and minimizes the ambition of governance. It rewards pragmatism at the expense of recruiting more representative or ideal protagonists for politics.
 |
| TechCrunch Disrupt Europe Hackathon (CC BY 2.0) |
They're hard, bordering on intractable, and people are working to solve these problems constantly, spending much more energy and resources than a single hackathon could ever do. There is nothing magical about putting a bunch of technologists and creatives in a room which will suddenly solve disasters, world crises, the economy, or anything else. (…)In short: Hackathons can be fun, they can inspire new ideas, they can break disciplinary boundaries. But if they are "Tech's Answer to Big Problems", we're in trouble.Sí, tenemos un gran problema si vamos a confiar en la tecnología para solucionar los grandes problemas que tenemos. En realidad, los hackathons 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, porque 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, porque para ofrecer soluciones, como mencionaba anteriormente, es importante enmarcar bien los problemas y en el caso de los temas que suelen cubrir los hackathons cívicos o urbanos, estos problemas son wicked problems la mayor parte de las veces y es en el proceso de desentrañar su complejidad donde más pueden aportar y aprender los participantes. Más constructivismo y menos tecno-determinismo para afrontar los conflictos políticos que están detrás de los temas urbanos/sociales que los hackathons cívicos suelen afrontar. ahí es donde diferentes metodologías, más 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.
No hay comentarios :
Publicar un comentario