Sus primeros 30/60/90 días como nuevo Data Analyst

Son las 9:47 AM del día 3. Apenas ha configurado su VPN. Le llega un mensaje de Slack de alguien cuyo nombre no reconoce: «¡Bienvenido! Una cosa rápida: ¿puedes extraer el MRR por segmento para el informe del consejo de mañana? Solo necesito que esté dividido por banda de ARR y canal de adquisición. ¡Gracias!»

Cómo responda ese mensaje decide sus próximos 12 meses.

Si dice que sí y ejecuta la consulta, acaba de firmar el contrato. Ahora es la persona de consultas puntuales. Pasará 40 horas a la semana en «rápidas» y no entregará ningún trabajo estratégico. Para el día 91, cuando su manager le pregunte qué logró, tendrá un archivo de Slack en lugar de una historia.

Si dice que no, es el nuevo analista que bloqueó el informe del consejo. También es malo.

Hay un tercer camino. Esta guía es ese camino.

Por qué los analistas necesitan un marco 30/60/90 más que nadie

Los ingenieros reciben un backlog. Los Product Managers reciben un Roadmap. Los diseñadores reciben un archivo de Figma ya en movimiento. Los analistas entran a un trabajo donde cada parte interesada cree que es la prioridad, el analista anterior no dejó documentación y la pantalla de la empresa muestra paneles de control que no se han actualizado en ocho meses. La mitad están mal. Nadie sabe cuál mitad.

Sin un marco, usted se convierte en una máquina expendedora de SQL. Con uno, se convierte en alguien que eliminó 30 paneles de control rotos, entregó un modelo de ingresos canónico y entró a la reunión de planificación del segundo semestre con un Roadmap de analítica que su VP no había pedido pero de repente necesitaba.

El marco es simple: auditar, luego entregar una cosa, luego ser dueño de una métrica. Tres meses. Un trabajo por mes. No se salte etapas.

Días 1-30: Auditar, no construir

El error más grande que veo cometer a los nuevos analistas es abrir un editor SQL el día 4 e intentar «arreglar» algo. Usted no sabe todavía qué está roto. No sabe qué es estructuralmente necesario. No sabe cuál panel de control «roto» es el único en el que confía el CFO.

El primer mes es reconocimiento. Escribe casi ninguna consulta. Toma muchas notas.

Semana 1: Inventario de paneles de control

Obtenga una lista de cada panel de control, informe y consulta guardada en su herramienta BI (Looker, Mode, Tableau, Metabase, lo que haya heredado). Para cada uno, capture cinco campos:

• Nombre
• Propietario (o «desconocido»)
• Conteo de vistas (últimos 60 días)
• Fecha de última edición
• Estado (activo / sospechoso / inactivo)

Inactivo significa: cero vistas en 60 días, O última edición por alguien que dejó la empresa hace más de seis meses. En una empresa SaaS de tamaño mediano típica, encontrará que el 60-70% de los paneles de control están inactivos. En mi última empresa teníamos 312 paneles de control. Después de la auditoría, 47 se usaban realmente. El resto eran barcos fantasma.

No elimine nada todavía. Solo haga la lista.

Semana 2: Recorrido por el esquema y la discusión canónica sobre ingresos

Ahora lee. Abra el repositorio de dbt (o su almacén de datos si no hay dbt). Encuentre las cinco tablas que tocará cada semana (usualmente alguna variante de accounts, subscriptions, events, users y una tabla de ingresos). Lea las definiciones de los modelos. Lea los comentarios de columnas. Lea los macros.

Con certeza estadística, descubrirá que su empresa tiene múltiples definiciones de ingresos. En una empresa donde trabajé, teníamos 14 versiones de ingresos en el almacén de datos. ARR reservado. ARR facturado. ARR proyectado. ARR neto nuevo. ARR retenido bruto. Cada uno era correcto para algún propósito e incorrecto para otro. Finanzas usaba uno. Ventas usaba otro. El CEO tenía una hoja de Google con un tercero.

Esto es normal. También es su tarea más importante de la semana 2. Programe una reunión con su contraparte de finanzas. Pregunte: «¿Cuál de estos es la fuente de verdad para el consejo?» Obtenga una respuesta por escrito. No en un mensaje de Slack, en un documento. Esa conversación es la base sobre la que descansa todo lo demás.

