Un día en la vida de un Data Analyst

La descripción del puesto decía «impulsar hallazgos para informar decisiones de negocio». Entonces su primer mensaje de Slack a las 8:47 es «oye, pregunta rápida, ¿por qué el MRR difiere $3K del informe del consejo de la semana pasada?» y usted pasa los siguientes noventa minutos demostrando que el informe era correcto.

Esa brecha entre la descripción del puesto y el día a día explica por qué la rotación de analistas en empresas SaaS ronda el 22-28% anual. Nadie le advirtió que el rol es mitad SQL, mitad traducción y una cuarta parte defender cifras que usted mismo escribió hace tres meses. (Sí, eso suma 125%. Las matemáticas son parte del problema.)

Esto es lo que parece un martes real para un Data Analyst IC en una empresa B2B SaaS o de mercado medio, con uno a cuatro años de experiencia. No la versión de LinkedIn. La verdadera.

Por qué esto importa ahora

El volumen de solicitudes puntuales se ha duplicado aproximadamente desde que las herramientas de BI de autoservicio se generalizaron. Cada Product Manager cree que necesita un corte de cohorte personalizado para el martes. Cada VP tiene una intuición que quiere validar para el viernes. Las herramientas prometieron datos democratizados y entregaron una avalancha de solicitudes.

Los candidatos que eligen este trabajo pensando que es un puesto tranquilo donde construyen modelos todo el día renuncian antes de los dieciocho meses. Los que permanecen aprenden a hacer algo que la descripción del puesto nunca menciona: proteger su tiempo de pensamiento mientras siguen pareciendo responsivos. Esa es la habilidad senior real.

Si usted está contratando, conocer esto cambia cómo evalúa candidatos. Si trabaja como analista, nombrar los patrones los hace manejables. Recorramos el día.

8:00am: Revisión de paneles de control

Antes de abrir Slack, antes de que el primer parte interesada esté despierto, revise los seis a ocho paneles de control que sus ejecutivos realmente abren. No los veinte que usted ha construido. Los que se visitan de verdad.

Usted busca tres cosas:

• Valores nulos donde no debería haberlos. Un número de ingresos en blanco para ayer. Un conteo de registros que dice cero un miércoles.
• Combinaciones de tablas rotas tras la ejecución de dbt de la noche anterior. Un modelo falló en silencio y el panel de control muestra datos desactualizados con una marca de tiempo reciente. Este es el peor tipo de error porque nadie lo nota hasta que toma una decisión basada en él.
• Picos extraños. ¿El tráfico es cuatro veces el normal? O marketing lanzó algo sin avisarle, o un evento de seguimiento se está disparando dos veces. Ambos justifican un mensaje de Slack antes de que alguien más pregunte.

Todo el recorrido toma quince minutos si todo está limpio. Cuarenta y cinco si no lo está. El objetivo es encontrar el error antes de que el CFO abra el panel de control a las 9:15am y le envíe «¿esto está bien?»

Una revisión matutina limpia es trabajo invisible. Nunca recibirá reconocimiento por ella. Pero el día que la omita es el día en que un miembro del consejo ve cifras incorrectas, y ese día es mucho más ruidoso que las cien mañanas tranquilas anteriores.

9:30am: Triaje de solicitudes puntuales

La cola de Jira tiene once tickets nuevos. Slack tiene seis mensajes directos. Un VP le envió un mensaje a su teléfono personal, algo que usted lamenta haberle dado en la fiesta de Navidad.

El triaje es clasificar, no resolver. Cada solicitud va a uno de cuatro grupos:

• Tarea de 10 minutos. Alguien quiere un conteo, una lista, un filtro rápido. Hágalas en el momento, publique la respuesta en el hilo y continúe.
• Análisis de 2 días. Preguntas reales que necesitan un modelo, una cohorte o un informe escrito. Prográmelas.
• Duplicada. Alguien pregunta lo que otra persona preguntó el mes pasado. Encuentre la respuesta anterior, vincúlela, cierre el ticket. Con cortesía.
• Poco clara. La solicitud no dice qué decisión respalda. Estas necesitan una respuesta de cinco minutos preguntando lo que le ahorrará cuatro horas.

Esa pregunta es: «¿Qué decisión cambiará esto?»

