Imaginemos un equipo de datos que presume de cumplir todos los “sprints” sin desviaciones. Las tareas se cierran a tiempo, la velocidad de entrega es constante y las retrospectivas son siempre positivas. Sin embargo, el portfolio de datos —cuadros de mando, pipelines, informes— crece sin parar y nunca se reduce. Esta situación, lejos de ser una coincidencia, es la consecuencia directa de medir lo que no importa: cerrar una incidencia no es lo mismo que generar valor. Durante años, muchas organizaciones han confundido actividad con productividad, acumulando activos digitales que consumen recursos sin aportar retorno.
El problema no es técnico, sino de disciplina directiva. En cualquier otra área de la empresa, un producto que no funciona se retira del mercado; una campaña que no convence se detiene; una inversión que no rinde se desinvierte. Sin embargo, cuando hablamos de datos, la reacción instintiva es añadir más: más fuentes, más herramientas, más ingenieros. Nadie se detiene a preguntar ¿qué podemos dejar de hacer? Esta asimetría genera lo que yo denomino “deuda de datos”: un pasivo silencioso que lastra la agilidad del equipo.
La clave está en aplicar el mismo rigor que dedicamos a la gestión de costes en otras partidas. Del mismo modo que una empresa no mantiene una tienda física vacía porque sí, no debería conservar un panel de control que nadie ha abierto en seis meses. Para romper este círculo, propongo tres pasos concretos que cualquier equipo puede adoptar desde el próximo trimestre.
El primer paso es realizar un inventario honesto. No basta con saber qué se ha construido; hay que documentar cuándo fue la última vez que se usó, cuánto cuesta mantenerlo (cómputo, almacenamiento, horas de mantenimiento) y cuántas personas lo echarían de menos si desapareciera un mes. Esta información suele estar disponible en los logs de las herramientas de BI y en los sistemas de monitorización; solo falta recopilarla y plantear la pregunta difícil.
El segundo paso es establecer un proceso de retirada tan formal como el de nuevas funcionalidades. Cada candidato a ser retirado debe pasar por la misma planificación trimestral que las nuevas características: mismos stakeholders, mismas estimaciones en story points, misma definición de “hecho” (detener el pipeline, archivar el dashboard, eliminar reglas de alerta, documentar el cambio). Y, sobre todo, si un interesado se opone, no tiene poder de veto; se convierte automáticamente en el responsable visible de los costes asociados, con un registro accesible para todo el equipo. Este mecanismo transforma un “por si acaso” en una decisión formal con consecuencias reales.
El tercer paso es cambiar los indicadores. La velocidad de sprint y la tasa de cierre de tickets no reflejan si el portfolio se está haciendo más ágil o simplemente más grande. En lugar de eso, hay que medir dos cosas: 1) si el tiempo oculto que el negocio dedica a sortear malos productos de datos se reduce trimestre a trimestre, y 2) si el equipo tiene capacidad real para construir, o si está dedicando toda su energía a sobrevivir a su propia acumulación. Estos indicadores, aunque menos habituales, son mucho más predictivos del valor real que la organización obtiene de sus datos.
En Q2BSTUDIO, sabemos que la gestión del ciclo de vida de los datos es tan crítica como su generación. Por eso ayudamos a las empresas a diseñar arquitecturas de datos que incluyan desde el inicio mecanismos de retirada y gobernanza. Nuestros servicios de software a medida permiten construir soluciones que no solo resuelven problemas actuales, sino que evitan la acumulación futura. Además, la integración con plataformas cloud como AWS o Azure facilita la automatización de la retirada de recursos no utilizados, reduciendo costes de infraestructura. La inteligencia artificial y los agentes de IA pueden incluso monitorizar patrones de uso y sugerir candidatos a retirar antes de que el humano los detecte.
El cambio cultural no es inmediato, pero comienza con una decisión valiente: antes de aprobar el próximo roadmap, dedique un espacio a identificar un solo activo que deba ser retirado. Sométalo al mismo escrutinio que una nueva funcionalidad. Observe lo extraño que resulta al principio y lo rápido que se normaliza. Esa pequeña acción es el germen de un equipo de datos más eficiente, más enfocado y, sobre todo, más valioso para el negocio.