Si finanzas no puede decírselo, eso es un hallazgo. Anótelo.

Semana 3: Reuniones con partes interesadas (escuche, no presente)

Participe en cinco reuniones: revenue ops, customer success, marketing, producto, finanzas. No está allí para presentar. No está allí para «presentarse». Está allí para escuchar las preguntas recurrentes.

El patrón que busca: la misma pregunta hecha por tres equipos diferentes de tres maneras diferentes. Ese es su panel de control de la semana 5.

Ejemplos de lo que he escuchado en reuniones de la semana 3:

• Líder de RevOps: «Nunca sabemos en qué segmento está realmente concentrado nuestro Pipeline».
• Director de CS: «Quisiera ver el ARR de expansión por sector sin tener que exportarlo a una hoja de cálculo».
• CMO: «El Pipeline originado por marketing por segmento está en cinco lugares diferentes».

Es la misma pregunta tres veces. Ese es el panel de control que usted construye en el mes dos.

Lleve un cuaderno. No abra su computadora. No se ofrezca a «extraer algo rápido». Cuando le pregunten, diga: «Estoy en modo de auditoría las próximas dos semanas. Agreguémoslo al formulario de admisión cuando esté disponible.» (Más sobre el formulario de admisión en un momento.)

Semana 4: La lista de eliminación

Ahora proponga dar de baja los paneles de control inactivos. Aquí es donde los nuevos analistas se asustan y se saltan este paso. No lo haga.

Vuelva a su inventario. Para cada panel de control inactivo, encuentre al creador original (o al equipo al que pertenecía) y pregunte: «Este no ha sido visto en X días. ¿Está bien que lo archive?» El 80% de las veces la respuesta es «por supuesto, lo había olvidado». El 15% de las veces la respuesta es «en realidad mantenlo, lo uso mensualmente». El 5% de las veces aprenderá algo importante sobre el negocio.

Obtenga la aprobación por escrito. Un hilo de Slack está bien. Luego archive, no elimine. La mayoría de las herramientas BI permiten archivar con restauración con un clic. Usted quiere un rastro documentado.

Este es el guión que funcionó para mí:

Hola [nombre], estoy haciendo una limpieza de paneles de control como parte del proceso de incorporación. El «[nombre del panel de control]» no ha tenido vistas en 73 días y fue editado por última vez por [persona que se fue]. Me gustaría archivarlo (reversible, no se elimina). ¿Está bien? Si prefiere conservarlo, sin problema, solo quiero confirmar que alguien lo tiene asignado.

Envíe esto en lotes de 10. No persiga respuestas. Silencio después de 5 días hábiles equivale a archivar. Documente todo.

Al final de la semana 4, normalmente habrá eliminado entre 40 y 150 paneles de control. Ese es su primer entregable. También es el único entregable que podrá reclamar que no requirió ni una línea de SQL, que es exactamente el punto.

Días 31-60: Entregar una cosa, establecer el SLA

El mes dos es donde aparece el trabajo real. Pero solo puede hacer tres cosas. Entregue un panel de control. Publique un SLA. Construya un modelo de dbt. Eso es todo. Resista el impulso de hacer más.

Entregue el panel de control que todos pidieron

¿Recuerda la pregunta de la semana 3 que tres equipos hicieron? Construya ese panel de control. Solo ese.

La disciplina aquí es implacable. La gente preguntará «ya que estás, ¿puedes también agregar...?» y la respuesta es no. No porque su solicitud sea mala, sino porque cada «ya que estás» se convierte en la trampa de la persona de consultas puntuales con pasos adicionales. Entregue una cosa. Hágala bien. Entréguela.

Un buen primer panel de control significa:

• Una pregunta, respondida claramente. No cinco preguntas.
• La definición de la métrica es la canónica por la que discutió en la semana 2, y el pie del panel de control lo indica. («Ingresos definidos según [enlace al modelo de dbt]. Última revisión con Finanzas el [fecha].»)
• Tres filtros como máximo. Segmento, rango de fechas, un corte específico del equipo.
• Un párrafo de «Cómo interpretar esto» al inicio.
• Un propietario (usted) y un canal de Slack para preguntas.

Ese último punto no es negociable. Cada panel de control sin propietario se convierte en un barco fantasma en 18 meses. Usted va a ser el analista que rompa ese patrón.