Formulada con tacto es: «Con gusto profundizo. Antes de empezar: ¿qué planea hacer de forma diferente según lo que digan los datos?» Si la respuesta es «nada, solo tenía curiosidad», puede despriorizar con honestidad. Si la respuesta es «estamos decidiendo si eliminamos el flujo de prueba el viernes», lo escala. De cualquier modo, usted ha hecho su trabajo antes de escribir una sola consulta SQL.

Una plantilla de admisión funcional (péguela en Jira/Linear o donde corresponda):

**Decisión que este análisis informará:**
**Fecha en que lo necesita:**
**Quién más revisará el resultado:**
**Qué ya revisó:**
**Nivel de precisión aceptable (estimación aproximada o auditoría detallada):**

La mitad de las solicitudes se detienen en el primer campo porque quien las hace se da cuenta de que aún no tiene una decisión. Eso es una ventaja, no un problema.

11:00am: Entrevista de requisitos a mediodía

Treinta minutos en Zoom con un Product Manager que dijo «necesito datos de abandono de clientes».

La solicitud real siempre está tres niveles más abajo. Su trabajo es ir de lo vago a lo específico sin hacer que la persona se sienta torpe. El truco es hacer preguntas diagnósticas, no interrogativas.

Un flujo funcional:

1. Reformule y amplíe. «Entonces quiere entender el abandono de clientes. Para asegurarme de hacer el corte correcto: ¿hablamos de abandono por cliente, abandono por ingresos o abandono por logo? Se comportan de forma diferente.»
2. Pregunte por la decisión. «¿Qué va a hacer una vez que tenga esto? ¿Está dimensionando la plantilla de un equipo de retención o intentando encontrar qué segmento priorizar?»
3. Defina la cohorte. «Cuando dice "clientes que abandonaron", ¿se refiere a los que cancelaron en los últimos 30 días, o a los que cancelaron y no reactivaron? ¿Y cuenta el downgrade?»
4. Fije un objetivo de precisión. «¿Necesita esto de forma orientativa hoy EOD, o con calidad de auditoría para el QBR? La respuesta cambia mi tiempo en aproximadamente un día.»

La mayoría de los Product Managers no quieren parecer inseguros frente a la dirección, así que piden cosas en el lenguaje del informe que tienen que presentar. Su trabajo es traducir eso a una pregunta que SQL pueda responder. No los está socavando al preguntar. Los está protegiendo de presentar un gráfico que no dice lo que ellos creen que dice.

La regla de Camellia: nunca deje que una parte interesada abandone una llamada de requisitos sin que ambos digan en voz alta cuál es el entregable, cuál es la cohorte y qué decisión respalda. Si no puede resumir eso en un mensaje de Slack después de la reunión, aún no tiene una especificación.

1:30pm: Comunicación asíncrona con Ingeniería y Producto

La ventana entre el almuerzo y las 4pm es cuando usted hace el trabajo que nadie le pide pero que determina si el próximo trimestre será manejable.

Este es el bloque asíncrono. Tres tipos de insumos:

Revisiones de pull request de dbt. Un ingeniero de datos cambió cómo el modelo fct_subscriptions maneja las conversiones de prueba. Usted lee el diff. Un comentario de muestra que resulta útil:

