Un día en la vida de un Data Scientist

Son las 8:07am. Su teléfono vibró a las 6:42 con una alerta de degradación del modelo desde MLflow. El PM le envió un mensaje directo en Slack a las 7:55: "pregunta rápida, ¿por qué este usuario fue marcado como posible abandono?" Todavía no ha abierto su laptop. Bienvenido al trabajo que nadie describe con precisión en LinkedIn.

La descripción del puesto con la que firmó prometía "construir modelos de ML, generar insights, colaborar con partes interesadas". Todo eso es verdad, técnicamente. Las proporciones no lo son. En un martes típico en una empresa B2B SaaS, la construcción de modelos ocupa quizás una cuarta parte de su día. La ingeniería de características y el trabajo de fontanería SQL se comen otro bloque grande. El resto es trabajo de traducción: explicarle a un VP por qué precisión no es exactitud, defender un intervalo de confianza ante un director de ventas, grabar un Loom que nadie ve, y recordarle al equipo de plataforma que sí, el modelo dbt que falla todos los miércoles sigue fallando todos los miércoles.

Esta no es la versión del trabajo del Data Scientist senior en LinkedIn. Es la real. Si lleva tres meses en el cargo y su semana no se parece en nada al rol para el que hizo la entrevista, eso no es un defecto suyo. Es el rol.

Así se ve un martes real.

8:00 a 8:30am: la revisión del rendimiento del modelo

Café en mano, laptop abierta, la primera pestaña es siempre MLflow o Weights & Biases. Revisa las predicciones de ayer contra las etiquetas que llegaron durante la noche. El AUC del modelo de abandono cayó de 0.84 a 0.79 durante el fin de semana. No es una catástrofe, pero es suficiente para investigar antes del standup.

Primero revisa las cosas obvias. ¿Cambió la distribución de entrada? Abre el dashboard de deriva de características. Dos características están derivando. Una es "días desde el último login", lo que tiene sentido porque el equipo de producto lanzó un nuevo flujo de incorporación el viernes y muchos usuarios antiguos fueron reactivados. La otra es "tickets de soporte en los últimos 30 días", que no tiene una explicación obvia. Anota para investigarla después del standup.

Esta revisión de treinta minutos es una de las partes más subestimadas del trabajo. La mitad de los Data Scientists senior que conozco fueron promovidos por detectar algo aquí que nadie más hubiera detectado. El modelo no falló. El mundo en el que fue entrenado el modelo cambió, ligeramente, y usted lo notó antes que nadie.

También revisa las ejecuciones de experimentos de ayer en MLflow. Dos compañeros de equipo iniciaron trabajos de entrenamiento a las 11pm. Uno convergió. El otro explotó porque alguien renombró una columna en la tabla de origen sin decirle a nadie. Bienvenido al trabajo con datos.

9:30 a 11:30am: diseño del experimento (90 minutos discutiendo sobre la métrica)

El PM llega al standup con una pregunta: "¿La nueva página de precios convierte mejor?" Fácil, ¿verdad? Tamaño de muestra, prueba de dos proporciones, listo.

Nunca es tan fácil.

Pasa 90 minutos en Hex delimitando el experimento. La matemática es la parte sencilla. Esto es lo que realmente se come el tiempo:

Definir "ganar". El PM quiere medir los clics en el botón "Comenzar prueba gratuita". Usted señala que los clics no son lo mismo que los inicios, los inicios no son lo mismo que las activaciones y las activaciones no son lo mismo que las conversiones de pago. Cuando termina, la métrica de éxito ha cambiado tres veces y hay una métrica de protección para la retención en la primera semana porque el funnel de la página de precios antigua tenía una fuga conocida después de la activación.

Verificación del cálculo de potencia. Con su tráfico semanal actual, detectar un incremento relativo del 3% en las conversiones de pago requiere ejecutar la prueba durante seis semanas. El PM quiere resultados en dos. Acuerdan una métrica sustituta más ruidosa (inicios de prueba) para la lectura temprana y la métrica real (conversiones de pago) para la decisión final.

Métricas de protección. ¿Y si la nueva página aumenta los inicios de prueba pero reduce la calidad de esas pruebas? Agrega una protección en la tasa de activación. ¿Y si cambia la combinación de niveles de planes seleccionados? Agrega una protección en los ingresos promedio por nuevo cliente. Ahora hay tres métricas, dos protecciones y una regla de parada.

Compromiso de segmentación previo. El PM pregunta si puede "simplemente dividirlo por tamaño de empresa después". Usted dice no, y luego sí, pero solo con corrección de Bonferroni y una lista escrita de los segmentos antes de que comience la prueba. Escriben la lista juntos. Esto salvará el trabajo de alguien más adelante.

Publica el documento de diseño del experimento en el espacio de trabajo de Hex del equipo, lo vincula en la página del proyecto en Notion y etiqueta al PM y al líder de ingeniería. La matemática tomó 15 minutos. La conversación tomó 75. Esa proporción es aproximadamente correcta para el resto de su carrera.

12:30 a 2:00pm: trabajo asíncrono con ingeniería sobre el despliegue en producción

