De Agilidad y otras hierbas

Han visto que siempre cuando alguien guarda una llave "en un lugar súper seguro para no perderla", pasan unos meses y nadie tiene idea dónde quedó. Entonces aparecen las teorías, las búsquedas desesperadas y las frases mágicas: "Solo Juan sabe dónde está." "Siempre se ha hecho así." "No toquen nada porque funciona." En tecnología, esa frase debería encender más alarmas que una sirena de incendio. Durante años muchas organizaciones construyeron infraestructura de memoria. Servidores configurados a mano. Redes documentadas en una servilleta. Permisos otorgados por tradición oral. Procesos que viven únicamente en la cabeza de alguien que lleva quince años en la empresa. Y así nace una de las formas más caras de deuda tecnológica. La infraestructura invisible. La que existe, funciona y genera valor... hasta que alguien se va de vacaciones, cambia de trabajo o se jubila. Ahí comienza la arqueología digital. Equipos enteros intentando entender quién cr...

Han visto que siempre cuando alguien dice "no voy a arreglar esa gotera ahora porque todavía son solo unas gotitas", unos años después termina cambiando medio techo. La gotera nunca desapareció. Solo estuvo acumulando intereses. Con la deuda tecnológica ocurre exactamente lo mismo. Nace de decisiones que, en su momento, parecen razonables. "Lo hacemos rápido y después lo arreglamos." "Por ahora dejémoslo así." "Más adelante modernizamos." "Lo importante es salir a producción." Y así pasan los meses. Luego los años. Y lo temporal se transforma en permanente. Empiezan a aparecer sistemas que nadie entiende completamente. Procesos que dependen de una sola persona. Integraciones construidas con cinta adhesiva digital. Servidores que llevan tanto tiempo funcionando que parecen patrimonio histórico de la organización. Lo peor es que al principio la deuda tecnológica se ve barata. Porque permite avanzar rápido. Permite cumplir plazos. Permite ...

Han visto que siempre cuando alguien escucha un ruido extraño en el auto, decide subir el volumen de la radio. Durante un tiempo parece funcionar. El ruido sigue ahí, pero ya no se escucha. Hasta que un día el auto decide expresar sus sentimientos de manera mucho más costosa. En tecnología y en las organizaciones ocurre exactamente lo mismo. Muchas áreas viven atrapadas en modo reactivo. Corriendo detrás de incidentes. Apagando incendios. Resolviendo urgencias. Atendiendo requerimientos de último minuto. Celebrando que lograron sobrevivir una semana más. Y ojo, no siempre es culpa de las personas. Muchas veces es consecuencia de años de acumulación de deuda tecnológica, falta de planificación, escasez de recursos o una cultura donde solo recibe atención aquello que está ardiendo. Porque seamos sinceros. Nadie felicita al equipo porque un sistema no se cayó. Nadie hace una ceremonia porque una vulnerabilidad fue corregida antes de generar un incidente. Nadie publica un comunicado celebr...

Han visto que siempre cuando hay que empujar un auto en panne, aparece alguien que toma una esquina del vehículo con un dedo y después dice: "Yo cumplí con mi parte." Técnicamente puede tener razón. Pero el auto sigue sin moverse. En el trabajo ocurre algo parecido. ¿Es válido hacer solamente lo que corresponde a tu cargo? Sí. Absolutamente. Nadie está obligado a resolver todos los problemas de la organización. Nadie puede convertirse en experto en todo. Nadie debería cargar responsabilidades que no le corresponden. Los límites son necesarios. Las funciones existen por una razón. Pero existe una diferencia importante entre tener límites profesionales y vivir encerrado dentro de ellos. Como viejo gruñón, he conocido personas que hacían exactamente lo que decía su contrato. Ni más ni menos. Llegaban a la hora. Cumplían sus tareas. No cometían errores. Y también descubrí que muchas veces eran incapaces de comprender por qué sus carreras se quedaban estancadas. Porque las organiz...

