Español

Un día en la vida de un Business Analyst (B2B SaaS, carrera IC)

Antes de que abra el portátil, ya hay 11 mensajes de Slack preguntando por qué el MRR bajó. Ninguno está equivocado. Ninguno tiene la misma respuesta.

Un PM está mirando el panel ejecutivo, que extrae de un modelo de dbt que se ejecutó a las 5 AM. Un CSM está mirando un reporte de Salesforce que define el MRR como el valor del contrato comprometido. El VP de Finanzas está mirando la vista de reconocimiento de ingresos, que excluye todo lo que aún no se ha facturado. Todos son correctos, y todos están mirando números diferentes, y a las 9:30 AM alguien me preguntará cuál es el "MRR real". Esa respuesta tarda 20 minutos en dar y otros 20 en defender. Bienvenido al martes.

Lo que prometía la descripción del puesto versus cómo se ve el martes en realidad

La descripción del puesto decía "generar insights de negocio" y "ser socio del liderazgo en decisiones estratégicas". Lo acepté. La realidad es que mi semana es aproximadamente 60% SQL y fontanería de datos, 30% traducción entre Ingeniería y Producto (y Ventas, y Finanzas, y ese director de CS que solo se comunica en notas de voz), y 10% análisis real. El insight solo ocurre cuando la fontanería funciona bien. Un BA que no puede mantener los paneles en verde nunca es invitado a la mesa de estrategia. Está demasiado ocupado en el sótano arreglando tuberías.

Aquí está el recorrido hora por hora para un día normal. Stack: Snowflake para el almacén de datos, dbt para las transformaciones, Looker para BI (con algunos notebooks de Hex para trabajos ad hoc), Notion para especificaciones, Jira para los tickets.

8:00 AM: verificación de salud del panel de control

Antes de responder un solo mensaje de Slack, hago el mismo recorrido de cinco minutos cada mañana:

  1. ¿Terminó la ejecución de dbt? Verifico el resumen de trabajos en dbt Cloud. ¿Todo en verde, o falló fct_revenue a las 4:47 AM porque alguien entregó un cambio de esquema?
  2. Marcas de tiempo de actualización en el panel ejecutivo. Abro el panel de Looker ejecutivo. El indicador de "última actualización" debería decir "hoy, alrededor de las 6 AM". Si dice "ayer", algo aguas arriba está desactualizado.
  3. Conteos de filas versus ayer. Tres consultas contra el almacén de datos (pedidos, oportunidades, cuentas activas). Si los conteos de filas cayeron más del 5%, una sincronización de Fivetran aguas arriba está rota.
  4. Los tres KPIs principales. Conteo de nuevos clientes, MRR y retención bruta. ¿Están dentro de rangos razonables, o uno muestra una variación del 40% semana a semana que indica "la definición se rompió"?
  5. La verificación de "¿alguien tocó la capa semántica anoche?". Reviso el repositorio de LookML en busca de fusiones en las últimas 12 horas.

Aquí hay una consulta de verificación rápida que tengo fija en Snowflake. Se ejecuta en menos de cinco segundos:

select
  date_trunc('day', created_at) as day,
  count(*) as orders,
  sum(amount) as gmv
from analytics.fct_orders
where created_at >= dateadd('day', -7, current_date)
group by 1
order by 1 desc;

Si la fila de hoy falta o el GMV oscila bruscamente, lo sé antes que el CEO. Ese es el punto. Detectar un join roto a las 8:05 AM es una corrección de tres minutos. Detectarlo a las 9:35 AM después de que ya comenzó la reunión general es un simulacro de incendio de 90 minutos más un correo de disculpa.

9:00 AM: clasificación de prioridades de solicitudes ad hoc

La cola está en tres lugares, como era de esperar. El tablero de Jira para solicitudes formales. El canal #data-help de Slack para "preguntas rápidas". Una página compartida de Notion donde uno de los directores sigue añadiendo solicitudes porque se niega a usar Jira. Reviso las tres.