Come rápido en su escritorio. El bloque de la tarde es el que más frustra a los DS nuevos: su modelo lleva "listo para entregar" tres semanas, y el bloqueador no tiene nada que ver con el modelo.

El modelo en sí está bien. El problema es el pipeline de características. Su modelo de abandono necesita una característica llamada weighted_engagement_30d, que es una suma ponderada de logins, envíos de mensajes y asistencia a reuniones en los últimos 30 días. Esa característica se calcula en un modelo dbt llamado fct_user_engagement_daily. El modelo dbt falla todos los miércoles por la mañana entre las 6 y las 7am del Pacífico porque depende de una sincronización con Salesforce que termina de forma inconsistente.

Usted no es el responsable del modelo dbt. Lo es el equipo de ingeniería de analítica. Saben que es inestable. Tienen un ticket para ello. Lo han tenido durante dos meses.

Así que el trabajo de hoy es escribir un comentario largo en el PR del despliegue en staging. Explica:

El pipeline de características tiene una ventana de fallo semanal conocida
Su modelo necesita la característica con una antigüedad máxima de 24 horas
El monitoreo actual en el modelo dbt se activa después de que la característica ya está desactualizada
Le gustaría que el equipo de plataforma corrigiera el modelo dbt upstream o conectara un fallback que use la última instantánea buena de la característica con un indicador de frescura

Etiqueta al líder del equipo de plataforma, enlaza la alerta de monitoreo de dbt del miércoles pasado como evidencia y enlaza su documento de requisitos de frescura del modelo. No escala. No se queja. Deja un comentario de PR calmado y específico con tres opciones clasificadas por su preferencia y una recomendación por defecto. Luego cierra la pestaña.

Esta es la parte del trabajo que la descripción del puesto llama "colaboración interfuncional". Es principalmente esperar, con una defensa tranquila e intermitente, para que algo que usted no puede arreglar sea arreglado por otra persona. Haga las paces con eso desde el principio.

2:00 a 3:00pm: la reunión "esta predicción está equivocada"

Un director de ventas ha reservado treinta minutos en su calendario. El asunto: "Chat rápido sobre el modelo de abandono: uno de mis clientes que marcó acaba de renovar por tres años."

Sabe cómo va a ir esto. Ha tenido esta reunión aproximadamente catorce veces desde que empezó. Tiene un guion. Aquí está la forma general:

Abra con curiosidad, no con defensa. "Cuénteme sobre el cliente. ¿Cuál es su historia?" Deja que el director de ventas se exprese durante cinco minutos sobre cómo el modelo va a avergonzar al equipo, cómo el cliente estaría insultado si lo supiera y cómo siempre tuvo la sensación de que el modelo era poco confiable.

Reencuadre la métrica sin hacerlos sentir mal. "El modelo predice con una precisión del 87% en la cohorte de 'alto riesgo de abandono'. Eso significa que de cada 100 cuentas que el modelo marca, alrededor de 87 realmente abandonan en 90 días. Las otras 13 no lo hacen. Esta cuenta es una de esas 13. Eso no es que el modelo falle. Eso es que el modelo funciona exactamente como fue diseñado."

Traiga un dashboard de Looker, no un tono defensivo. Comparte su pantalla y abre el Looker de rendimiento del modelo de abandono. Muestra la curva de precisión-recall. Muestra que reducir el umbral para capturar más abandonos significaría aún más falsos positivos, y aumentarlo perdería abandono real. Muestra el valor en dólares del abandono capturado el trimestre pasado ($2.4M) frente al valor en dólares de los falsos positivos si cada cuenta marcada se fuera (mucho mayor que eso, pero no necesitan saber eso).

Cierre con para qué sirve el modelo, en su lenguaje. "Este modelo es una herramienta de clasificación. No es un veredicto. Le dice a su equipo dónde gastar la primera hora de su semana. El hecho de que una cuenta marcada haya renovado significa que su equipo hizo su trabajo. Intervinieron. Esa es la condición de victoria."

El director de ventas abandona la llamada más tranquilo de lo que llegó. Usted agrega la conversación al registro de experimentos. Agrega una diapositiva a la próxima sincronización mensual DS-Ventas llamada "Precisión no es exactitud" porque si ha tenido esta conversación 14 veces, el resto del equipo de ventas la ha tenido más veces de las que admiten.

4:00 a 5:30pm: limpieza del notebook y el registro de experimentos

El último bloque del día está de vuelta en Jupyter. Abre el notebook de análisis del alcance del experimento de la página de precios de esta mañana. Está desordenado. La mitad es código de boceto. Hay una celda que solo dice df.head() sin comentario. Hay una gráfica sin etiquetas en los ejes. Hay una consulta SQL contra el esquema equivocado.

Lo limpia. La disciplina aquí importa más que la estética. No lo está haciendo bonito para usted. Lo está haciendo legible para la versión de usted en tres meses que necesitará recordar por qué eligió el tamaño de muestra 4.200 y no 5.000. La convención en su equipo:

Celda markdown en la parte superior del notebook con la pregunta, la fecha y la conclusión
Cada sección tiene un encabezado markdown de una línea sobre el código
Los gráficos tienen títulos, etiquetas en los ejes y una interpretación de una oración debajo
La celda final es una celda markdown con la recomendación y la siguiente acción

