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