Esta mañana: cinco nuevas solicitudes. Mi trabajo no es responderlas. Mi trabajo es clasificar las prioridades.

  • "¿Puedes extraer el abandono de clientes por nivel de plan del último trimestre?" Bloqueante. El CFO lo necesita para la presentación del directorio el jueves. Si la capa semántica está limpia, esto es una consulta de 15 minutos. Si fct_subscription_events todavía tiene el problema antiguo con el join de plan_id, son dos horas. Estimación: 30 minutos. Tomo este.
  • "Tengo curiosidad, ¿cuántos de nuestros usuarios de prueba provienen de LinkedIn?" Curioso, no bloqueante. El panel de marketing ya tiene el desglose por fuente de adquisición. Respondo con una captura de pantalla y un enlace. Dos minutos.
  • "Necesito saber nuestra tasa de victorias en el Q1 por industria." Ya existe en el panel de rendimiento de ventas de Looker. Envío el enlace y una oración sobre qué filtro aplicar. Tres minutos.
  • "¿Puedes crear un panel para nuestro nuevo experimento de precios?" Trabajo real. Necesita una conversación de alcance de 30 minutos, no una consulta SQL. Respondo: "Entendido, dediquemos 20 minutos el jueves a delimitar la decisión que este panel necesita impulsar."
  • "Este número en el panel de CS se ve raro, ¿puedes verificarlo?" Podría ser nada, podría ser todo. Lo abro. El número está bien. La leyenda es incorrecta porque alguien renombró una medida. Corrección de 10 minutos en LookML.

La regla de clasificación que salvó mi cordura: separar "bloqueante" de "curioso". Bloqueante significa que una decisión no puede avanzar sin una respuesta. Curioso significa que alguien está en un explore de Looker y se distrajo. Los curiosos se redirigen a la opción de autoservicio. Los bloqueantes van al principio de la cola. Si todo es "bloqueante", nada lo es.

El equipo de datos al que pertenezco tiene tres personas. Entre todos recibimos entre 8 y 12 solicitudes ad hoc netas nuevas por semana. Sin clasificación de prioridades, la cola se come todo el trabajo.

11:00 AM: entrevista de requisitos a mitad del día

Un PM reserva 45 minutos en mi calendario. La agenda dice: "Delimitación del panel de compromiso de usuarios". He estado aquí antes. El PM quiere "un panel para el compromiso". Eso no es una solicitud. Es un sentimiento.

Mi trabajo en esta reunión es llegar a la decisión real que impulsará el panel, y luego trabajar hacia atrás hasta dos o tres métricas que no sean métricas de vanidad. Aquí está el guión de preguntas que uso, y literalmente lo tengo abierto en un documento de Notion cuando comienza la reunión:

  1. ¿Qué decisión tomará de forma diferente después de mirar este panel? (Si no pueden responder, el panel es una solicitud de vanidad. Deténgase aquí.)
  2. ¿Quién más necesita verlo y qué decisión toman?
  3. ¿Con qué frecuencia lo mirará (diario, semanal, mensual)? (Diario significa que necesita una alerta de Slack, no un panel.)
  4. ¿Qué número, si cambiara, le haría hacer algo esta semana?
  5. ¿Cuál es el umbral? ¿Qué cuenta como "bueno" versus "malo"?
  6. ¿Qué ya existe que sea casi esto, pero no exactamente? (A menudo hay un explore de Looker existente que cubre el 80%.)
  7. Si solo podemos entregar dos gráficos, ¿cuáles dos importan más?

Hoy el PM dijo "panel de compromiso de usuarios". Después de 30 minutos con esas preguntas, lo que realmente necesita es un gráfico (usuarios activos semanales por cohorte de funcionalidad) más una alerta de Slack cuando el WAU caiga más de un 10% semana a semana. Esfuerzo de construcción: medio día. Solicitud original, tomada al pie de la letra: probablemente dos semanas para algo que nadie abriría después del primer sprint.

El PM que pide "un panel" normalmente necesita un gráfico y una alerta de Slack. Aproximadamente el 70% de las veces, en mi experiencia.

1:30 PM: trabajo asincrónico con ingeniería y producto