Han visto que siempre cuando un reloj se atrasa, casi nadie culpa a un engranaje específico. La gente simplemente dice: "El reloj no funciona." Nadie pregunta cuál rueda dentada falló. Porque todos entienden que el valor está en el conjunto. En tecnología, y especialmente en organizaciones grandes, esa lección suele llegar tarde. Muchos profesionales comienzan su carrera pensando en su propia área. El desarrollador ve código. El administrador ve servidores. El especialista de redes ve conectividad. El DBA ve bases de datos. Y cada uno defiende su territorio como si fuera un pequeño reino independiente. Eso es la lógica de la jerarquía tradicional. Áreas separadas. Responsabilidades delimitadas. Información que sube y baja por canales definidos. Y aunque ese modelo sigue siendo necesario para ordenar organizaciones complejas, tiene una limitación importante. Los problemas reales rara vez respetan los organigramas. Ahí aparece la redarquía. No como reemplazo de la jerarquía, si...

Han visto que siempre cuando uno llama a un maestro para arreglar una puerta, algunos solo cambian la bisagra y se van. Otros, en cambio, preguntan por qué se rompió, revisan el marco, miran la humedad de la pared y descubren que el problema nunca fue la bisagra. En informática ha ocurrido una evolución parecida. Durante muchos años existió una visión bastante clara: "El informático se preocupa de los computadores." Y punto. Si el sistema funcionaba técnicamente, la misión estaba cumplida. El problema es que el mundo cambió. Hoy un profesional de tecnología que solo entiende tecnología corre el riesgo de convertirse en un especialista cada vez más desconectado de la realidad que intenta resolver. Porque los sistemas ya no existen aislados. Están conectados con procesos, normativas, presupuestos, auditorías, usuarios, experiencia cliente, estrategia y objetivos institucionales. Como viejo cascarrabias, siempre me causa gracia cuando alguien dice: "Eso no me corresponde, y...

Han visto que siempre cuando una ampolleta se quema en la casa, nadie piensa que la solución es poner a una persona a soplar electricidad durante 48 horas seguidas hasta que vuelva la luz. Suena absurdo. Sin embargo, en muchas organizaciones ocurre exactamente eso, pero con computadores. Cuando aparece una tarea repetitiva, un proceso manual interminable o una operación crítica que consume días completos, la respuesta suele ser la misma: "Que lo haga informática." Y ahí aparece el héroe involuntario. El profesional que pasa noches enteras ejecutando scripts, moviendo archivos, actualizando registros, conciliando datos o realizando procesos que debieron automatizarse hace años. Lo más curioso es que después algunos celebran el esfuerzo. "El equipo se sacó la mugre." "Trabajaron todo el fin de semana." "Estuvieron 48 horas resolviendo el problema." No. Eso no es una victoria. Es una alarma. Porque en pleno siglo XXI, con automatización, orquestació...

Han visto que siempre cuando uno entra a una ferretería a comprar un tornillo, aparece alguien golpeando una llave inglesa contra la mesa como si estuviera dirigiendo una orquesta. Hace ruido, se hace notar, y uno piensa que debe ser el maestro del lugar. Después aparece el viejo medio cascarrabias del rincón, el que apenas habla, te mira de reojo y con tres palabras te dice exactamente cuál es el tornillo que necesitas. Cosas de la vida. Y es que una cosa es mostrarse y otra muy distinta es andar desesperado por ser visto a cualquier precio. Porque la presencia no se compra con gritos ni con exhibiciones permanentes. La presencia se construye con coherencia, con trabajo y con algo que los años me enseñaron a porrazos: quien vale, no necesita andar tocando la campana cada cinco minutos para recordar que existe. Hay gente que confunde visibilidad con valor. Como si el aplauso fuera alimento. Y claro, los aplausos son ricos, pero duran menos que la batería del celular cuando uno más la n...

Han visto que siempre cuando alguien visita una represa, pregunta por qué no abren todas las compuertas de una sola vez para que el agua salga más rápido. Desde afuera parece una decisión sencilla. Hasta que uno entiende que detrás hay cálculos, normas, riesgos y consecuencias que no se ven a simple vista. Con los sistemas del Estado ocurre algo parecido. Muchas personas creen que modificar una funcionalidad es tan simple como pedirlo. "Agreguen este botón." "Cambien esta regla." "Saquen este requisito." "Automaticen este proceso." Y a veces incluso se molestan cuando la respuesta no es inmediata. Pero en el sector público las cosas suelen ser más complejas. Porque un sistema no siempre refleja una decisión tecnológica. Muchas veces refleja una ley. Un reglamento. Una normativa. Un dictamen. Un procedimiento administrativo. Un requisito de control. Una obligación legal. Y eso cambia completamente la conversación. Como viejo gruñón tecnológico, ap...

