Errores comunes del Data Analyst: 7 trampas que frenan su carrera (y cómo corregirlas)

Su Slack está activo. Su Looker tiene 47 paneles de control con su nombre. Su manager le dice que es "sólido" en las reuniones individuales. Y de alguna manera, cuando el VP de Sales decide reestructurar los territorios el próximo trimestre, nadie lo invita a la reunión donde se toma la decisión.

Bienvenido a la paradoja del analista de 14 meses. Es lo suficientemente competente como para estar desbordado de trabajo, y no lo suficientemente senior como para rechazar nada. El trabajo que llenó su calendario lo llevó al IC2. Ninguno de ese trabajo lo llevará a Senior.

He revisado ciclos de evaluación de desempeño de analistas en empresas de 80 a 8.000 personas. Los que se estancan casi siempre lo hacen por las mismas razones. No es la habilidad. SQL puede aprenderlo. dbt puede aprenderlo. Python puede aprenderlo en un fin de semana si realmente abre el portátil. Las trampas de este artículo son hábitos, y los hábitos son más difíciles de desaprender que los conceptos de aprender.

Aquí están los siete que causan más daño. Cada uno viene con un síntoma que reconocerá de esta semana, un número real con el que compararse y una corrección que puede empezar a aplicar el lunes por la mañana.

Por qué la ventana de los 6 a 18 meses determina su trayectoria

En las evaluaciones de desempeño de analistas que he visto, aproximadamente el 73% de las personas que se estancan en el IC2 lo hacen por patrones formados entre los meses 6 y 18. Esa es la ventana después de que termina el proceso de incorporación pero antes de haber ganado el capital político para definir su propio alcance. Los primeros seis meses los dedica a demostrar que puede entregar resultados. Los meses 6-18 los dedica a decidir qué tipo de analista va a ser el resto de su carrera.

La mayoría de las personas no decide. Deriva. La deriva se parece a decir sí a cada ping de Slack, a construir paneles de control que nadie abre y a medir el éxito en tickets cerrados. A los dos años, el rol se calcifica. Para el mes 24, las personas de su equipo que establecieron límites están recibiendo ofertas de Senior. Usted recibe "lo revisamos en el próximo ciclo".

Estas siete trampas son la deriva, con nombre.

Trampa 1: Convertirse en el servicio de asistencia

Síntoma: Más del 60% de su semana son solicitudes puntuales de menos de 30 minutos cada una. No ha tocado el análisis más profundo que planificó hace seis semanas.

Puede detectar esto en su propio calendario en cinco minutos. Abra Slack, busque los mensajes en los que envió un resultado de consulta, cuente cuántos de ellos tomaron menos de media hora en resolverse. Si ese número supera los 25 en una semana típica, usted no es un Data Analyst. Es un servicio de SQL a pedido.

La trampa es que ser el servicio de asistencia se siente como ser útil. Cada emoji de "¡gracias!" es un pequeño estímulo positivo. Cada respuesta rápida lo hace ver reactivo. Y cada minuto que pasa en esos tickets es un minuto que no está construyendo lo que lo promoverá, que es el juicio.

Corrección que ejecuta esta semana:

Establezca un SLA de gestión y publíquelo en el canal de su equipo. El mío dice:

Solicitudes puntuales: las proceso dos veces al día, a las 11 a.m. y a las 4 p.m. Para lo que realmente bloquea su trabajo, escríbame con urgente y la fecha límite. Para preguntas repetidas, aquí está el panel de autoservicio: [enlace]. Si la pregunta me toma más de 45 minutos, se convierte en un ticket y pasa por la priorización con mi manager.

Luego construya una biblioteca de consultas de autoservicio. Las 10 preguntas que responde con mayor frecuencia, expuestas como un panel de control o un Looker Explore guardado con documentación. Reducirá su volumen de solicitudes de asistencia entre un 40 y un 60% en dos semanas. Su manager lo notará. Sus partes interesadas se quejarán durante una semana y luego se detendrán.

La incomodidad de decir "esto pasa por la priorización" es el precio de ser tratado como un analista en lugar de un buscador.

Trampa 2: Saltarse la aprobación de requisitos

Síntoma: Está en la tercera ronda de revisiones de un proyecto, y la parte interesada acaba de decir "en realidad, lo que realmente quería decir era...". Rehará el modelo y lo publicará el viernes.

Esto cuesta más de lo que piensa. Un equipo de Analytics de una empresa mediana con el que trabajé auditó su tasa de retrabajo y encontró que el 31% de las horas del analista se dedicaban a proyectos que ya habían sido "publicados" una vez. Tres de cada diez horas, rehaciendo trabajo porque la especificación era un hilo de Slack.

