De Agilidad y otras hierbas

Durante años, muchas organizaciones trataron la seguridad como la última etapa del desarrollo. Primero se analizaban los requerimientos. Después se desarrollaba. Luego se probaba. Se desplegaba... Y recién al final alguien preguntaba: "¿Ya revisó seguridad?" Ese modelo ya no funciona. DevSecOps dejó de ser una buena práctica para convertirse en una necesidad estratégica. Hoy las organizaciones enfrentan amenazas constantes, ataques automatizados, cadenas de suministro de software vulnerables, dependencias de terceros y regulaciones cada vez más exigentes. En este escenario, la seguridad no puede seguir siendo un cuello de botella ni una auditoría al final del proyecto. Debe formar parte del proceso desde el primer día. Pero DevSecOps no significa simplemente agregar herramientas como SonarQube, SAST, DAST, escaneo de contenedores o análisis de dependencias. DevSecOps significa incorporar la seguridad como una responsabilidad compartida entre todos los actores del ciclo de vid...

Hubo un tiempo en que hablar de DevOps era casi una moda. Bastaba con instalar un servidor de CI/CD, crear un par de pipelines y decir que la organización ya era "DevOps". Hoy eso ya no es suficiente. DevOps dejó de ser un juego. Las organizaciones que siguen viendo DevOps como una tarea exclusiva del área de infraestructura o como un conjunto de herramientas están perdiendo competitividad. DevOps no se trata de Azure DevOps, GitHub, Jenkins, Docker o Kubernetes. Se trata de transformar la forma en que una organización desarrolla, prueba, asegura, despliega, monitorea y mejora sus productos digitales. Cuando una empresa toma DevOps en serio, ocurren cambios profundos: ✅ Los despliegues dejan de ser eventos traumáticos. ✅ La automatización reemplaza tareas manuales repetitivas. ✅ La seguridad se incorpora desde el inicio (DevSecOps). ✅ La calidad deja de depender de la suerte. ✅ La observabilidad permite detectar problemas antes que los usuarios. ✅ El tiempo de entrega pasa d...

Han visto que siempre cuando uno va al supermercado por una sola cosa, termina saliendo con tres bolsas, dos antojos y preguntándose en qué momento el carrito tomó decisiones por uno. La vida tiene ese raro sentido del humor: uno entra buscando una cosa y termina encontrando otra. Algo parecido nos dejó este Mundial. Con la ampliación a 48 selecciones, aparecieron equipos que hace algunos años jamás habrían tenido un cupo. Muchos ni siquiera sabíamos que existían futbolísticamente. Y, sin embargo, cuando les dieron la cancha, demostraron que sabían jugar. Algunos emocionaron, otros sorprendieron y varios hicieron tambalear a los gigantes. No eran malos. Solo nunca les habían dado la oportunidad de mostrarse. Y ahí es donde el fútbol deja de ser solo fútbol. Porque la vida está llena de personas jugando clasificatorias eternas, pero sin que nadie les abra la puerta del estadio. Pienso en esos chiquillos que uno ve vendiendo en la calle, atendiendo un negocio, trabajando desde muy jóvene...

Han visto que siempre cuando uno compra una herramienta vieja en una feria, oxidada, golpeada por décadas de uso, todavía funciona mejor que muchas cosas nuevas recién salidas de fábrica. Eso me hace pensar en una expresión que escucho cada vez más: "informática artesanal" para referirse a sistemas mal diseñados, soluciones improvisadas o software hecho sin estándares. Y qué injusticia más grande es esa. La artesanía nunca fue sinónimo de chapuza. Todo lo contrario. Un artesano era la persona que conocía su oficio tan profundamente que podía crear algo con sus propias manos y hacer que sobreviviera generaciones. Detrás de una silla, una espada, una vasija o un reloj artesanal había años de aprendizaje, errores, perfeccionamiento y conocimiento transmitido de maestro a aprendiz. La artesanía es experiencia acumulada. Es conocimiento refinado por el tiempo. Es obsesión por los detalles. Cuando alguien construye un sistema informático desordenado, lleno de parches, dependencias...

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