A blog about data, information and Tech by Mario Alberich
Participación, hackaton y "civic engagement"
Parece ser que la calidad democrática no (sólo) depende de la capacidad de la clase política, sino también del grado y la calidad de la participación de la población en el proceso, y por lo que estamos viendo, dista de de lo ideal. Es por eso que uno se pregunta qué falla, o al menos qué nos falta para que funcione.
</p>
</p>
¿Por qué querremos la participación de otras personas?
Las personas que se implican comprenden (y ayudan a comprender) lo que sucede: es una experiencia más cercana a la realidad y por ello ayuda a tener una visión global.
El grupo de personas que se implica acostumbra a ser diverso, y por ello ayuda a superar ciertos puntos de bloqueo que sucede cuando el grupo es más homogéneo.
Al implicarse y diversificarse, el grupo de personas implicadas legitima la acción.
Dar respuestas a situaciones complejas requiere esa implicación, porque así las personas se centran en el problema y aprovechan esa habilidad de nuestros cerebros para adaptarse a situaciones complejas.
</ul></p>
También hay que considerar que los procesos de implicación a veces pueden resultar descorazonadores para los propios participantes, especialmente si toman conciencia del "largo camino" a recorrer, o bien cuando los propios procesos de implicación conllevan un proceso de exclusión o jerarquización de los miembros del grupo. Por ello, la implicación debe implicar horizontalidad, al menos durante el tiempo que dura ese primer contacto.
</p>
</div></p>
¿Cómo puedes conseguir participación e implicación?
Amy Quipse en Google+ publicó una pequeña joya: cómo llevar a cabo un hackaton más inclusivo. Para quien no lo sepa, los hackatons son jornadas dedicadas a hackear, a sacar partido de los recursos disponibles para obtener algún objetivo más o menos concretos. Existe gran variedad de hackatons, que intentan atraer a un público más o menos tecnológico o al menos atraído por ello. Dicho así, si eres alguien con pocos o nulos conocimientos en programación e informática, es probable que no te atraiga. Amy expone los siguientes puntos para conseguir que el hackaton funcione:</p>
Explicar a la gente qué es un hackaton, y no el tipo de personas que esperamos ver ahí.
No es problema que sea tu primera vez.
No es una competición.
Presentarlo y cuidar la imagen con (cierto) esmero.
Es una oportunidad para aprender.
Es fácil hacer preguntas.
Es más que "brillantes webapps".
Asegurar que no serán los/as únicos/as
Abrieron preinscripciones para mujeres y chicos de edades inferiores. Ambos son públicos menos proclives a los hackatons.
Que sea tu primera vez, no significa que no puedas aportar nada.
</ul></p>
Al fin y al cabo, ¿Por qué queremos hacer un hackaton?
Y más allá de esto: ¿qué nos aportará? Clay Shirky, en su Keynote para la Code for America Summit del año pasado 2013 presentó algunos elementos clave:</p>
</p>
Enfoque iterativo: la reformulación del problema permite ajustar la herramienta a la solución.
Los problemas de gestión son más complejos que los técnicos, porque requieren conocimiento y voluntad entre las partes.
A nivel político, no se trata de una cuestión de soluciones (qué ganamos) sino de dilemas (qué dejamos de ganar).
Algunos problemas sociales clásicos (ej. prostitución) son de solución difícil porque se resisten a una definición clara.
</ul>
</li></p>
El primer paso para resolver el problema es darse cuenta que el problema técnico no es el verdadero problema.
El mejor recurso para encontrar esa solución es darse cuenta de nuestra propia capacidad para cambiar nuestra opinión, punto de vista o visión del problema.
No te guíes por el "No funcionará": En el fondo no se trata de si funciona o no. En primera instancia no funcionará casi seguro.
Buscar la crítica constructiva: Enfócalo a la persona tratando de resolver un problema, no al problema en sí mismo.
El objetivo de los hackatons no es obtener un código fuente funcional, sino conseguir un capital social que permita comprender y formular mejor los problemas a resolver.
Prácticamente ninguna solución que actualmente funcione, tiene la forma con la que se concebió: ha evolucionado/iterado.
Es importante asumir que nuestra primera formulación del problema es errónea, y que enfrentándola al exterior tendremos que redefinirla.
A veces creamos un prototipo para demostrar al cliente que está equivocado. Es importante que también lo construyamos para entender en qué estamos equivocados.