Se saltó la aprobación de requisitos porque pedirla se sentía lento. Pedir a la parte interesada que escribiera lo que quería, firmara con su nombre y se comprometiera con los criterios de aceptación se sentía como burocracia. Así que se la saltó. Y ahora es miércoles y está reconstruyendo el funnel por tercera vez, y el VP de Marketing está "frustrado con los tiempos de respuesta de Analytics".

Corrección que ejecuta esta semana:

Una ficha de una página, para cada proyecto de más de cuatro horas de trabajo. Plantilla:

Proyecto: [nombre]
Solicitante: [nombre + rol]
Decisión que impulsa este análisis: [la decisión real]
Responsable de la decisión: [quién actúa sobre ella]
Fecha límite de la decisión: [fecha]
Criterios de aceptación: [lista de 3-5 resultados específicos que deben existir para considerar esto "terminado"]
Fuera del alcance: [lo que NO vamos a hacer]
Aprobación de la parte interesada: [nombre + fecha]

Envíela por correo electrónico. Espere el "aprobado". Luego escriba el SQL. Si la parte interesada no firma, el proyecto no es real y no necesita empezar.

Sí, esto ralentiza las primeras 24 horas de un proyecto. Elimina las siguientes 24 horas de retrabajo. La matemática no es sutil.

Trampa 3: Construir paneles de control antes de definir la decisión

Síntoma: Su último panel de control tiene 14 bloques, tres filtros y un selector de rango de fechas. Cuando se le pregunta qué acción desencadena, el ambiente se vuelve tenso.

Este es el mal hábito más común que veo, y es el que los analistas defienden con más fuerza. El instinto es "más es más". Darle al usuario todos los cortes, todos los desgloses, todas las dimensiones, y dejar que filtre. El resultado es un panel de control que nadie puede usar porque no hay ninguna pregunta que responda.

Un benchmark interno de 2024 de una empresa SaaS de 400 personas: de los 287 paneles de control en su instancia de Looker, 41 tenían más de 10 visitantes por semana. Los otros 246 eran pueblos fantasma. Los 41 que funcionaban respondían exactamente una pregunta y desencadenaban una acción. Los 246 que no funcionaban eran paneles de "resumen general", "resumen ejecutivo", "salud del equipo": sustantivos vagos disfrazados de entregables.

Corrección que ejecuta esta semana:

Antes de cualquier nuevo panel de control, responda cuatro preguntas por escrito:

1. ¿Qué decisión impulsa esto?
2. ¿Quién toma esa decisión?
3. ¿Con qué cadencia (diaria, semanal, trimestral)?
4. ¿Qué acción se toma cuando la métrica cruza un umbral?

Si no puede responder las cuatro, no está construyendo un panel de control. Está construyendo papel tapiz. Devuelva el proyecto al solicitante hasta que pueda responderlas junto con usted.

Los paneles de control construidos de esta manera tienen entre 3 y 7 bloques, un rango de fechas y una advertencia clara de "si este número cae por debajo de X, haga Y". Se usan porque responden algo específico.

Trampa 4: Depender excesivamente de las exportaciones de Excel

Síntoma: Cada "número final" que citan sus partes interesadas vive en un CSV en el escritorio de alguien, modificado por última vez hace tres semanas.

El botón de exportar es el enemigo de una analítica de confianza. Cada exportación es una bifurcación en sus datos. En el momento en que un número sale del almacén y aterriza en Q3_pipeline_v4_FINAL_real.xlsx, usted ha perdido el control sobre él. Seis semanas después, el CFO citará ese archivo en un deck del directorio y estará desactualizado, y ese número incorrecto le será atribuido a usted.

He visto a equipos de finanzas citar una cobertura de pipeline del 19% a partir de un CSV cuando el número en vivo del almacén era del 14%. El CSV era de antes de que un acuerdo fuera reclasificado como commit. El CFO presentó el 19% al directorio. Dos meses después, el directorio preguntó por qué habíamos fallado tanto. La respuesta fue "la hoja de cálculo estaba desactualizada", que no es una respuesta que sobreviva a una reunión del directorio.

Corrección que ejecuta esta semana:

Construya una capa semántica gobernada. Modelos de dbt, métricas definidas, expuestas a través de Looker, Sigma, Hex o lo que use su stack. Acceso de solo lectura para las partes interesadas. Luego, en el canal de su equipo, haga este anuncio:

A partir de [fecha], la fuente de verdad para [pipeline, ingresos, retención, la métrica que importa] es [enlace al panel de control]. Los CSV de más de 24 horas no se reconciliarán. Si necesita un número para un deck, enlace el panel de control.

Algunas partes interesadas se resistirán. Está bien. El CFO que se resiste es el mismo CFO que le dará las gracias la primera vez que el almacén detecte un número que la hoja de cálculo habría pasado por alto.

Elimine el hábito de exportar. La reputación que salva es la suya.

Trampa 5: Sin control de versiones en SQL ni en dbt

Síntoma: Su consulta de atribución en producción vive en un hilo de Slack de marzo. O peor, vive en un bloque de Looker y tres personas lo han editado sin que usted lo supiera.

Esta trampa se siente demasiado vergonzosa para admitirla, pero he auditado equipos de Analytics en empresas en etapa Serie C donde el cálculo del valor de vida del cliente era una consulta de 400 líneas pegada en una tabla derivada de Looker sin comentarios ni historial de quién cambió qué y cuándo. El analista que la escribió se fue en 2024. Nadie puede cambiar nada con confianza.

Cree que el control de versiones es para los ingenieros. No lo es. Es para cualquiera cuyo trabajo otras personas dependen, que es usted. Un analista sin control de versiones está a una mala fusión o a un borrado accidental de un incidente de día completo.

Corrección que ejecuta esta semana:

Incluso si es un analista en solitario, configure:

1. Un repositorio git para su SQL, llamado analytics-sql o similar.
2. dbt para cualquier modelo que use más de una persona o un panel de control.
3. Revisión de PR. Si trabaja solo, revísese usted mismo a la mañana siguiente. Relea el diff con la mente despejada antes de fusionar.
4. Comprobaciones de CI (dbt test, incluso tres básicas: no nulo, único, valores aceptados).

El primer mes se siente lento. En el mes dos detectará un error en la revisión que habría reducido en un 8% el cálculo del bono de un líder de ventas. A partir de entonces, nunca volverá atrás.

El analista senior de su empresa tiene todo esto. El IC2 que nunca se promueve no tiene nada de esto. Esa es la mayor parte de la brecha.

Trampa 6: Ignorar las revisiones de retirada

Síntoma: Mantiene más de 200 paneles de control. No puede decirme cuáles 12 están realmente en uso activo. Tampoco puede decirme cuáles eliminar, así que los mantiene todos, y cada cambio en dbt se propaga a través de 200 bloques downstream.

Una auditoría sencilla en la mayoría de los equipos de BI: paneles de control con 3 o menos visitantes únicos en los últimos 30 días. En una empresa mediana típica, eso es entre el 60 y el 75% del inventario. El costo no es solo almacenamiento, es fricción. Cada refactorización, cada cambio de definición de métrica, cada cambio de nombre de columna debe probarse en regresión contra paneles de control que nadie abre.

No realiza la auditoría porque eliminar parece político. Alguien creó cada uno de esos paneles de control. Alguien podría aún quererlo. Así que los mantiene, y los restos se acumulan, y sus compilaciones de dbt se vuelven más lentas, y su tiempo para publicar una nueva métrica pasa de dos días a dos semanas.

Corrección que ejecuta esta semana:

Revisión trimestral de retirada. Invitación en el calendario, 90 minutos, cada trimestre, recurrente para siempre:

1. Extraiga estadísticas de uso: paneles de control con menos de 3 visitantes únicos por mes durante el último trimestre.
2. Notifique a los propietarios (o @channel si no hay propietario): "Este panel de control está en la lista de retirada. Si aún lo necesita, responda antes de [fecha]. De lo contrario, se archiva."
3. Archive (no elimine; mueva a una carpeta separada durante 90 días, luego elimine).
4. Registre el recuento. Apunte a retirar entre el 20 y el 30% del inventario en su primera auditoría. Menos que eso y no fue lo suficientemente agresivo.

Las partes interesadas serán más ruidosas de lo que espera en la primera ronda y más tranquilas en cada ronda posterior. Para la tercera ronda, el equipo está en buena forma y sus compilaciones de dbt terminan antes del almuerzo.

Trampa 7: Medir el uso sin el impacto en las decisiones

Síntoma: Su documento de evaluación de desempeño dice "vistas del panel de control: 1.200 por mes" y "tickets cerrados: 47 por mes". No dice nada sobre qué cambió en el negocio gracias a usted.

Este es el asesino de carrera más silencioso de los siete, porque no se siente mal mientras lo hace. Las visitas a la página suben, los tickets se cierran, parece productivo. Y luego llega el ciclo de promoción y el analista senior del pod de al lado se promueve con la mitad de sus tickets, porque su autoevaluación decía:

