Preguntas de entrevista Gestor de datos

Empiezo con un alcance reducido y de alto valor en lugar de intentar gobernarlo todo a la vez. Identifico los tres o cuatro conjuntos de datos que más pesan en las decisiones importantes, normalmente datos de clientes, ingresos y uso del producto, y construyo la gobernanza alrededor de ellos primero: propiedad clara, una definición acordada para cada métrica clave, y un diccionario de datos que se mantiene actualizado en lugar de escribirse una vez y olvidarse. Organizo un grupo de trabajo breve con los propietarios de negocio de cada conjunto de datos para que las normas reflejen cómo se usan los datos en la práctica, no solo lo que parece ordenado sobre el papel. Evito deliberadamente un documento de política pesado que nadie lee. Prefiero incorporar las normas en las herramientas que la gente ya usa, como convenciones de nomenclatura aplicadas en el almacén de datos y controles de validación en el pipeline de ingesta. Trato el marco como algo vivo: lo reviso cada trimestre y retiro las normas que resultaron no importar.

Primero confirmo el alcance del error antes de decir nada: qué cifras están mal, cuánto, y qué decisiones pudieron basarse en ellas. He comprobado que una alerta rápida pero imprecisa causa más daño que una alerta ligeramente más lenta pero exacta. Una vez tengo los hechos claros, aviso directamente a quien es responsable del informe y a los destinatarios de dirección, con las cifras corregidas y una explicación clara de la causa raíz, no solo una disculpa. En un caso, un panel de churn contaba dos veces las cuentas reactivadas, inflando la tasa de retención en unos 6 puntos porcentuales durante dos trimestres. Rastreé el problema hasta una condición de join que no tenía en cuenta cuentas que se habían dado de baja y vuelto a activar en el mismo periodo, corregí la consulta, añadí un control de conciliación contra el sistema de facturación, e informé a la dirección tanto de la corrección como de la solución para que supieran que no se repetiría en silencio.

Empiezo por establecer qué sistema es la fuente autorizada para cada campo, porque intentar que todos los sistemas tengan la misma autoridad es precisamente lo que genera duplicados. Para la identidad del cliente, suelo designar el CRM como referencia para los datos de contacto y relación, y el sistema contable como referencia para los datos de facturación y entidad legal, y luego construyo una clave de coincidencia, a menudo una combinación del número de registro de la empresa y el nombre normalizado, para vincular los registros entre ambos sistemas. Ejecuto una deduplicación de forma programada, no solo una vez, porque se crean nuevos duplicados cada vez que alguien introduce manualmente un cliente sin comprobar antes. Para los casos que la coincidencia automática no puede resolver con confianza, los envío a una revisión humana con los dos registros candidatos uno al lado del otro en lugar de fusionarlos automáticamente, porque una fusión automática errónea es más difícil de deshacer que una coincidencia no detectada.

Sigo un pequeño conjunto de indicadores prácticos en lugar de una única puntuación de madurez, porque una puntuación única tiende a ocultar dónde están los problemas reales. Reviso los incidentes de calidad de datos al mes y si esa tendencia baja, el porcentaje de conjuntos de datos críticos con un propietario nombrado y una definición actualizada, cuánto se tarda en responder a una nueva solicitud de datos, porque una respuesta lenta suele significar que la gente no confía lo suficiente en los datos existentes como para autoservirse, y con qué frecuencia se repite la misma pregunta porque la respuesta no quedó documentada en ningún sitio fácil de encontrar. También presto atención a una señal más sutil: si en las reuniones la gente cita directamente las cifras del panel o las recalcula discretamente en una hoja de cálculo antes, porque ese hábito es la señal más clara de que la confianza en los datos todavía no se ha ganado.

Un responsable de operaciones comerciales quería cargar directamente una lista de contactos comprada en el CRM antes del lanzamiento de una campaña, saltándose el paso habitual de validación y deduplicación para cumplir un plazo fijado para el viernes. No me limité a decir que no. Expliqué el riesgo concreto: la lista no tenía ninguna verificación contra nuestra lista de supresión existente, así que corríamos el riesgo de contactar a personas que ya se habían dado de baja, lo cual es un problema real de cumplimiento normativo, no solo de orden. Propuse una versión reducida del proceso de validación, unas cuatro horas en lugar de los dos días habituales, ejecutando solo los controles ligados a un riesgo legal real y aplazando la limpieza cosmética. La campaña se lanzó con aproximadamente medio día de retraso respecto al plan inicial. Después, el responsable me pidió que convirtiera ese proceso reducido en una opción estándar para campañas urgentes, algo que hoy está documentado como nuestro proceso de revisión acelerada.