Han visto que siempre cuando uno se compra una planta, aparece alguien diciendo que mejor hubiera comprado una artificial porque "dura más". Como si todo lo que vale tuviera que durar para siempre o dar ganancias inmediatas. Algo parecido pasa con las carreras que algunos iluminados llaman "sin futuro". Esa visión pequeñita, casi de calculadora con pilas gastadas, cree que el valor de una profesión se mide únicamente por la plata que genera. Y aquí habla este viejo medio mañoso y con más años que entusiasmo por las reuniones largas: una carrera no es una acción en la bolsa. No se estudia solamente para perseguir un sueldo, se estudia también por vocación, por curiosidad, por aportar algo, por dejar una huella y, a veces, simplemente porque uno quiere entender mejor el mundo. La historia está llena de gente que escuchó que lo suyo "no servía para nada". Artistas, filósofos, historiadores, científicos y profesores. Curioso, porque después la humanidad termin...

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

Me estaba preparando un café y casi tiro la primera taza al escuchar en las noticias eso de las "incivilidades". Pensé que estaban hablando de una nueva enfermedad o de un club de señoras indignadas por las palomas. 💡 Les cuento una cosa. Uno aprende que mientras más elegante suena una palabra, más probable es que esté tratando de evitar otra mucho más directa. "Incivilidades" es una de esas joyitas siúticas. Es como decir "evento desafortunado" cuando alguien se mandó un cag.... monumental, o "desvinculación laboral" cuando te pegaron la patada. Se han fijado que antes uno decía: ✔️ "Se estacionó como las reverendas." ✔️ "Dejó la basura tirada." ✔️ "Se mandó un cag..." Y listo. Todo el mundo entendía. Ahora aparece un experto en televisión diciendo: ➜ "Estamos observando un aumento de las incivilidades en el espacio urbano". ¡Pero si el compadre botó una bolsa al suelo y rayó una pared, no redactó la caíd...

Han visto que siempre cuando alguien no encuentra algo en la casa, después de buscar diez segundos declara solemnemente: "Ya revisé todo, no está." Y cinco minutos después aparece exactamente donde debía estar. No era que no existiera. Simplemente no sabía dónde buscar. En tecnología ocurre una confusión parecida y bastante peligrosa. Cada vez que alguien escucha una propuesta nueva suele aparecer una frase conocida: "Eso no se puede hacer." A veces es verdad. Pero muchas veces significa algo completamente distinto: "No sé cómo hacerlo." Y esas dos cosas no son iguales. Ni remotamente iguales. Una limitación técnica es una restricción real. Puede ser una limitación del producto, una restricción legal, un problema físico, una incompatibilidad tecnológica o una barrera económica que hace inviable una solución. Son límites objetivos. Existen aunque el mejor experto del mundo participe en el proyecto. El desconocimiento, en cambio, es otra cosa. Es una limitac...

Han visto que siempre cuando uno arma un mueble y sobra una pieza, aparece el optimista de turno diciendo: "Debe venir de repuesto." Y sigue armando como si nada. Horas después descubre que esa pieza era precisamente la que sostenía toda la estructura. En tecnología pasa algo parecido con el conocimiento. He escuchado demasiadas veces frases como: "Eso no se puede." "Nadie sabe hacerlo." "La plataforma no lo permite." "Siempre se ha hecho así." Y cada vez que escucho algo parecido, me surge la misma sospecha. ¿Estamos frente a una limitación real o simplemente frente a algo que todavía no hemos aprendido? Porque existe una diferencia enorme entre ambas cosas. Como viejo gruñón que ha sobrevivido a varias generaciones de tecnologías, lenguajes, metodologías y modas corporativas, aprendí una verdad bastante simple: No saber algo no es un problema. Negarse a aprenderlo sí lo es. Nadie nace sabiendo arquitectura, nube, automatización, segur...