El almuerzo fue un sándwich en mi escritorio mientras revisaba un PR de dbt. Esta es la parte de traducción del trabajo, y es la parte que nadie le dice en las entrevistas.

Comentario en el PR de dbt. Un ingeniero de analítica está refactorizando dim_accounts y renombrando una columna de account_owner_id a owner_user_id. La descripción del PR no menciona los cuatro explores de Looker descendentes que hacen referencia al nombre antiguo. Dejo un comentario con enlaces a cada explore afectado y una nota de que necesitamos (a) un alias de columna para compatibilidad hacia atrás o (b) un PR de LookML coordinado entregado al mismo tiempo. Este comentario de 10 minutos previene tres mensajes directos de Slack a las 9 AM de mañana preguntando por qué el panel de ventas está roto.

Respuesta a una especificación de producto. Un PM ha escrito una especificación para un nuevo flujo de incorporación en la aplicación y me ha etiquetado preguntando si puedo "rastrear el compromiso con cada paso". Mirando el seguimiento de eventos, los eventos que quieren no existen. La instrumentación de producto actual activa onboarding_started y onboarding_completed, punto. Para responder la pregunta que realmente les importa (dónde abandonan los usuarios el flujo), necesitamos eventos a nivel de paso: onboarding_step_viewed con una propiedad step_name. Lo escribo en el documento de especificación con el esquema exacto del evento, les señalo el plan de seguimiento existente en Notion y añado un ticket de Jira al backlog de Ingeniería para añadir los eventos.

Este es el trabajo que no aparece en ningún panel de control pero que separa a un BA que es contratado de nuevo de uno que no lo es. Ingeniería habla en tablas y esquemas. Producto habla en funcionalidades y resultados. Las partes interesadas hablan en sentimientos y mensajes de Slack. El BA conecta los tres. Los PRs de dbt revisados antes del almuerzo previenen interrupciones de Looker después del almuerzo. Ese es el trabajo.

3:00 PM: extracción de datos ejecutiva al final del día

El VP de Ventas me escribe a las 2:55 PM. La llamada de preparación del directorio es a las 4. Necesita el pipeline del trimestre hasta la fecha por segmento, desglosado por etapa y ponderado por probabilidad de etapa. La diapositiva se está construyendo ahora mismo.

El SQL está bien. Tengo una consulta guardada para exactamente este corte. Se ve aproximadamente así:

select
  segment,
  stage,
  count(*) as opps,
  sum(amount) as pipeline_amount,
  sum(amount * stage_probability) as weighted_pipeline
from analytics.fct_opportunities
where close_quarter = 'Q2-2026'
  and is_active = true
group by 1, 2
order by 1, 2;

La parte difícil no es la consulta. Es la advertencia. El VP quiere un número en la diapositiva. Tengo que decidir cuál y explicarle por qué. Tres opciones, todas defendibles:

  • Monto del pipeline (suma bruta): número más grande, se ve excelente, incluye tratos con un 10% de probabilidad de cerrarse.
  • Pipeline ponderado (suma x probabilidad de etapa): más honesto, más pequeño, lo que prefiere la mayoría de los CFOs.
  • Pipeline comprometido (solo etapas 4 y superiores): más conservador, lo que reportamos en el QBR.

Envío los datos con una nota de un párrafo: "La diapositiva debería usar el pipeline ponderado. Eso es lo que el CFO presentó el trimestre pasado, y usar una definición diferente este trimestre desencadenará una pregunta de '¿por qué cambió la metodología?'. Si el VP quiere el número bruto para la narrativa, que lo liste como nota al pie."

Los datos tardan cuatro minutos. La recomendación tarda 12. La recomendación es la parte que me hace ser invitado de nuevo el próximo trimestre.

4:30 PM: el pánico de "este reporte está mal"

Justo a tiempo. Un Director de Customer Success me escribe por Slack: "Oye, el número de nuevos clientes en el panel de CS dice 47 para abril, pero Salesforce dice 52. ¿Puedes verificarlo?"