Publique el SLA de solicitudes puntuales

Este es el momento en que deja de ser una máquina expendedora de SQL. Publica una página única (un documento de Notion, una página de Confluence, lo que use su empresa) que diga:

Admisión de solicitudes de datos puntuales

1. Envíe a través de [formulario / canal #data-requests]. Los mensajes directos a mí serán redirigidos aquí.
2. Tres campos requeridos: qué necesita, cuándo lo necesita, qué decisión informa.
3. SLA: solicitudes de menos de 4 horas de trabajo, el mismo día o a la mañana siguiente. Solicitudes de más de 4 horas, triadas al próximo sprint.
4. Todo lo etiquetado como «informe del consejo» o «revisión ejecutiva» sube al frente de la cola.

Tres campos requeridos. No siete. No un formulario de 14 preguntas. El tercer campo (qué decisión informa) es el que hace la magia. La mitad de las solicitudes mueren en él porque quien las hace se da cuenta de que en realidad no necesita los datos, solo tenía curiosidad. La otra mitad llegan más acotadas porque quien las hace tuvo que pensar primero.

Pida a su manager que envíe el anuncio, no usted. «Hola equipo, [su nombre] ahora gestiona la admisión de analítica. Por favor usen el formulario a partir de ahora.» Esa frase vale más que cien mensajes directos de Slack que usted no tiene que absorber.

El SLA no se trata de decir que no. Se trata de convertir «el próximo sprint» en una respuesta normal en lugar de una discusión.

Construya un modelo de dbt

El modelo de dbt es la definición canónica de ingresos por la que discutió en la semana 2. Solo ese. No una capa de métricas. No una refactorización semántica. Un modelo.

Nómbrelo fct_revenue_canonical o según la convención de su repositorio. Escriba el bloque de documentación. Agregue tests. Hágalo revisar. Fusiónelo. Actualice el panel de control de la semana 5 para que use ese modelo como fuente.

Este es su momento de «pertenezco aquí». La primera vez que alguien en una reunión diga «espera, ¿qué número de ingresos estamos usando?» y un compañero responda «el canónico, es el modelo de dbt que entregó [su nombre]», ese es el momento en que deja de ser el nuevo analista y se convierte en el analista.

No intente, bajo ninguna circunstancia, refactorizar el resto del almacén de datos en el mes dos. El cementerio de nuevos analistas está pavimentado con personas que intentaron «reconstruir todo» en la semana 6 y rompieron un informe del consejo en la semana 8. Entregue un modelo. Continúe.

Días 61-90: Sea dueño de una métrica, presente el plan

El mes tres es donde deja de ser evaluado por tickets cerrados y empieza a ser evaluado por lo que tiene asignado.

Adopte el tiempo hasta el hallazgo como su métrica

Elija una métrica de nivel de equipo y sea su dueño. La más sólida para analistas es el tiempo hasta el hallazgo: mediana de horas desde «solicitud enviada» hasta «respuesta de datos entregada». Algunos equipos lo llaman tiempo de primera respuesta a pregunta de datos. La misma idea.

Mídalo desde su formulario de admisión (ya tiene uno). Establezca una línea de base en la semana 9. Fije un objetivo para la semana 12. El mío fue: mediana de 6 horas, objetivo por debajo de 4.

¿Por qué esta métrica y no, por ejemplo, «tasa de adopción de paneles de control» o «consultas ejecutadas»? Porque el tiempo hasta el hallazgo es el que sienten sus partes interesadas. No notan cuando la tasa de adopción sube. Notan cuando su pregunta se responde antes del almuerzo en lugar del próximo martes.

Repórtelo semanalmente en la reunión de equipo. Tres números: mediana, p90, conteo. Eso es todo.

El informe de 90 días

Alrededor del día 85, escriba a su manager un informe de una página. Cuatro secciones, en este orden:

Eliminado. Número de paneles de control archivados, con una lista. Ahorro estimado de carga en el almacén de datos si puede medirlo.

Entregado. El panel de control. El modelo de dbt. El formulario de admisión con dos meses de datos de rendimiento.

Roto. Lo que encontró que sigue mal. Sea específico. «El modelo de MRR por segmento cuenta dos veces las conversiones de prueba en la región EMEA. Afecta a 4 paneles de control. La corrección es un proyecto de 1 semana.» No lo suavice. Su manager quiere la lista.

Próximo. Dos proyectos estratégicos, una inversión en plataforma, una solicitud de personal si corresponde. Concreto. Con plazos aproximados.

Una página. No más. Envíelo como documento y luego recórralo en su reunión 1:1.

La presentación del plan del segundo semestre

El informe de 90 días es el calentamiento. La presentación es lo que viene después. En la misma reunión 1:1, usted dice: «Quiero ser responsable del plan de analítica del segundo semestre. Este es el perfil aproximado: dos proyectos estratégicos (X e Y), una inversión en plataforma (una capa de métricas / reverse ETL / marco de experimentación) y una decisión de personal (¿contratamos un segundo IC o un senior para liderar?). Tendré un documento completo para el [fecha].»

Este es el momento que distingue al analista que sigue siendo IC cinco años después de aquel que dirige un equipo en 18 meses. La mayoría de los analistas esperan que su manager planifique por ellos. Usted va a planificar para su manager.

Habrá objeciones. El plan será editado. Dos de sus proyectos serán cancelados. Está bien. La presentación es el acto, no el artefacto.

Las trampas (estas lo tentarán, no caiga en ellas)

Decir sí a cada solicitud puntual en el mes 1. Lo dije al principio, lo repito. El ciclo de solicitudes puntuales es una puerta de un solo sentido. Dice sí en la semana 1 y sigue diciéndolo en el año 2.

Reconstruir el almacén de datos en la semana 2. Todavía no entiende el negocio. El modelo «obviamente roto» es estructuralmente necesario para alguien que usted no ha conocido. Audite primero.

Desaparecer durante 60 días y luego presentar una auditoría de 40 páginas. Nadie pidió la auditoría. Pidieron evidencia de que usted existe. Entregue la lista de eliminación en la semana 4. Publique el SLA en la semana 6. Aparezca.

Entregar un panel de control con la definición de ingresos incorrecta. Se saltó la reconciliación con finanzas en la semana 2. Ahora su panel de control contradice el informe del consejo. Confianza perdida. Difícil de reconstruir. No lo haga.

Plantillas que realmente usará

Hoja de cálculo de inventario de paneles de control. Seis columnas: nombre, propietario, última vista (fecha), última edición (fecha), estado (activo/sospechoso/inactivo), decisión de eliminar o conservar. Una fila por panel de control. Ordene por última vista en orden ascendente y los inactivos suben al principio.

Lista de preguntas para reuniones con partes interesadas. Cinco preguntas, en orden: (1) ¿Qué decisiones tomó el trimestre pasado para las que desearía haber tenido mejores datos? (2) ¿Qué número revisa cada mañana? (3) ¿Qué panel de control usa realmente frente a cuál existe para usted? (4) ¿Qué pregunta sigue recibiendo de su jefe que no puede responder rápidamente? (5) Si le pudiera dar una nueva vista del negocio, ¿cuál sería? Observe que ninguna es «¿qué necesita de mí?». Esa pregunta le da una lista de deseos. Estas preguntas le dan la verdad.

Formulario de admisión de solicitudes puntuales. Tres campos. Solicitud. Fecha límite. Decisión que informa. Eso es todo.

Informe de 90 días. Una página. Eliminado. Entregado. Roto. Próximo. Viñetas, no párrafos.

Cómo se ve el «éxito» al día 90

Para el día 90, el conteo de paneles de control en su herramienta BI es menor, no mayor. Hay un modelo de dbt canónico para la métrica sobre la que su empresa solía discutir. Las partes interesadas usan el formulario de admisión en lugar de enviarle mensajes directos. Su manager tiene un plan escrito del segundo semestre de usted, no al revés. Y en algún lugar de la pantalla de la empresa, los paneles de control muestran el mismo número un martes que un viernes.

Usted no es la persona de consultas puntuales. Usted es el analista.

Ese es el trabajo.

Más recursos

• Descripción de puesto: Data Analyst (la descripción de puesto que acompaña a este Playbook)
• Un día en la vida de un Data Analyst
• SQL y modelado de datos que escala
• Traducción para partes interesadas: de solicitudes vagas a análisis entregables
• Métricas para Data Analysts: tiempo hasta el hallazgo, adopción e impacto
• Errores comunes de los Data Analysts