Ir al contenido principal

⚙️ 𝐄𝐥 𝐄𝐬𝐭𝐚𝐝𝐨, 𝐥𝐚 𝐝𝐞𝐮𝐝𝐚 𝐭𝐞𝐜𝐧𝐨𝐥ó𝐠𝐢𝐜𝐚 𝐲 𝐞𝐥 𝐦𝐢𝐭𝐨 𝐝𝐞 𝐪𝐮𝐞 𝐭𝐨𝐝𝐨 𝐞𝐬𝐭á 𝐦𝐚𝐥

Han visto que siempre cuando una casa tiene una muralla descascarada, aparece alguien diciendo que hay que botarla completa y construir una nueva.

Como si los años de historia, las reparaciones hechas y las partes que siguen funcionando no existieran.

Con el Estado pasa algo parecido.

Es fácil mirar la deuda tecnológica de algunos organismos públicos y concluir que todo está obsoleto, que nada funciona y que la única solución es empezar desde cero.

Pero la realidad suele ser bastante más compleja.

Sí, existe deuda tecnológica.

Sí, existen sistemas antiguos.

Sí, hay procesos que todavía cargan con decisiones tomadas hace décadas.

Eso ocurre en el sector público.

Y también ocurre en bancos, aseguradoras, retail, telecomunicaciones y grandes empresas privadas.

La diferencia es que cuando falla una empresa, el problema afecta a sus clientes.

Cuando falla una institución pública, el problema aparece en los titulares.

Por eso muchas veces la percepción es peor que la realidad.

Como viejo cascarrabias tecnológico, puedo decir algo que no siempre gusta escuchar:

Mantener funcionando sistemas que atienden a millones de personas durante años tampoco es una tarea menor.

Detrás de muchos servicios públicos existen profesionales que sostienen plataformas complejas, integraciones históricas y procesos críticos que no pueden simplemente apagarse un fin de semana para empezar de nuevo el lunes.

Porque modernizar una aplicación interna es una cosa.

Modernizar sistemas que pagan beneficios, administran información sensible o sostienen servicios esenciales para un país entero es otra muy distinta.

La deuda tecnológica existe.

Pero también existe experiencia acumulada.

Existe conocimiento institucional.

Existen equipos comprometidos.

Existen avances que muchas veces pasan desapercibidos porque la gente solo nota la tecnología cuando falla.

Y ahí está la lección.

No todo está bien.

Pero tampoco todo está mal.

La transformación digital del Estado no consiste en reemplazar cada sistema antiguo por el software de moda del momento.

Consiste en identificar qué debe modernizarse, qué puede evolucionar y qué sigue cumpliendo adecuadamente su función.

Porque la edad de una tecnología no siempre determina su valor.

Lo que importa es si sigue siendo segura, mantenible y capaz de responder a las necesidades actuales.

Las organizaciones maduras entienden que la modernización no es una demolición.

Es una renovación progresiva.

Y eso aplica tanto para una empresa privada como para el Estado.

Porque al final, la verdadera discusión no debería ser cuántos años tiene un sistema.

La pregunta importante es si está ayudando o dificultando el futuro que queremos construir.

Y aunque queda mucho camino por recorrer, también es justo reconocer algo que a veces olvidamos:

Hay más personas trabajando para mejorar las cosas de las que suelen aparecer en las noticias. 🇨🇱🚀

Y cuando uno mira con atención, descubre que entre los sistemas antiguos y las nuevas iniciativas, hay bastante más progreso del que los pesimistas profesionales están dispuestos a admitir. 🦉✨⚙️

Comentarios

Entradas más populares de este blog

Épicas, Requerimientos, Historias de Usuario y Tareas: El ADN de un proyecto ágil 🛠️📋

En el mundo ágil, estructurar el trabajo en épicas, requerimientos, historias de usuario y tareas es clave para gestionar proyectos complejos de forma eficiente. Esta jerarquía ayuda a conectar grandes objetivos con las acciones concretas del equipo, asegurando que cada esfuerzo aporte valor real al cliente. 🏔️ Épicas: La gran visión Las épicas son iniciativas amplias que representan metas estratégicas a largo plazo. Por ejemplo, en una app de compras: "Permitir a los usuarios realizar pedidos en línea". Estas grandes ideas se dividen en partes más manejables para facilitar su ejecución. 📜 Requerimientos: La base técnica Los requerimientos definen qué debe cumplir el producto. Son más específicos, como: "El sistema debe enviar correos de confirmación al procesar pedidos". En metodologías ágiles, estos se traducen en historias de usuario para conectar mejor con los objetivos del cliente. 👤 Historias de Usuario: El enfoque humano Las historias de usuario convierten...

Tiempo de gestión: ¿Quién tiene el mono?

En el ámbito laboral, uno de los desafíos más comunes para los líderes y colaboradores es la gestión adecuada del tiempo y las responsabilidades. Un concepto que lo ilustra muy bien es el del "mono en la espalda" , una metáfora acuñada por William Oncken y Donald L. Wass en su famoso artículo de Harvard Business Review, “Management Time: Who’s Got the Monkey?” . El mono representa una tarea, problema o responsabilidad que, sin una buena gestión, puede saltar del empleado al supervisor o a un compañero de equipo. Este fenómeno ocurre cuando un colaborador, al encontrarse ante una dificultad o una tarea compleja, decide acudir a su jefe o compañero en busca de ayuda o una solución. La conversación termina con la sensación de que, en lugar de haber recibido apoyo para resolver el problema, la responsabilidad ahora recae sobre la otra persona. El "mono" ha saltado de una espalda a otra. Para evitar esta trampa, es fundamental aplicar el concepto de delegación efectiv...

"El Que No Puede, Enseña": Una Mirada desde la Metodología Ágil

En el ámbito de las metodologías ágiles, hay una frase comúnmente tergiversada: "El que no puede, enseña." Esta declaración, frecuentemente utilizada de manera peyorativa, sugiere que aquellos que no pueden hacer algo, optan por enseñarlo en su lugar. Sin embargo, al profundizar en la filosofía ágil y en las prácticas de enseñanza dentro de este marco, podemos descubrir una verdad más matizada y, en última instancia, más positiva. La Enseñanza en el Contexto Ágil En el mundo de la agilidad, enseñar y aprender son componentes vitales. La transmisión de conocimientos no solo es fundamental para el desarrollo continuo de los equipos, sino que también es un pilar del Manifesto Ágil, que promueve "individuos y su interacción sobre procesos y herramientas." Enseñar en este contexto no es una señal de incapacidad, sino una manifestación de liderazgo y compromiso con la mejora continua. El Papel del Scrum Master Tomemos como ejemplo al Scrum Master. Este rol es esencial...