Esta es la emergencia más común en el trabajo, y casi siempre tiene la misma causa raíz. Aquí está la depuración de 20 minutos que ejecuto, en orden:

  1. Verificación de definición. ¿Qué llama el panel "nuevo cliente"? En Looker, está filtrado a is_first_paid_invoice = true. En Salesforce, el reporte está filtrado a opportunity_stage = 'Closed Won' Y account_type = 'New Logo'. Esas son definiciones diferentes. Una oportunidad puede estar Closed Won pero aún no tener una factura pagada (demora de facturación de 5 días). Eso solo suele explicar una brecha de 5 tratos.
  2. Verificación de zona horaria. Salesforce reporta en la hora local del usuario. El panel de Looker está en UTC. El 30 de abril en hora del Pacífico es el 1 de mayo en UTC. Uno o dos tratos siempre quedan atrapados en esto.
  3. Verificación de filtros. ¿El reporte de Salesforce incluye renovaciones o actualizaciones? A veces el filtro de "nuevo cliente" está mal configurado.
  4. Verificación de actualización de datos. ¿Cuándo fue la última sincronización de Salesforce a Snowflake? Si fue hace 10 minutos, bien. Si fue hace seis horas, puede que se hayan cerrado dos tratos más desde entonces.
  5. Error de datos real. Solo después de descartar los primeros cuatro verifico si hay un problema aguas arriba.

La respuesta de hoy: discrepancia de definición. Looker usa factura pagada; Salesforce usa closed-won. Ambos son "correctos", simplemente responden preguntas diferentes. El número de Looker es el correcto para los propósitos del equipo de CS (debería celebrarse a los clientes que pagan, no los cierres en papel), pero documento la diferencia en la descripción del panel para que esto no vuelva a ocurrir el mes que viene.

La comunicación importa tanto como el diagnóstico. Nunca respondo con "el reporte de Salesforce está mal". Respondo con: "Ambos son correctos, pero están midiendo cosas diferentes. Aquí está lo que significa cada uno, aquí está por qué difieren este mes, y aquí está cuál usar para el QBR de CS." Nadie se pone a la defensiva. Nadie escala. El director me agradece y sigue adelante.

"Este reporte está mal" es casi siempre un desacuerdo de definición, no un error de datos. Quizás el 80% de las veces. El otro 20% son errores reales, y esos obtienen un ticket de Jira y un análisis post-mortem.

5:30 PM: cierre del día

Esta mañana entraron cinco solicitudes ad hoc. Cerré tres. Dos se pospusieron a mañana con una respuesta en Slack explicando por qué, para que nadie se pregunte. Una la añadí al backlog de ingeniería de analítica como solicitud recurrente. La extracción de "abandono de clientes por nivel de plan" llega aproximadamente dos veces por trimestre, y es hora de convertirla en un panel de autoservicio para que deje de llegar a mi cola. Ese es el movimiento de mayor apalancamiento que haré en todo el día, y tardó dos minutos.

Lo último que hago antes de cerrar el portátil: una nota de una línea en mi registro diario de Notion. Qué entregué, qué aprendí, qué se pospuso. Mañana por la mañana, cuando los 11 mensajes de Slack vuelvan a empezar, ese registro es cómo recuerdo qué incendios ya estaban ardiendo.

El cuadro de mando honesto

Al final de un buen día, el BA entregó un análisis real (la delimitación del panel de compromiso de usuarios que convirtió una construcción de dos semanas en un gráfico y una alerta de medio día), desbloqueó a tres partes interesadas (el CFO con la extracción de abandono de clientes, el VP de Ventas con el corte del pipeline, el director de CS con la pregunta del nuevo cliente) y previno un incidente de número incorrecto (el comentario en el PR de dbt que salvó la interrupción de Looker de mañana).

Ese es el trabajo. No "generar insights". No "ser un socio estratégico". Aparecer, mantener los paneles en verde, traducir entre las personas que no pueden comunicarse entre sí y responder la pregunta detrás de la pregunta.

El 10% que es análisis estratégico real solo ocurre cuando el 90% funciona bien. Los BAs que ascienden son los que descubrieron esto antes del tercer mes.

Aprenda más