En 2014 lo llamábamos desarrollar aplicaciones para ayuntamientos. Android, iOS, bandos, noticias, agenda, notificaciones e incidencias. Doce años después, mirando el ecosistema Vicopo con perspectiva, creo que aquello explica bastante bien una parte de lo que hoy llamamos GovTech municipal.
En 2014 no hablábamos todavía de GovTech municipal.
Hablábamos de hacer aplicaciones para ayuntamientos.
Una app para Android.
Otra para iPhone.
Un backend. Una base de datos. Un panel de gestión. Mapas. Notificaciones. APIs.
Y una idea bastante más sencilla que toda esa tecnología:
Que el vecino pudiera saber qué estaba ocurriendo en su municipio y relacionarse con su Ayuntamiento desde el móvil.
Desde 2014 trabajé en este tipo de soluciones para ayuntamientos de toda España dentro del ecosistema Vicopo.
Doce años después me resulta curioso comprobar cuánto ha cambiado la tecnología y cuánto se parece el problema actual al que intentábamos resolver entonces.
Hoy utilizaríamos palabras como GovTech municipal, Smart City, participación ciudadana, servicios digitales, datos u omnicanalidad. De hecho, la OCDE ya sitúa GovTech como un habilitador de la innovación y la transformación digital de las administraciones.
En aquel momento, muchas veces, la petición era simplemente:
Necesitamos una app para el Ayuntamiento.
TL;DR
En 2014 pensábamos que estábamos construyendo aplicaciones municipales.
Con los años entendí que estábamos construyendo una pequeña capa de infraestructura digital entre Ayuntamiento y ciudadanía.
Las apps eran la parte visible. El producto real eran los servicios que existían detrás.
Antes de hablar de GovTech municipal, simplemente hacíamos apps para ayuntamientos
Uno de los proyectos donde mejor se concentraron estas ideas fue La Pobla Info, dentro del ecosistema Vicopo.
Con perspectiva, aquel proyecto fue también uno de mis primeros ejemplos de GovTech municipal: tecnología bastante poco espectacular destinada a resolver problemas cotidianos entre Ayuntamiento y ciudadanía.
La intención no era trasladar la web municipal a una pantalla más pequeña.
Queríamos acercar el municipio al teléfono del ciudadano.
Que alguien pudiera abrir la aplicación y resolver preguntas muy cotidianas:
- ¿Qué ha ocurrido hoy?
- ¿Hay algún bando nuevo?
- ¿Qué actividades hay este fin de semana?
- ¿Dónde está la farmacia de guardia?
- ¿Hay alguna información importante sobre transporte?
- ¿Ha cambiado algún servicio?
- ¿Puedo comunicar una incidencia?
- ¿Me avisará el Ayuntamiento si ocurre algo relevante?
Parece una lista sencilla.
Sin embargo, detrás ya estaban muchas de las cuestiones que seguimos encontrando cuando hablamos de transformación digital de una Administración.
Información. Comunicación. Participación. Servicios. Datos. Operación. Mantenimiento.
Porque desarrollar una aplicación es relativamente sencillo.
Conseguir que siga siendo útil muchos años después es otra historia.
Que el vecino sepa qué ocurre en su municipio
Si tuviera que resumir el propósito de aquellas aplicaciones en una sola frase, elegiría esta:
Que el vecino sepa qué ocurre en su municipio.
Noticias, bandos, agenda, eventos, farmacias, transporte, servicios y avisos. No todo tenía la misma importancia, el mismo ciclo de vida ni debería comunicarse de la misma manera.
Un bando no es una noticia. Una noticia no es un evento. Un evento no es una alerta. Y una alerta importante no debería competir en igualdad de condiciones con cualquier publicación.
La idea importante
El bando no pertenece a Android. La noticia tampoco pertenece a la web y el evento no pertenece a iOS.
Son elementos del dominio municipal. Las aplicaciones son simplemente interfaces que permiten acceder a ellos.
Un bando municipal también puede ser GovTech municipal
El bando es probablemente uno de los ejemplos que mejor explica aquella transformación. Los ayuntamientos llevan muchísimo tiempo utilizando bandos. La necesidad de comunicar no apareció con los smartphones. Lo que cambió fue la distribución. Este es uno de los ejemplos más sencillos de GovTech municipal: no inventar una necesidad nueva, sino mejorar cómo se presta un servicio que ya existía.
La información puede ser exactamente la misma. La experiencia no. El valor no está en transformar un bando de papel en HTML o JSON, sino en conseguir que la información oficial llegue cuando todavía es útil.
- un corte de tráfico;
- una modificación de horarios;
- una ayuda;
- un plazo;
- un cambio en un servicio;
- un aviso relacionado con las fiestas;
- una información importante para el municipio.
Las noticias hacen otra cosa
Las noticias tienen un ciclo distinto. No todo requiere urgencia. Además, sirven para construir contexto sobre lo que está ocurriendo en el municipio: obras, proyectos, campañas, convocatorias, servicios, novedades e información institucional.
El ciudadano necesita un lugar sencillo donde consultar esa actualidad. Lo interesante no suele estar en la pantalla, sino en todo lo que hay detrás para que esa pantalla siga teniendo sentido.
Mostrar datos suele ser bastante más sencillo que gobernarlos.
Los eventos son información con fecha de caducidad
En cambio, la agenda tiene otra naturaleza. Un evento tiene fecha, hora, ubicación, categoría, descripción y quizá inscripción. Además, puede cambiar o cancelarse. Una actividad que hoy es relevante puede no tener ningún valor pasado mañana.
Por eso siempre me pareció especialmente útil que la agenda no se limitara a mostrar actividades. Una pequeña funcionalidad puede transformar información que caduca en un servicio que acompaña.
Farmacias, transporte y servicios cotidianos
También había funcionalidades aparentemente menos sofisticadas que explicaban bastante bien para qué servía realmente una app municipal: consultar una farmacia, encontrar un teléfono, obtener información sobre transporte o acceder a determinados servicios.
La pregunta deja de ser «¿qué tecnología estamos utilizando?» y pasa a ser «¿ha encontrado el ciudadano lo que necesitaba?».
Las notificaciones push cambiaron la relación
Probablemente una de las capacidades que más transformó la experiencia fueron las notificaciones. Hasta entonces la relación digital funcionaba fundamentalmente en modo pull: el ciudadano tenía que acordarse de que existía información, abrir una web o una app y buscarla. Con push aparece otra posibilidad: el Ayuntamiento publica información relevante y puede avisar directamente al ciudadano. En GovTech municipal, disponer de un canal directo con el vecino tiene mucho valor, pero precisamente por eso conviene utilizarlo con criterio.
Cada push consume un poco de confianza
Enviar una notificación es barato. Recuperar a un usuario que ha decidido silenciar la aplicación es bastante más complicado. Si convertimos cada noticia, cada actividad y cada pequeña actualización en una interrupción, terminaremos destruyendo precisamente el canal que pretendíamos construir.
Cada notificación push consume una pequeña cantidad de confianza.
No confundas comunicar con interrumpir
Un canal directo es valioso porque el ciudadano confía en que lo utilizaremos con criterio.
Cuanto más importante queremos que sea el canal, menos deberíamos abusar de él.
Segmentar también es una forma de respetar esa confianza
En La Pobla Info las notificaciones podían organizarse por categorías. No todos los vecinos tienen los mismos intereses. Alguien puede estar especialmente interesado en cultura. Otro en avisos municipales. Otro en determinadas noticias o servicios.
La comunicación también iba en dirección contraria
Hasta aquí tenemos principalmente información que viaja desde el Ayuntamiento hacia el ciudadano. Sin embargo, las incidencias introducían el camino contrario.
Una farola apagada. Un desperfecto en una acera. Una señal dañada. Un problema de limpieza. Mobiliario urbano. El ciudadano podía utilizar el teléfono para comunicarlo mediante una fotografía, ubicación GPS, descripción y categoría.
¿El vecino como sensor urbano?
Durante los años de mayor conversación alrededor de las Smart Cities se utilizó bastante una expresión: cada ciudadano puede convertirse en un sensor urbano. Tiene una parte de verdad, aunque hoy prefiero explicarlo de una manera menos grandilocuente.
Miles de personas recorren cada día las calles de un municipio. Ven problemas que ningún sistema centralizado puede detectar inmediatamente. La tecnología permite reducir la distancia entre «aquí hay un problema» y «el Ayuntamiento sabe que existe».
La incidencia no termina al pulsar «Enviar»
Aquí aparece una parte del GovTech municipal que muchas veces queda escondida. La aplicación es solo el comienzo.
Digitalizar no es solo poner un formulario
Si digitalizamos la entrada pero detrás todo continúa funcionando exactamente igual, corremos el riesgo de haber creado únicamente una cola más bonita.
El servicio incluye también todo lo que ocurre después de pulsar Enviar.
GovTech municipal: cuando una incidencia empieza a convertirse en dato
Una incidencia aislada sirve para resolver un problema. A partir de cien, empiezan a aparecer patrones. Con miles de casos y suficiente histórico, además, podemos aprender cómo está funcionando una parte del municipio.
- ¿Qué problemas aparecen con mayor frecuencia?
- ¿Dónde?
- ¿Cuándo?
- ¿Se repiten?
- ¿Cuánto tardamos en resolverlos?
- ¿Qué zonas concentran determinados tipos?
- ¿Hay patrones estacionales?
- ¿Existen actuaciones que reducen los problemas posteriores?
Pero los datos de la plataforma no son solo incidencias
Sería un error reducir esta conversación únicamente a las incidencias. Los bandos pueden ayudarnos a entender qué información necesita mayor distribución. La agenda puede mostrar qué tipos de actividades generan más interés. Las noticias pueden indicar qué información se consulta. Las notificaciones pueden enseñarnos cuándo estamos informando y cuándo estamos generando ruido. Los servicios pueden mostrar qué necesidades digitales aparecen con más frecuencia.
El dato no sustituye al Ayuntamiento
Los datos no sustituyen al conocimiento de los técnicos ni a las decisiones políticas.
Tampoco convierten automáticamente un municipio en una Smart City.
Pero pueden aportar evidencia para hacer mejores preguntas.
Los datos de mañana dependen del formulario de hoy
Hay una lección importante que no suele verse en la primera versión de un servicio. Si para comunicar una incidencia pedimos un único campo de texto libre, un técnico probablemente podrá interpretarlo. El problema aparece unos años después, cuando quieres contar, agrupar, comparar o mapear miles de casos escritos de maneras completamente distintas.
Si, en cambio, pedimos una estructura mínima —por ejemplo, categoría, ubicación y descripción— seguimos teniendo un formulario razonable para el vecino, pero también ganamos algo importante detrás: datos útiles. En GovTech municipal, una decisión aparentemente pequeña de UX puede condicionar durante años la calidad de los datos disponibles.
Los datos que podremos utilizar dentro de cinco años dependen bastante de cómo diseñemos hoy una interacción de treinta segundos.
También había que funcionar cuando Internet no colaboraba
Otra característica menos espectacular, pero bastante importante, era el almacenamiento local. El GovTech municipal también se utiliza en la calle, con teléfonos distintos, coberturas irregulares y momentos en los que la conectividad falla.
Por eso, parte de la información debía continuar estando disponible aunque la conectividad fuera limitada. Son precisamente estas decisiones las que terminan separando una demo de un servicio que las personas pueden utilizar de verdad.
Diseñar para todo un municipio cambia las prioridades
El público de una aplicación municipal no es homogéneo. Puede utilizarla un adolescente, una persona de cuarenta años o una persona mayor. Alguien con un teléfono nuevo o alguien con un dispositivo que lleva años utilizando.
- navegación comprensible;
- jerarquías claras;
- textos legibles;
- acciones reconocibles;
- acceso rápido a la información importante.
La interfaz debía ser comprensible antes que espectacular. La brecha digital tampoco se reduce simplemente poniendo más servicios en Internet.
Dos aplicaciones nativas y doce años de cambios
También está la parte menos visible de la historia. No teníamos una app. Teníamos dos.
Dos SDK, dos tiendas, dos sistemas de permisos y dos ciclos de publicación. Mientras tanto, las plataformas evolucionaban de manera independiente: Android cambió, iOS cambió, Google Play cambió y App Store cambió. También cambiaron los mecanismos de notificación y envejecieron las librerías.
La expectativa del ciudadano seguía siendo exactamente la misma: abro la aplicación y funciona.
Legacy no significa necesariamente software malo
Cuando un sistema sobrevive más de una década es inevitable encontrar código que hoy escribirías de otra manera: Java de otra época, Objective-C cuando hoy probablemente empezaríamos con Swift, librerías que ya no elegiríamos, APIs que han cambiado y backends que han acumulado historia.
Muchas veces legacy significa simplemente software que ha sobrevivido el tiempo suficiente como para convertirse en importante.
Esta forma de verlo también está detrás de mi enfoque sobre arquitectura y modernización de software: no todo sistema antiguo necesita una reescritura, pero sí entender qué conservar, qué desacoplar y qué modernizar.
Vicopo no era realmente una app
Con perspectiva, esta es probablemente una de las conclusiones más claras. El ecosistema incluía Android en Java, iOS en Objective-C, una API REST ligera desarrollada con Slim Framework, MySQL, backoffices en Laravel, portales web, WordPress y desarrollos a medida, mapas, geolocalización, notificaciones, almacenamiento local y procesos municipales.
Es también la misma idea que aplico hoy cuando hablo de desarrollo de software a medida: la aplicación visible importa, pero la arquitectura, las APIs, los datos y los procesos que quedan detrás son los que determinan si el sistema puede evolucionar.
La app era solo la superficie
Cuando algo falla en cualquiera de esas capas, el ciudadano no ve una arquitectura distribuida, ni un problema de sincronización, ni una dependencia incompatible. Ve algo mucho más sencillo: «la app no funciona».
Por eso, con los años, dejas de pensar únicamente en aplicaciones. Empiezas a pensar en sistemas y servicios.
De Smart City a GovTech municipal
En aquella época era bastante habitual hablar de Smart City. Sensores. IoT. Movilidad. Participación. Datos. Servicios conectados. Una parte de La Pobla Info encajaba perfectamente en esa conversación. Pero hoy veo también otra lectura. Además, esa evolución no es solo terminológica: el Interoperable Europe Act de la Comisión Europea refuerza la interoperabilidad y la cooperación digital entre administraciones públicas.
La tecnología no reparaba la farola. Tampoco redactaba el bando ni organizaba una actividad cultural. Mucho menos gestionaba por sí sola el municipio. Su función era otra: reducir la distancia entre quien necesitaba un servicio y quien podía prestarlo.
Smart City sin empezar por los sensores
Una ciudad inteligente no tiene por qué empezar instalando sensores en cada farola.
Puede empezar simplemente consiguiendo que la información circule mejor entre quienes viven en el municipio y quienes lo gestionan.
Lo que no ha cambiado desde 2014
Android 2026 se parece bastante poco al Android con el que empezamos. El ecosistema de Apple tampoco es el mismo. Con el tiempo cambiaron los frameworks, las stores y las APIs. Aun así, la expectativa del ciudadano permanece sorprendentemente estable.
Pero las preguntas del vecino siguen siendo sorprendentemente reconocibles: ¿qué está pasando hoy?, ¿hay algún aviso importante?, ¿qué actividades hay este fin de semana?, ¿puedo comunicar este problema?, ¿dónde encuentro el servicio que necesito?
Conclusiones: probablemente ya estábamos haciendo GovTech municipal
Cuando empezamos con este tipo de aplicaciones en 2014 no necesitábamos una etiqueta para explicarlo. Hacíamos apps para ayuntamientos: Android en Java, iOS en Objective-C, APIs, backoffices, mapas y push.
Pero debajo de toda esa tecnología había algo más importante: conseguir que un vecino supiera qué estaba ocurriendo en su municipio, que pudiera recibir un bando cuando todavía era relevante, que descubriera una actividad, que encontrara una farmacia o información de transporte, que recibiera un aviso importante y que pudiera comunicar un problema sin conocer la estructura interna del Ayuntamiento.
Una noticia municipal bien distribuida es un servicio.
Un evento que puedo descubrir y recordar es un servicio.
Un bando que llega cuando todavía es útil es un servicio.
Una notificación relevante es un servicio.
Una incidencia que puede viajar desde el teléfono del vecino hasta quien puede solucionarla es un servicio.
La aplicación era la superficie donde todas esas piezas se encontraban. Y quizá por eso me interesa el GovTech municipal. No tanto por la palabra, sino por la parte bastante menos espectacular y mucho más difícil: construir pequeños puentes digitales entre una Administración y las personas, y conseguir que sigan siendo útiles cuando pasan los años y cambia prácticamente toda la tecnología que existe debajo. En definitiva, visto con doce años de perspectiva, probablemente aquello ya era GovTech municipal.
La pregunta que me queda
Si hoy tuviera que diseñar este ecosistema de nuevo, ya no empezaría preguntando qué app necesita el Ayuntamiento.
Empezaría preguntando qué necesita poder hacer el ciudadano y desde qué canales debería poder hacerlo.
Ahí empieza el siguiente artículo de esta serie.
Si trabajas con software público, administraciones o productos digitales municipales, me interesa especialmente conocer qué parte te resulta más difícil: la tecnología, las integraciones, mantener los datos actualizados o conseguir que el servicio encaje con los procesos reales de la Administración.
Deja una respuesta