Han visto que siempre cuando alguien se compra un teléfono nuevo, hay dos tipos de personas. La primera aprieta botones, investiga, se equivoca, pregunta y en una semana ya domina funciones que ni el fabricante sabía que existían. La segunda usa el mismo equipo durante cinco años exactamente igual que el primer día y se enoja cuando algo cambia de lugar. En tecnología pasa algo parecido. Nadie está obligado a saberlo todo. De hecho, es imposible. Las tecnologías cambian más rápido que los organigramas y aparecen herramientas nuevas antes de que terminemos de aprender las anteriores. Por eso, no saber algo jamás debería ser motivo de crítica. Lo preocupante aparece cuando una persona decide que tampoco quiere aprenderlo. Porque ahí el problema deja de ser técnico. Se transforma en cultural. He visto profesionales con décadas de experiencia reinventarse varias veces durante su carrera. Y también he visto personas quedarse detenidas durante diez años defendiendo el mismo conocimiento mien...

Han visto que siempre cuando alguien guarda una receta solamente en su memoria, está convencido de que jamás la olvidará. Hasta que llega el día en que intenta repetirla y descubre que faltan ingredientes, pasos y detalles que parecían imposibles de olvidar. En tecnología ocurre algo parecido. Por eso la pregunta muchas veces no debería ser: "¿Por qué utilizar Infraestructura como Código?" Sino más bien: "¿Por qué seguir sin utilizarla?" Porque cuando una organización decide administrar infraestructura manualmente, está aceptando una serie de riesgos que suelen pasar desapercibidos. Cada servidor configurado a mano puede terminar siendo distinto. Cada cambio manual puede introducir errores difíciles de rastrear. Cada procedimiento no documentado puede transformarse en dependencia de una sola persona. Cada emergencia puede convertirse en una expedición arqueológica para descubrir cómo fue configurado algo años atrás. Como viejo gruñón tecnológico, he escuchado varias...

Han visto que siempre cuando alguien tiene que armar un mueble por segunda vez, piensa: "Ahora sí me acuerdo cómo era." Y termina mirando el manual nuevamente porque la memoria humana tiene una relación bastante creativa con la realidad. Durante décadas, gran parte de la infraestructura tecnológica funcionó de forma parecida. Servidores configurados a mano. Redes creadas siguiendo instrucciones guardadas en correos antiguos. Cambios realizados a las tres de la mañana por alguien que prometió documentarlos después. Y todos sabemos cómo termina esa historia. Con un archivo llamado "versión_final_definitiva_ahora_si_v12.xlsx". La Infraestructura como Código llegó para resolver ese problema. Transformó configuraciones manuales en código reutilizable, versionado y reproducible. Pero ahora estamos entrando en una nueva etapa. La Infraestructura como Código asistida por Inteligencia Artificial. Y no, no significa que una IA administrará sola todo el centro de datos mientra...

Han visto que siempre cuando alguien deja las llaves en un lugar "para no olvidarlas", termina olvidando dónde las dejó. Y después pasa media hora buscando algo que podría haberse evitado con una simple costumbre. Las organizaciones hacen algo parecido todos los días. Repiten errores conocidos. Olvidan lecciones aprendidas. Ignoran señales tempranas. Y vuelven a tropezar con problemas que ya habían resuelto antes. Por eso aparece una pregunta interesante: ¿Podemos utilizar Inteligencia Artificial para prevenir errores? La respuesta corta es sí. Pero probablemente no de la forma que muchos imaginan. La IA no es una bola de cristal. No puede predecir el futuro con certeza. No sabe qué ocurrirá mañana. Lo que sí puede hacer es detectar patrones que los seres humanos suelen pasar por alto. Puede identificar comportamientos anómalos. Puede encontrar tendencias. Puede advertir desviaciones. Puede analizar miles o millones de registros mucho más rápido que cualquier equipo humano. Y...

Han visto que siempre cuando alguien quiere construir una casa, pasa horas eligiendo el color de las paredes, la terraza soñada y el tamaño de las ventanas. Pero rara vez pregunta primero cómo está el suelo donde piensa construirla. Y después vienen las sorpresas. Porque una casa espectacular construida sobre un terreno inestable sigue siendo un problema espectacular. En tecnología ocurre algo parecido entre la Arquitectura de Soluciones y la Arquitectura de Infraestructura. Desde lejos parecen similares. Desde cerca tienen responsabilidades muy distintas. La Arquitectura de Soluciones mira el negocio y los sistemas como un todo. Se preocupa por responder preguntas como: ¿Cómo resolvemos esta necesidad? ¿Qué aplicaciones participan? ¿Cómo se integran? ¿Qué experiencia tendrá el usuario? ¿Qué datos viajarán entre sistemas? ¿Cómo generamos valor para la organización? Su foco está en la solución completa. La Arquitectura de Infraestructura, en cambio, mira los cimientos. Se preocupa por l...