"Construí el modelo de retención por cohorte que reorientó el movimiento de renovación del equipo de customer success. Causó $1,4 M en ARR ahorrado en el Q3 al identificar cuentas en riesgo 60 días antes que el modelo anterior."

Esa oración supera a "vistas del panel de control: 1.200 al mes" en cada ciclo. No es ni cercano.

La trampa es que las métricas de actividad son fáciles de contar y el impacto en las decisiones es difícil. Así que cuenta lo que es fácil, y el analista senior cuenta lo que importa. Adivine quién obtiene el título.

Corrección que ejecuta esta semana:

Empiece un "registro de decisiones". Una fila por análisis, columnas:

La mayoría de las semanas añadirá entre 0 y 2 filas. Ese es el punto. El umbral es "la decisión cambió gracias a este análisis", no "envié un número". Si no puede completar la columna 4, el trabajo no movió nada, y eso también es una señal útil. Quizás el proyecto era el proyecto equivocado.

En el momento de la promoción, su autoevaluación se escribe sola. Y la conversación con su manager pasa de "¿está al día con los tickets?" a "¿cuál es la próxima decisión que vale la pena tomar?".

El costo acumulado de arrastrar estas trampas hasta el año dos

Elija una de estas y la sentirá como un punto de fricción pero se recuperará. Lleve tres o más al año dos y la trayectoria se endurece. La reputación se forma. Se convierte en "la persona de los paneles de control" o "la persona del SQL" en lugar de "el analista que nos impulsó a eliminar el paso equivocado de la incorporación".

Esa reputación es lo que realmente es difícil de deshacer. Los retrasos en la promoción de entre 9 y 15 meses son comunes. Los roles senior van a colegas que publicaron menos código pero tomaron más decisiones. Y el peor resultado no es que no se promueva, es que empiece a creer que la versión del servicio de asistencia del rol ES el rol, y deje de aspirar a algo más.

La buena noticia es que la corrección tarda un trimestre, no un año. La mayoría de los analistas que corrigen estos patrones notan un cambio perceptible en cómo son tratados en 6-8 semanas. Las partes interesadas empiezan a preguntar "¿qué deberíamos hacer?" en lugar de "¿puede extraer este número?". Ese es el juego completo.

La reiniciación de los 30 días

No intente corregir los siete a la vez. No corregirá ninguno.

Elija los dos que más le afecten. Sea honesto. El que menos quiera admitir es probablemente por el que empezar. La mayoría de los analistas que asesoro eligen "convertirse en el servicio de asistencia" y "medir el uso sin el impacto en las decisiones". Tienden a agravarse mutuamente.

Luego:

• Semana 1: Elija la trampa número 1. Escriba la corrección como un plan de una página. Dígale a su manager que la está ejecutando.
• Semanas 2-3: Ejecute la corrección. Registre qué cambia: las horas que recupera, el rechazo de las partes interesadas, la calidad de su trabajo.
• Semana 4: Añada la trampa número 2. El mismo Playbook.

Para el día 30 tendrá dos nuevos hábitos. Para el día 90, se sentirán automáticos. Para el día 180, mirará atrás al analista que era y no lo reconocerá.

Ese es el trabajo. No aprender una nueva herramienta. No volverse más inteligente. Solo negarse a derivar.

Lista de autoevaluación

Revísela el lunes por la mañana. Solo respuestas honestas:

• Menos del 40% de mi semana son solicitudes puntuales de menos de 30 minutos
• Cada proyecto de más de 4 horas tiene una ficha escrita y firmada antes de escribir el SQL
• Cada panel de control que poseo puede nombrar la decisión que impulsa, el responsable de la decisión y la cadencia
• Mis partes interesadas citan paneles de control en vivo, no CSV, en sus reuniones
• Cada SQL o modelo de dbt que poseo está en git con un historial de PR
• Realizo una auditoría trimestral de retirada y archivo al menos el 20% del inventario no utilizado
• Mi autoevaluación tiene al menos 5 entradas en un registro de decisiones con impacto nombrado

Puntúese sobre 7. Cualquier cosa por debajo de 4 indica deriva. Entre 4 y 5, es promedio. 6-7 significa que opera como un analista senior y probablemente debería cobrar como uno, que es una conversación diferente para otra semana.

Más información

• Plantilla de descripción de puesto: Data Analyst
• Trayectoria profesional del Data Analyst: de IC1 a Staff
• Gestión de partes interesadas: de solicitudes vagas a análisis publicables
• Diseño de paneles de control que impulsan decisiones