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?

</p>

Entonces, ¿por qué el engagement es importante? Hay varios motivos, según este interesante artículo People Powered Social Innovation: The Need for Citizen Engagement (PDF):
</p>

  • 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.

        • </ul></p>

© 2007 and beyond Mario Alberich, licensed under CC-BY-SA unless stated otherwise.