Confirma el notebook en el repositorio del equipo. Escribe un resumen de 200 palabras en el registro de experimentos del equipo, que vive en una página compartida de Notion. También hace push del cambio en el modelo dbt que escribió esta mañana. Está en una rama separada y etiquetado para revisión mañana.

Lo último antes de cerrar la laptop: revisa las notas de la reunión del director de ventas de las 2pm y agrega una tarea al backlog del equipo. "Construir un dashboard de Looker orientado a ventas que muestre la precisión y la sensibilidad del modelo de abandono en lenguaje concreto, actualizado semanalmente." Esta es la tercera vez que piensa en construirlo. Quizás esta semana realmente lo haga.

Lo que la descripción del puesto no le dirá

Algunas cosas que la JD pasará por alto y que vale la pena saber desde el primer día.

Escribirá más SQL que Python. Snowflake o BigQuery serán su segundo idioma. Cuanto más limpio sea su SQL, más rápido será su ciclo de iteración. La mayoría de los cuellos de botella en su semana no son de modelado. Son "los datos todavía no están en la forma correcta".

La ingeniería de características consume el 40% de su tiempo de modelado. El modelo XGBoost tarda 20 minutos en entrenar. Las características que lo alimentan tardaron dos semanas en construir, validar e integrar en un pipeline. Los DS nuevos subestiman esto siempre.

El "problema de ML" más difícil suele ser una parte interesada que no confía en el resultado. Puede tener un modelo perfectamente calibrado con un AUC digno de publicación y cero impacto, porque nadie actuará sobre él. La confianza se construye a través de explicaciones repetibles, dashboards en el lenguaje de las partes interesadas y mostrarse con calma en la reunión "esta predicción está equivocada".

El pánico de "esta predicción está equivocada" es un evento semanal. Tenga un guion listo. Traiga un dashboard. No se ponga a la defensiva. La conversación es el trabajo, no una distracción del trabajo.

Los despliegues en producción son más lentos de lo que cree. No porque el código sea difícil. Porque las dependencias de datos son inestables, el entorno de staging es un espejo de la producción del trimestre pasado y el equipo de plataforma también está haciendo su mejor esfuerzo.

Herramientas que realmente usará

El stack varía según la empresa, pero la forma es consistente. En la mayoría de las empresas B2B SaaS con una función de DS real en 2026:

Python y Jupyter para análisis y modelado. Algunos equipos han trasladado trabajo más pesado a VS Code con notebooks como archivos de porcentaje, pero Jupyter sigue siendo el predeterminado para exploración.
SQL en Snowflake o BigQuery para todo lo que toca datos de producción. Si venía de un lugar que usaba Postgres directamente, el modelo mental del almacén de datos es diferente y pensará en el costo por consulta por primera vez.
dbt para transformaciones. Leerá más modelos dbt de los que escribe, pero escribirá algunos.
MLflow o Weights & Biases para el seguimiento de experimentos. La mayoría de los equipos tiene uno u otro; casi no importa cuál.
Hex para notebooks colaborativos que PMs y analistas pueden leer. Hex está haciendo por el análisis lo que Figma hizo por el diseño.
Looker para dashboards orientados a partes interesadas. Los dashboards que construye aquí son por lo que sus partes interesadas lo juzgan, aunque el modelo detrás de ellos sea el trabajo real.
Opcional pero común: Airflow, Prefect o Dagster para orquestación. Puede o no ser su responsabilidad.

No usará todos estos en todos los equipos. Probablemente aprenderá uno nuevo en sus primeros 90 días.

Cómo se ve "lo bueno" después de 90 días

Si es nuevo en el rol, aquí tiene una definición útil de éxito a los tres meses. Olvide el conteo de modelos. Busque estas señales:

Puede nombrar las preguntas reales de sus tres principales partes interesadas, en su lenguaje, sin tener un documento delante.
Tiene un modelo en producción. Aunque sea pequeño. Aunque sea una regresión logística con una sola característica. La producción supera al notebook.
Ha dejado de ponerse tenso cuando una parte interesada le escribe "esta predicción está equivocada". Tiene un guion. Trae un dashboard.
Sabe qué modelos dbt fallan semanalmente y qué características son inestables. Ha dejado de sorprenderse por el fallo del miércoles.
Ha escrito al menos un documento que otro DS del equipo ha enlazado. El conocimiento que se acumula supera al análisis que se olvida.

Ese es el nivel. No "entregué cinco modelos" ni "dupliqué la velocidad del equipo". Esas métricas no sobreviven el contacto con la realidad. La lista anterior sí.

La división 50/50 entre trabajo técnico y trabajo de traducción no es un defecto del rol. Es el rol. La traducción no está por debajo del modelado. Es como el modelado realmente cambia algo. Los DS que se involucran en eso antes que sus pares son los que son promovidos a Senior en 18 meses en lugar de 30.

La alerta de degradación del modelo a las 6:42am volverá a vibrar mañana. Desayune primero.

Playbooks del Data Scientist