¿Cómo construirías un marco de gobernanza de datos desde cero en una empresa que no tiene ninguno?

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.

Explícame cómo gestionarías un problema de calidad de datos descubierto en un informe que ya se ha enviado a la dirección.

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.

¿Cómo gestionas los datos maestros entre varios sistemas, por ejemplo registros de clientes duplicados entre un CRM y un sistema contable?

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.

¿Cómo mides la salud o madurez de las prácticas de datos de una organización?

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.

Cuéntame sobre una vez que te opusiste a un responsable de negocio que quería saltarse la gobernanza de datos para ir más rápido.

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.

Describe cómo has gestionado y desarrollado a un equipo pequeño de analistas o data stewards.

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.

Cuéntame sobre una fuga de datos o un incidente evitado por poco que hayas gestionado, y qué cambió después.

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.

¿Cómo abordas el cumplimiento del RGPD en la práctica, no solo en la política escrita?

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.

¿Qué buscas en un catálogo de datos o una herramienta de gestión de metadatos, y cómo has usado una?

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.

¿Cómo priorizas entre el trabajo de gobernanza de datos y las correcciones de infraestructura de data engineering cuando compiten por los mismos recursos?

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.

Gestor de datos

Las entrevistas de Gestor de datos evalúan algo distinto de una entrevista de Analista o Ingeniero de datos: tu capacidad para conseguir que una organización confíe en sus propios datos. Los entrevistadores quieren ver un enfoque claro de gobernanza, calidad y cumplimiento normativo, junto con el criterio para saber cuándo una norma debe aplicarse y cuándo debe revisarse. Esta guía cubre las preguntas más frecuentes y las respuestas que demuestran que puedes conectar el lado técnico y el lado de negocio de los datos.

Para consejos generales de preparación, consulta nuestra guía sobre las preguntas de entrevista más frecuentes.

Prepárate más

Dominar la entrevista conductual (método STAR)Cómo prepararse para una entrevista técnica

Preguntas de entrevista habituales para Gestor de datos

Preguntas conductuales para puestos de Gestor de datos

Preguntas técnicas para candidatos a Gestor de datos

Lo que buscan los reclutadores en las entrevistas para Gestor de datos

Lo que los responsables de selección buscan realmente en los candidatos a Gestor de datos:

Criterio sobre qué normas importan. Un marco de gobernanza que intenta controlarlo todo suele acabar sin controlar nada de forma efectiva.
Comodidad para decir que no a una parte interesada, pero siempre acompañado de una alternativa, no solo aplicar normas por aplicarlas.
Fluidez en ambos sentidos: suficientemente técnico para trabajar con data engineering, suficientemente cómodo con el negocio para explicar un problema de calidad de datos a un directivo sin jerga.
Evidencia de trabajo de cumplimiento real, no solo conocimiento de políticas. Un detalle concreto sobre solicitudes de supresión, revisiones de acceso o gestión de incidentes es la señal que lo delata.
Un historial de desarrollo de las personas de su equipo, no solo de gestión de tareas y tickets.

Preguntas que puedes hacer al entrevistador

→¿Cómo se reparte actualmente la propiedad de los datos entre el equipo de datos y las áreas de negocio que los generan?
→¿Cómo es el proceso actual de gestión de incidentes de calidad de datos, y con qué frecuencia se usa?
→¿Qué parte de la gobernanza de datos aquí es política escrita frente a lo que está integrado de forma concreta en las herramientas y los pipelines?
→¿Cómo es la relación entre el equipo de datos y el equipo de data engineering: hojas de ruta separadas, o un backlog compartido?
→¿Cómo sería el éxito en este puesto en los primeros seis meses?

Practica estas preguntas antes de tu entrevista

El simulador de entrevista prepara una sesión de práctica basada en una oferta de empleo concreta y tu perfil, para que repases las preguntas con más probabilidad de aparecer.

Empezar a practicar

Gratis para empezar. Sin compromiso.

Puestos relacionados

Oficial de cumplimiento

Finanzas10 preguntas

Disponible en otros idiomas

English Français