Gestioné un equipo de tres data stewards, cada uno responsable de un dominio de negocio distinto: clientes, producto y finanzas. Pronto noté que uno de ellos era excelente en documentación técnica pero evitaba las conversaciones con las partes interesadas necesarias para resolver disputas de propiedad de datos, lo que dejaba los problemas de su dominio sin resolver más tiempo que los de los demás. En lugar de esquivar el problema, lo emparejé con el steward más cómodo en ese tipo de conversaciones para una sesión conjunta sobre una disputa concreta, y luego dejé que él liderara la siguiente en solitario, con mi supervisión. En dos meses llevaba esas conversaciones de forma autónoma. Mantengo reuniones individuales mensuales centradas específicamente en qué está bloqueando su dominio, no en actualizaciones generales, porque ahí es donde puedo ayudar de forma más directa, y he comprobado que los bloqueos concretos y actuales se resuelven mucho más rápido que lo que se plantea en una reunión general.

Un contratista externo tenía un acceso más amplio a una base de datos de clientes del que su proyecto requería, y lo descubrimos en una revisión de accesos rutinaria, tres semanas después de haberse concedido el acceso, sin evidencia de que se hubiera usado de forma indebida. Traté el caso con el mismo rigor que un incidente real: documenté la cronología, revoqué el acceso excedente de inmediato, y trabajé con IT para confirmar, mediante registros y exportaciones, que ningún dato había salido del sistema. La causa raíz era que un solo responsable aprobaba las solicitudes de acceso sin una segunda comprobación del principio de mínimo privilegio. Introduje una validación de dos personas para cualquier acceso por encima de la simple lectura, y añadí una revisión de accesos trimestral específica para contratistas en lugar de integrarla en la revisión anual general, porque los accesos de los contratistas cambian con mucha más frecuencia que los de los empleados.

Parto de los flujos de datos concretos, no del texto normativo, porque los fallos de cumplimiento suelen ocurrir en un proceso que nadie mapeó, no en una política que nadie escribió. Mantengo un registro de actividades de tratamiento que detalla qué datos personales tenemos, por qué, dónde se almacenan y quién puede acceder a ellos, y lo actualizo cada vez que se añade un sistema o integración nueva, no solo una vez al año. Para las solicitudes de acceso o supresión, he construido una checklist que cubre cada sistema que contiene datos personales, incluidos los que se olvidan con facilidad, como las copias de seguridad y las herramientas analíticas de terceros, porque una supresión técnicamente correcta en la base principal que deja datos en una exportación antigua sigue siendo un fallo de cumplimiento. También paso una revisión de privacidad ligera antes de incorporar cualquier herramienta o proveedor nuevo, comprobando su acuerdo de tratamiento de datos y dónde almacenan los datos, en lugar de dejarlo únicamente en manos del equipo legal.

Busco tres cosas: lo fácil que resulta para usuarios no técnicos buscar y entender un conjunto de datos sin tener que preguntar a alguien del equipo de datos, lo bien que la herramienta rastrea el linaje para poder trazar una cifra de un informe hasta sus tablas de origen, y cuánto mantenimiento manual requiere, porque un catálogo que necesita etiquetado manual constante tiende a quedar obsoleto en pocos meses. He usado Collibra, y también una configuración open source más ligera construida sobre la documentación y el grafo de linaje de dbt para un equipo más pequeño que no necesitaba las funciones completas de gobernanza. Esa configuración ligera funcionó mejor para ese equipo precisamente porque la adopción dependía de que la herramienta fuera casi invisible: los ingenieros documentaban las cosas como parte de su trabajo habitual en lugar de como una tarea de gobernanza aparte, lo que mantenía la documentación actualizada de forma constante.

Enfoco ambos en términos de riesgo y coste del retraso, en lugar de tratar la gobernanza como algo inherentemente secundario frente a la infraestructura, que es la suposición por defecto en muchas organizaciones. Una caída de un pipeline que detiene un informe diario es visible y urgente, pero un vacío de gobernanza, como un conjunto de datos sin documentar que alimenta un informe regulatorio, puede costar igual de caro si aparece en una auditoría, simplemente es menos visible en el día a día. Trabajo con el responsable de data engineering para puntuar ambos tipos de trabajo en la misma escala: impacto de negocio si no se atiende, y esfuerzo necesario, y luego secuenciamos el backlog juntos en lugar de dejar que gobernanza e ingeniería gestionen dos listas competidoras por separado. Cuando ambos entran en conflicto directo por la misma capacidad de sprint, priorizo el que sería más difícil de explicar después a un regulador o a un directivo, lo que hace que la decisión sea concreta en lugar de abstracta.