Spanish (pdf)
Article in xml format
Article references
Automatic translation
Send this article by e-mail
Cited by SciELO 
Cited by Google 
Similars in
SciELO 
Similars in Google 
Permalink
Introducción
En el presente artículo presentamos un análisis crítico sobre las metodologías de desarrollo centradas en el usuario (Trujillo, Aguilar y Neira, 2016), considerando las experiencias en dos proyectos de software y uno de hardware (Trujillo, 2015), estos son: a) la red abierta Beacons Barcelona, b) el caso del proyecto Barcelona Street Lab y c) el prototipo Urban Sensor. Consideramos que estas experiencias nos dotan de elementos empíricos para evaluar las potencialidades y debilidades que tienen las metodologías basadas en el desarrollo participativo de tecnologías (DPT), las técnicas de co-creación (Brown, 2008 y 2009) y las metodologías ágiles (Beck et al., 2001; Pikkarainen et al., 2012). Además de analizar críticamente cada metodología aplicada, también establecemos reflexiones sobre el papel que tienen los investigadores sociales y los factores externos en los procesos de desarrollo de las tecnologías emergentes que, en nuestros casos de estudios y con arreglo a las diferencias, dibujan cierto patrón común paradójico en el que los obstáculos se convierten o traducen en un impulso de los procesos de innovación (Brown y Wyatt, 2010). En este sentido, la hipótesis subyacente de este trabajo apunta en tres direcciones. En primer lugar, las metodologías que involucran a la participación de los potenciales usuarios (Espinoza Vásquez y Espinoza Zapata, 2017) no siempre generen un proceso lineal con todos los factores controlados, y en el caso de ser efectivo, un proceso de desarrollo lineal y controlado no es garantía de éxito (Dobrigkeit y de Paula, 2019). En segundo lugar, en los procesos de innovación de base tecnológica es frecuente que existan agentes resistentes al cambio que no están previstos y que pueden condenar los procesos de creación al fracaso, pero también pueden significar un mayor impulso o fortalecer el proyecto. El tercer lugar, las metodologías participativas para la creación de tecnologías tienen el trasfondo de ser dispositivo de gestión de la creatividad colectiva, si esta gestión de la creatividad no es enmarcada, en ocasiones puede resultar un factor paralizante de la agencia innovadora. En conjunto, las tres direcciones de la hipótesis redundan en que cualquier proceso de desarrollo de software centrado en el usuario puede ser considerado “tecnología incierta”.
Metodología
Casos de estudio
Caso 1: red abierta Beacons Barcelona
Problema
El proyecto surgió en el marco de una investigación doctoral que se desarrolló entre el Departamento de Psicología y la Escuela de Ingeniería de la Universidad Autónoma de Barcelona. El problema identificado fue el siguiente: las dificultades que tienen las personas ciegas o con deficiencia visual para acceder a la información del entorno.
Solución
La solución consistió en el desarrollo de un sistema informático con la tecnología Beacon (Peñaloza et al., 2021): las balizas Bluetooth Low Energy (BLE), un tipo de tecnología WPAN (Wireless Personal Area Network) desarrollada por Bluetooth SIG (Special Interest Group), que funciona mediante dispositivos de bajo consumo, popularmente son conocidas como “beacons” y pueden ser utilizadas para determinar la localización física del dispositivo, esta cualidad hace que el usuario de la app no tenga que “buscar el beacon sino que el beacon lo busca a él”, por lo que funciona mejor que las prestaciones de un código Qr; el usuario no tiene que realizar maniobras de localización del marcador para acceder a diferentes contenidos digitales vinculados a la baliza. Mediante este tipo de dispositivos se puede acceder a diferentes modalidades de traducción de la información: audiodescripción de texto, video con lenguaje de señas y pictograma (Zaballa, 2017).
Metodología
En la Figura 1 se presenta el detalle del proceso de diseño y desarrollo participativo de tecnologías. Desde la génesis del proyecto se contó con la participación de las organizaciones de ciegos ACIC y ADVC1, gracias a la participación de estas organizaciones también se sumó la asociación de comerciantes. Con la participación de las asociaciones de personas ciegas y el apoyo de los comerciantes de la Cruz Cubierta (Barcelona, España), mediante el concurso de subvenciones competitivas, se obtuvo el apoyo económico y técnico del Instituto de Cultura de Barcelona y el Instituto Municipal de Personas con Discapacidad, ambos organismos del Ayuntamiento de Barcelona.
Fuente: Cereceda Otárola y Roig de Zárate (2022)
Figura 1 Proceso de escalamiento de la red abierta Beacons Barcelona, basado en el diseño y desarrollo participativo en tecnologías.
Obstáculos
En principio, se solicitó apoyo a la principal organización de discapacidad en España, la Organización Nacional de Ciegos de España - ONCE, que tiene una convocatoria competitiva para proyectos de I+D+i en discapacidad visual. La respuesta de la ONCE fue que ya estaba desarrollando su propia tecnología en beacons. Además, el Departamento de Psicología de la Universidad Autónoma de Barcelona, considerando que no hubo financiación por parte de la ONCE, no siguió participando, salvo el doctorando que llevaba a cabo la investigación, un psicólogo y politólogo, interesado en participar juntamente con los ingenieros que no abandonaron el proyecto. En nuestra opinión, estos dos problemas en vez de hacer abortar el proceso fueron impulsores del proyecto, que quedó en manos de las asociaciones de ciegos, los comerciantes y el equipo de desarrolladores integrado por ingenieros en informática, sociólogos y psicólogos.
Resultados
Se desarrolló la red abierta Beacons Barcelona, una flota de 450 beacons instalados en los comercios de Creu Coberta, en el Museo Etnológico de Catalunya y el Museo de Castillo de Montjuïc. Los comerciantes o técnicos disponen de un gestor de contenidos (CMS) donde alojan los contenidos digitales asociados a los beacons. Se desarrolló la aplicación “Barcelona sense barreres” (Aragall, 2002), que los usuarios instalan en su dispositivo móvil para acceder a los contenidos mediante la consulta de los beacons. El éxito del proyecto se observa en dos instancias: en primer lugar, el software, las flotas de 450 beacons fueron trasferidos a la empresa Mass Factory. En segundo lugar, la ONCE, corporación que en principio rechazó el proyecto, terminó solicitando la alianza con el proyecto de la red abierta de Beacons para instalar el servicio en todos los museos de España.
Taso 2: Proyecto Barcelona Street Lab
Problema
La instalación masiva de tecnologías IoT en el espacio público (Nedeltcheva y Shoikova, 2017) que considera una diversidad de sensores de contaminación, temperatura, humedad, etc. produce un fenómeno urbano al cual llamamos “sobretecnificación del paisaje urbano” (Durán, 2020), consiste en que el desarrollo de estas tecnologías de “smart cities” (López y Álvarez, 2021) producen problemas estéticos o de ordenamiento urbano en espacios en ocasiones fuertemente regulados por la normativa (Mejía et al., 2019). Si bien el desarrollo tecnológico de la ciudad no puede ir en contra del paisaje urbano, el mantenimiento y la armonía del paisaje urbano no pueden ir en contra del desarrollo tecnológico de la ciudad (Coşkun, 2010).
Solución
Desde la Universidad Autónoma de Barcelona, específicamente CORE - Ciudades Inteligentes y Sostenibles, se propuso diseñar y desarrollar un prototipo de PCB (placa de circuito impreso) y firmware que integrara diferentes tipos de sensores en un solo concepto, considerando diferentes tipos tecnología de sensores, emisores y dispositivos telecomunicaciones, alimentados con una fuente variable (fotovoltaica o toma de corriente directa) empaquetada en una carcasa fabricada con impresión 3D. Este proyecto fue financiado por la convocatoria competitiva para el desarrollo de tecnologías del Ayuntamiento de Barcelona.
Metodología
En la Figura 2 se presenta el detalle del proceso de co-creación. Se conformó un grupo multidisciplinar compuesto por diferentes empresas de ingeniería: telecomunicaciones, informática, electrónica, sensórica; al proceso se integraron los comerciantes de Creu Coberta. Los profesionales (sociólogo y urbanista) se encargaron de dinamizar las diferentes sesiones de deliberación y desarrollo conceptual, a través de establecimiento de diferentes retos que los participantes iban resolviendo de manera consensuada. Como una forma de experimentar con la creatividad, a los participantes se les pidió idear una solución de integración de máximos, en lugar de pedir un mínimo producto viable, el objetivo fue obtener un máximo producto viable, es decir, una solución que integre en la PCB el máximo número posible de componentes tecnológicos con sus respectivas funcionalidades, de manera flexible y adaptable a diferentes tipos de entornos, logrando así una mayor adaptación a los requerimientos y las necesidades de empresas, inversores, mercado, etc.
Obstáculos
El experimento de los investigadores sociales de hacer interactuar a diferentes saberes de la ingeniería conjuntamente con la ciudadanía (los comerciantes) se tradujo en la obtención de un máximo producto viable, pero surgieron problemas inesperados: en primer lugar, las empresas participantes comenzaron a disputarse y generar fricciones por la futura propiedad intelectual o industrial del producto, sobre todo, por los porcentajes que le correspondería a la Universidad Autónoma de Barcelona y los porcentajes que le corresponderían las empresas desarrolladoras. En segundo lugar, el máximo producto viable desbordó el presupuesto inicial asignado por el Ayuntamiento de Barcelona, se tenía un pequeño fondo de 9.000 € pero el prototipo costaba 50.000 €, una cantidad no menor, la Universidad abrió la instancia para concursar y pedir este fondo, pero el investigador principal, habida cuenta de las malas relaciones que se generaron entre las empresas, decidió postular a una beca postdoctoral y marchó a Chile.
Resultados
El proyecto finalmente no pasó a la fase de desarrollo (ver detalle en Figura 2), quedó en stand-by a la espera de encontrar mejorar condiciones para su despliegue. Aunque se obtuvo la idea base de que es posible crear una solución de integración de diferentes tecnologías en un solo concepto y que la solución tiene un interesante potencial de mercado, como solución al desarrollo tecnológico amigable con el planeamiento urbano. Pero de ser posible, su desarrollo no se realizará en Europa, sino en Chile, con mejores condiciones de financiación y recursos humanos más competitivos.
Caso 3: Prototipo Urban Sensor
Problema
En el marco del proyecto FONDECYT 3200381 se constataron los serios problemas que tiene Santiago de Chile en materia de accesibilidad en la vía pública, problemas como hoyos, cruce de peatones sin rampa, mal estado de las calles o simplemente calles que no están pensadas para la diversidad corporal, lo que se traduce en barreras que excluyen a adultos mayores o personas con discapacidad. Gran parte de las municipalidades, aunque están informadas de estos problemas, no tiene herramientas simplificadas y económicas para identificar, mapear y sistematizar las situaciones de inaccesibilidad para poder realizar intervenciones efectivas.
Solución
Con ingenieros en informática de la Universidad Autónoma de Chile, se diseñó y desarrolló el software Urban Sensor, un prototipo de SIG (sistema de información geográfica) para identificar y clasificar los problemas de accesibilidad en espacio público (Corral y Fronza, 2018). El usuario utiliza una aplicación móvil para capturar los datos: coordenadas de latitud y longitud, y puede adjuntar evidencias en formato de video, audio, imagen, para hacer descripciones del contexto. Estos datos son enviados por el usuario a una plataforma de visualización de datos, donde un equipo de gestión que toma decisiones puede realizar diferentes operaciones, consultar estadísticas, agregar capas, etc.
Metodología
En la Figura 3 se presenta el detalle del proceso de aplicación de la metodología ágil (Landim, Albuquerque y Macedo, 2010; Tolfo et al., 2011) escogida, específicamente en su variante Scrum. El procedimiento consiste en iteraciones sucesivas con sincronizaciones puntuales. Como apunte crítico, aquí la aportación de los investigadores sociales y de los usuarios es bastante lejana a la que propone el diseño participativo y la co-creación: solo tienen una participación en la definición del “pre-proyecto”, durante el desarrollo su participación se reduce validar los Scrum, proponer mejoras y validar el resultado final (Solinski y Petersen, 2016).
A diferencia del diseño participativo, la metodología ágil (Nerur, Mahapatra y Mangalaraj, 2005) se muestra efectiva para crear productos pero no para crear comunidad de usuarios que reduzca la incertidumbre al momento de hacer la transferencia tecnológica al mercado, esta se tiene que crear una vez implantada la tecnología. En consecuencia, se corre el riesgo de que el producto no tenga ningún sustento social o comunitario y en el corto y mediano plazo se convierta en una “aplicación fantasma”, es decir, un software sofisticado que nadie utiliza.
Obstáculos
Aunque los miembros del equipo funcionaron perfectamente dentro de los marcos de la metodología ágil Scrum (Nishijima y Dos Santos, 2013), la Dirección de Investigación de la Universidad Autónoma de Chile (UA), por problemas burocráticos externos, retiró el patrocinio en plena fase de desarrollo. La retirada de patrocinio actúa como un factor que afecta la motivación, los miembros del equipo perseveraron y continuaron con el desarrollo (Fayad, Laitinen y Ward, 2000). Posteriormente, se lograron captar nuevos fondos de financiación del proyecto, por la vía de la postulación a fondos internos concursables de la Vicerrectoría de Vinculación con el Medio (VVcM) de la misma universidad, se obtuvo la aportación de 1.300.000 pesos chilenos. También se recibió el apoyo técnico de la Faculta de Ingeniería y la Facultad de Arquitectura y Construcción, así como la vinculación al proyecto de funcionarios de la Municipalidad de Constitución y Yerbas Buenas (Chile). Finalmente, el proyecto logró captar patrocinio adicional por parte de la Dirección de Innovación y Transferencia y la Dirección de Investigación (UA) para la postulación a fondos concursables que permiten el desarrollo y escalamiento del prototipo.
Resultados
Actualmente el prototipo ha sido presentado a fondos concursables por parte de la Universidad, de manera paralela, se están haciendo pruebas de usuario con municipalidades y también en proyectos con los practicantes, el objetivo es que en función de la financiación la Universidad Autónoma tenga un software SIG propio, al cual se le podrán añadir más funcionalidades y extender su uso más allá de los problemas de accesibilidad: identificación de microbasurales, catalogación de flora y fauna, proyectos de ciencia ciudadana.
Resultados
Se pueden observar aspectos singulares en cada proceso y su impacto en el resultado obtenido. Pero también se observan aspectos que son transversales, en los que intervienen obstáculos externos que, paradójicamente, resultan ser factores que impulsan el desarrollo. En nuestra opinión, esto sucede cuando los proyectos adquieren identidad, es decir, un tipo de agencia que no es igual a la suma de los esfuerzos de los individuos que intervienen en el proceso de programación, sino un tipo de dinámica psicosocial de innovación en que, a pesar de los obstáculos, los actores logran alinearse en torno al desarrollo del software. Por ejemplo, en el caso de la red abierta Beacons, observamos cómo los principios del diseño participativo son reflejados en un proceso que articuló una alianza simétrica entre diferentes entidades sociales que posibilitó el escalamiento, que fue creando su propia comunidad de usuarios, a medida que el desarrollo avanzaba. Esto fue posible por el papel de liderazgo que tuvieron los investigadores sociales, que actuaron como dinamizadores tecnológicos. En este sentido, se pueden aplicar diferentes conceptos de la teoría del actor-red, como el concepto de “traducción”, a medida que avanza la trayectoria temporal del desarrollo, el objeto tecnológico traduce los intereses de los actores involucrados. Por ejemplo, la red de beacons traduce las necesidades de las personas ciegas al proveer de un sistema de orientación, traduce las necesidades de los comerciantes al proveerles un sistema de promoción comercial y traduce las necesidades de los informáticos al proveerles de un sistema IoT sobre el cual se pueden programar múltiples aplicaciones.
En el caso del proyecto Barcelona Street Lab observamos un efecto paradójico de la co-creación: en primer lugar, se observa que la co-creación se yergue como una técnica en las que participan diferentes ramas de la ingeniería en torno a la solución de un problema definido. En esta experiencia, los investigadores sociales, a diferencia del papel dinamizador que tuvieron en el caso 1 (red abierta Beacons), tuvieron un papel relevante en la identificación del problema a resolver, en la dinamización, en la sistematización del proceso de co-creación y el registro documental de las liberaciones que fue tomando el grupo de trabajo. En este sentido, la naturaleza del reto propuesto, así como la interacción entre saberes de la ingeniería, abrieron el marco para la experimentación definiendo un producto máximo viable. Sin embargo, en este espacio donde la creatividad produjo expectativas en los participantes, se dieron situaciones que actuaron en contra del proceso de co-creación, dadas las fricciones en torno a potencial propiedad industrial.
En el caso del prototipo Urban Sensor, se pueden observar las ventajas, pero también las limitaciones que tiene esta metodología para articular procesos de innovación emergentes. Este método disminuye la incertidumbre, pero la linealidad, la rapidez y la parcialización de las actividades de desarrollo lo revelan quizá como no apropiado para insertar tecnologías en el tejido o las redes asociativas en las que están involucrados diferentes agentes de la ciudadanía; el hecho de reducir la participación de los investigadores sociales a meros usuarios o bien reducir la participación de los potenciales usuarios a sincronizaciones pautadas, hace imposible que los usuarios o agentes involucrados se pueden apropiar y dotar de identidad a la tecnología, un aspecto importante al momento de la implementación. En estos casos, una vez realizado el servicio es necesario hacer esfuerzos (incluso más costosos que el desarrollo) en marketing o publicidad para que el software pueda insertarse como una solución en algún tipo de práctica humana, a diferencia de lo que sucede con el diseño participativo de tecnologías y las técnicas de co-creación.
Conclusiones
Intentado ir más allá de la crítica a los diferentes métodos, también observamos el papel que cumplen los obstáculos y cómo en vez de configurarse como barreras que extinguen el impulso innovador, paradójicamente, estos “portazos” se convierten en un catalizador observado a través de maniobras, aperturas o bien perseverancia. Cuando suceden estas paradojas en forma de obstáculo o portazo que altera la trayectoria del proceso de desarrollo, pero no lo detiene, desde la sociología de la innovación es indicador de que el proyecto comienza a tomar identidad propia, va reclutando a sus componentes, evade o salta los obstáculos que se le interponen o amenazan. Esta particularidad asigna sentido social a la creación del software, lo fundamenta y va más allá de las actividades de programación en sí, incluso puede ser un aspecto invisible a los programadores, puede estar más relacionado con la ingeniería social en la que se sostiene cada proyecto de software, generalmente son los gerentes, los Scrum managers o los directores de equipo los que logran visualizar este aspecto paradójico. La comparación de los tres casos de estudio nos proveen de consideraciones importantes en cuanto a las limitaciones y ventajas que pueden tener las metodologías de desarrollo de software que incorporan el trabajo de investigadores sociales, sean estos sociólogos y psicólogos, hemos observado que la incorporación de estos profesionales en los procesos le dota al proceso de co-creación y desarrollo un sentido experimental en el que las actividades de programación de software pueden estar vinculadas directamente a los problemas de las entidades sociales e incluso ir creando comunidades de usuarios desde el principio, como prosumidores, es decir, productores y consumidores que van dotando, configurando y transformando la trayectoria del ciclo de desarrollo. Estos casos que pueden ser emergentes o bottom up, son procesos lineales en los que la tecnología transforma los modos de organizar la vida. Sin embargo, estas prácticas de desarrollo de software que logran transformar las organizaciones humanas no siempre son factibles, están sujetas a un alto grado de incertidumbre, ya que no se sabe cómo terminará el proceso, por eso les podemos llamar “tecnologías inciertas”.