Este cambio parece correcto para nuevas pruebas, pero creo que
contará dos veces cualquier cuenta que convierta, haga downgrade
y reconvierta en el mismo trimestre. Tenemos ~40 de esos por
trimestre (lo verifiqué en #data-quality el mes pasado). ¿Podemos
agregar un test de unicidad de `subscription_id` en el modelo de
staging antes de fusionar? Con gusto lo escribo.

Específico. Hace referencia a datos reales. Se ofrece a ayudar. No bloquea el pull request por razones vagas.

Comentarios en especificaciones de producto. Un Product Manager dejó una especificación para un nuevo flujo de Onboarding. La sección de seguimiento de eventos dice «disparar onboarding_completed cuando el usuario termine». Usted deja un comentario: ¿qué paso cuenta como «terminar»? ¿Qué pasa si omite el paso tres? ¿Debemos disparar onboarding_completed para cada variante del flujo o tener eventos separados? Mejor preguntar ahora que analizar datos incorrectos en seis semanas.

Alertas de cambios de esquema. Ingeniería va a renombrar una columna en producción el viernes. Usted busca ese nombre de columna en cada exploración de Looker, cada notebook de Hex y cada modelo de dbt. Cuatro paneles de control se romperán. Envía un mensaje al líder de ingeniería con la lista y coordina el cambio. Esta tarea de veinte minutos es la diferencia entre un sábado tranquilo y un sábado reconstruyendo paneles de control ejecutivos mientras su hijo ve televisión.

Aquí es donde los analistas senior ganan su título. El IC escribe el SQL. El senior detecta la ruptura tres semanas antes de que ocurra.

4:00pm: Extracción de datos para ejecutivos al final del día

El CFO necesita tres cifras para la preparación del consejo de mañana. Le envió un mensaje a las 3:47pm. La reunión del consejo es a las 8am.

Este es el momento en que SQL se encuentra con las apuestas reales. Usted consulta Snowflake (o BigQuery, o Postgres, según lo que use su empresa) y verifica cada cifra contra los números reportados el trimestre pasado. Si la nueva extracción no concuerda con el número anterior, no envía nada hasta entender por qué.

El entregable no son tres cifras. Son tres cifras más contexto. Un formato funcional para la nota en Notion o Confluence:

**Extracción rápida Q1 2026 para preparación del consejo**

1. ARR neto nuevo: $1.42M
   (vs. $1.38M reportado en el informe Q4, +3%, en línea)
   Advertencia: incluye 2 contratos con fecha de cierre 31/3 pero
   registrados el 2/4; excluidos de la vista estricta Q1 más abajo.

2. Tasa de abandono por logo: 4.1% (anualizada)
   Vista estricta Q1: $1.40M, 4.4%
   Extraído a las 4:35pm del 28/4; actualizaré si lo necesita antes de las 8am.

3. Conversión de prueba a pago: 18.7%
   (vs. 17.2% en Q4, impulsado por la cohorte del test de precios de febrero,
   que es un incremento temporal, no un cambio estructural. No
   proyecte esto en línea recta.)

Modelos fuente: fct_subscriptions, fct_trials, dim_accounts.
Escríbame si algo aquí no coincide con lo que usted ve.

Cuatro puntos, cuatro líneas de advertencias. El CFO puede presentar esto sin volver a preguntar. Y cuando alguien en la reunión del consejo diga «espera, eso no coincide con lo que dijiste en febrero», el CFO ya tiene la respuesta preparada.

Este es el trabajo que lo hace avanzar. No el SQL. Las cuatro líneas de contexto debajo de él.

Las dos crisis recurrentes

Dos patrones consumirán su semana si los deja. Nombrarlos ayuda.

Crisis uno: La explosión de solicitudes puntuales

Dijo que sí a una solicitud rápida el lunes. Quien la hizo le contó a un colega que usted fue útil. Para el miércoles, cuatro personas están en sus mensajes directos. Para el viernes, tiene dieciocho tickets y no tiene tiempo para el proyecto estratégico en el que su manager realmente lo evalúa.

Este es el ciclo de solicitudes duplicadas. Se agrava porque decir sí es más rápido en el momento que establecer un proceso, y porque cada «pregunta rápida» no parece una solicitud. Parece una conversación.

El patrón que realmente funciona:

• Horario de atención, dos veces por semana. Un bloque de 60 minutos donde cualquiera puede aparecer con una pregunta. La mayoría de los «necesito un número rápido» caben en este formato y no necesitan un ticket de Jira.
• Formulario de admisión para todo lo demás. Vinculado en su perfil de Slack y en el tema del canal. Si alguien le escribe directamente, su respuesta es «buena pregunta, ingrésela en el formulario para que pueda priorizarla frente a los otros doce que tengo, aquí está el enlace».
• Un resumen semanal de lo que cerró. Publicado en #data el viernes. Tres líneas por ticket cerrado: quién preguntó, qué quería, cuál fue la respuesta. Construye un historial de búsqueda, reduce solicitudes duplicadas y muestra a su equipo lo que usted realmente entregó.

No está siendo obstructivo. Está protegiendo las diez horas de trabajo enfocado por semana donde construye las cosas que importan.

Crisis dos: El pánico por definiciones incompatibles

Mensaje de un Director a las 5:55pm de un jueves: «Este informe está mal. Los usuarios activos cayeron un 30% semana a semana y eso no es lo que está viendo marketing».

El noventa por ciento de las veces el informe es correcto y el Director está comparando dos definiciones diferentes. Marketing cuenta como «activo» a quien visitó el sitio. El panel de control de producto cuenta como «activo» a quien completó una acción significativa. Ambas son correctas. Nunca van a coincidir.

El guión de triaje:

1. Reconozca la urgencia sin contagiarse del pánico. «Revisando ahora, le tengo respuesta en diez minutos con lo que encuentre.»
2. Busque la definición primero, el número después. ¿Qué campo usa la fuente del Director? ¿Qué campo usa el panel de control? Si son diferentes, ya resolvió el problema.
3. Ofrezca una comparación lado a lado. No diga simplemente «están usando métricas diferentes». Muestre los dos números uno al lado del otro con las definiciones debajo. «Fuente de marketing: activos por visita de página, 142K. Panel de control: activos por acción, 98K. La caída del 30% es real si se refiere a activos por acción; es una caída del 4% si se refiere a activos por visita de página.»
4. Documente la discrepancia. Agregue una nota en su diccionario de datos o documento de definiciones. Vincúlelo en su respuesta. La próxima vez que esto ocurra, responde con el enlace.

El Director no está equivocado. Trabaja con una definición diferente. Su trabajo es identificar la brecha de definición con suficiente rapidez para que nadie tenga que rehacer un informe.

Verificación de realidad sobre las herramientas

Las herramientas que realmente utilizará:

• SQL. Snowflake, BigQuery o Postgres. Use el que tiene su empresa. Aprenda uno bien; los demás se traducen. Las funciones de ventana, los CTE y QUALIFY (Snowflake/BQ) cubren el 90% del trabajo.
• Una herramienta BI. Looker, Tableau, Hex o Mode. Cada una tiene una filosofía diferente: Looker se inclina por la capa semántica, Tableau es visual de arrastrar y soltar, Hex y Mode se inclinan por el estilo de notebook con SQL y Python. Se especializará en la que eligió su empresa. No intente ser experto en Looker y en Tableau al mismo tiempo; la sintaxis de LookML y los cálculos de Tableau no se transfieren limpiamente.
• dbt para modelado de datos. Lee YAML y escribe SQL. Si su empresa tiene un equipo de ingeniería de datos, usted revisará sus pull requests más de lo que escribirá sus propios modelos, pero necesita leer dbt con fluidez para entender qué hay upstream de cada panel de control.
• Notion o Confluence. Para documentación, registros de decisiones y las notas de advertencia de cuatro líneas. La herramienta no importa; la disciplina de escribir las cosas sí.
• Jira (o Linear, o Shortcut). Para la cola de solicitudes. Cualquiera que use su empresa para tickets de ingeniería, canalice también el trabajo de datos a través de él. Si los datos viven en un sistema separado, se ignoran.

Si una descripción de puesto lista las cinco como requisito y espera nivel experto en cada una, eso es una señal de alerta. Nadie es experto en las cinco. La versión honesta es: profundo en una herramienta BI, fluido en SQL, cómodo leyendo dbt, organizado en Notion, responsivo en Jira. Eso es todo.

Lo que la descripción del puesto no le dice

Aproximadamente el cincuenta por ciento de su semana es comunicación y traducción, no análisis. Llamadas de requisitos, hilos de Slack, debates sobre definiciones, revisiones de pull requests asíncronas, notas de advertencia al final del día. El SQL es la punta del iceberg.

Su habilidad más usada es preguntar «¿qué decisión intenta tomar?». La segunda más usada es decir que no sin parecer obstructivo. La tercera es documentar decisiones para que el próximo analista no las vuelva a debatir.

Los analistas IC que se agotan son los que creen que el SQL es el trabajo. Los que avanzan son los que se dan cuenta de que el SQL es el veinte por ciento del valor, y el otro ochenta es todo lo que lo rodea: el triaje, la traducción, las advertencias, la documentación de definiciones, el resumen del viernes.

Si eso suena como el trabajo que usted quiere, le irá bien. Si suena como un engaño, también es válido, y es mejor saberlo ahora que tres años después.

Más recursos

• Plantilla de descripción de puesto: Data Analyst
• Cómo triar solicitudes de datos puntuales
• Cómo dirigir una entrevista de requisitos con partes interesadas
• Defendiendo sus cifras cuando un Director dice «esto está mal»