Han visto que siempre cuando alguien compra un terreno, lo primero que hace es imaginar la casa terminada. Ve la terraza, el jardín, la cocina y hasta dónde irá la parrilla. Pero entre esa idea y la casa construida existe una pequeña diferencia llamada realidad. Y esa realidad necesita planos, cálculos, materiales y mucha gente trabajando en conjunto. En tecnología ocurre algo parecido. Muchas veces se confunde Arquitectura de Soluciones con Desarrollo de Software, como si fueran la misma disciplina con distinto nombre. Pero no lo son. El arquitecto de soluciones mira el problema completo. Entiende el negocio. Evalúa restricciones. Analiza sistemas existentes. Define integraciones. Considera seguridad, escalabilidad, costos, operación y sostenibilidad. Su pregunta principal es: "¿Cuál es la mejor forma de resolver este problema?" El desarrollador, en cambio, transforma esa visión en realidad. Diseña componentes. Escribe código. Construye funcionalidades. Prueba soluciones. Co...

Han visto que siempre cuando alguien compra una cocina nueva, cree que automáticamente se convirtió en chef. La cocina ayuda. Pero el estofado todavía puede quedar horrible. Con DevOps y la automatización pasa exactamente lo mismo. Muchas organizaciones creen que porque tienen pipelines, scripts, despliegues automáticos o infraestructura como código ya son DevOps. No. Eso es automatización. Y la diferencia es mucho más importante de lo que parece. La automatización consiste en que las máquinas hagan tareas repetitivas por nosotros. Desplegar aplicaciones. Crear servidores. Ejecutar respaldos. Configurar ambientes. Actualizar sistemas. Todo eso es valioso. Y mientras más repetitiva sea una tarea, más sentido tiene automatizarla. Pero DevOps es otra cosa. DevOps es una cultura. Es una forma de trabajar donde desarrollo, operaciones, seguridad y negocio dejan de actuar como islas enemigas que se lanzan problemas por encima de un muro. Porque seamos honestos. Durante años el modelo fue más...

Han visto que siempre cuando alguien decide ponerse en forma después de quince años sin hacer ejercicio, al segundo día ya está mirando zapatillas profesionales, relojes deportivos de última generación y videos de atletas olímpicos. Todavía no logra subir una escalera sin jadear, pero ya está comparándose con quienes llevan años entrenando. Las organizaciones atrasadas digitalmente suelen caer en la misma trampa. Un día despiertan y descubren que están quince años detrás del mercado. Los procesos siguen en planillas eternas, los correos reemplazan sistemas completos, las aprobaciones pasan por cinco escritorios y todavía existen documentos que parecen haber sobrevivido a varias eras geológicas. Entonces aparece la gran idea: "Tenemos que estar al nivel de los líderes de la industria en doce meses." Y ahí comienza la carrera. Compran plataformas gigantescas. Contratan consultoras. Hablan de inteligencia artificial, automatización, analítica avanzada y transformación digital co...

Han visto que siempre cuando uno sale con paraguas porque el cielo parece el fin del mundo, termina volviendo a la casa con el paraguas seco y la frente quemada por el sol. Curiosa costumbre humana esa de prepararse para la tormenta que nunca llega. En los puestos de jefatura pasa algo parecido. He conocido personas que siempre esperan el peor resultado posible. Si un proyecto va bien, imaginan que algo explotará. Si el equipo está motivado, sospechan que pronto aparecerá un problema. Si los números mejoran, creen que es cuestión de tiempo para que todo se derrumbe. Y ojo, no siempre nace del pesimismo. Muchas veces nace de la responsabilidad. Cuando te toca responder por otros, aprendes a mirar los riesgos. Aprendes a preguntarte qué podría salir mal. Es una habilidad necesaria. El problema aparece cuando la prevención se transforma en residencia permanente y uno termina viviendo en el peor escenario imaginable. Un líder que solo ve catástrofes termina transmitiendo catástrofes. El eq...