Español

Sus Primeros 30/60/90 Días como Nuevo Data Scientist

Son las 9:47 del tercer día. Apenas ha descubierto qué canales de Slack importan. Su café todavía está caliente. Un mensaje llega de alguien que conoció una vez durante el onboarding: "oye, ¿puedes echarle un vistazo al modelo de churn? ha estado fallando un tiempo."

Felicitaciones. Acaba de heredar 18 meses de decisiones ajenas. Dos propietarios anteriores, sin documentación que valga la pena leer, un conjunto de características que nadie comprende del todo, y un CFO que lleva seis semanas preguntando cuándo "la inversión en AI" va a rendir frutos. El modelo no se ha reentrenado desde agosto. Ni siquiera ha terminado de configurar su laptop.

Esta es la experiencia real del tercer día para la mayoría de los nuevos Data Scientists en B2B SaaS, y la tentación es brutal: desplegar algo rápido, lo que sea, para parecer que está ganando su lugar. No lo haga. Los primeros 90 días son cuando se establece la narrativa de si el liderazgo lo ve como una palanca de ingresos o como la siguiente línea a cortar cuando la junta pregunta dónde está inflado el headcount. Y los roles de ciencia de datos se cortan más rápido que cualquier otra función técnica cuando la historia de valor de negocio es confusa.

Aquí hay un plan de 90 días que no requiere heroísmo, no depende de que usted sea un genio, y no termina con usted siendo dueño del modelo de churn defectuoso de alguien más como su KPI.

Por qué Auditar Supera a Construir (Y por qué la Mayoría de los Nuevos Data Scientists se Equivocan en esto)

El mayor error que comete un nuevo Data Scientist es desplegar un modelo nuevo en la semana dos para parecer productivo. Se siente bien. Pero también significa que ahora es dueño de algo cuyo contexto de negocio aún no comprende, que ha señalado a las partes interesadas que "desplegar modelos" es su propuesta de valor (no lo es), y que omitió la única ventana que tendrá para hacer preguntas básicas sin ser juzgado.

Tiene exactamente un período de luna de miel. Inviértalo escuchando, no construyendo. La buena noticia es que escuchar produce artefactos tangibles (un memo de auditoría, un mapa de partes interesadas, una guía rápida del almacén de datos) que parecen igual de productivos ante su manager que un modelo a medias, y no generan deuda técnica.

Días 1-30: Auditar y Escuchar

Los primeros 30 días tienen un objetivo: construir un mapa defendible de qué existe, qué está roto y qué quiere la gente realmente. Sin modelos nuevos. Sin "experimentos rápidos". Sin promesas.

Inventariar Cada Modelo en Producción

Cree una hoja de cálculo. Una fila por modelo que se ejecute en cualquier lugar: producción, notebook programado, esa cosa en Airflow que nadie admite que es un modelo. Para cada uno, complete tres columnas:

  • Rendimiento vs. rendimiento declarado. ¿Qué dice la ficha del modelo o la última revisión trimestral que hace (AUC, precisión en el decil superior, MAPE, lo que sea)? ¿Qué hace realmente en los últimos 90 días de datos? Encontrará al menos un modelo donde la brecha es vergonzosa. El modelo de churn suele ser el peor. Una deriva del 15-25% en características clave es normal en B2B SaaS donde la mezcla de clientes cambia cada trimestre.
  • Equidad y deriva. ¿La distribución de entrada todavía se aproxima a lo que el modelo fue entrenado? Para modelos tabulares, una verificación rápida del Índice de Estabilidad de Población (PSI) en las cinco principales características suele decirle todo. Un PSI superior a 0.25 significa que el modelo opera fuera de su distribución de entrenamiento y las predicciones son ruido disfrazado de señal.
  • Valor de negocio real. ¿Quién usa el resultado? ¿Qué decisión impulsa? ¿Qué pasaría si el modelo devolviera un valor constante mañana? Si la respuesta es "honestamente, probablemente nada", anótelo. Lo necesitará después.

Tres a cinco modelos es lo normal. Ocho o más significa que alguien estaba construyendo para parecer ocupado y usted ha heredado un cementerio.

Asistir a Cinco Reuniones de Seguimiento con Partes Interesadas

No cinco conversaciones. Cinco reuniones recurrentes a las que se une como observador silencioso durante las dos o tres primeras antes de comenzar a contribuir. Elija una de cada uno de estos grupos:

  • Sales ops (precisión del pronóstico, cobertura del Pipeline, quejas sobre lead scoring)
  • Customer success (señales de churn, plays de expansión, vínculos entre NPS e ingresos)
  • Producto (adopción de características, activación, qué están probando mal con A/B test)
  • Finanzas (pronóstico de ingresos, economía unitaria, el modelo real del negocio según el CFO)
  • Ingeniería o plataforma de datos (costos del almacén, confiabilidad del Pipeline, qué está en crisis)

Está escuchando dos cosas: qué decisiones se están tomando por intuición cuando podrían tomarse por datos, y qué decisiones se están tomando por datos que en realidad están mal. Lo segundo es más común de lo que la gente admite. Sales ops ejecutando pronósticos de Pipeline basados en un reporte de Salesforce que cuenta doble las renovaciones es una de las situaciones más frecuentes en la mayoría de las empresas B2B SaaS.

Aprender Dónde Están las Inconsistencias del Almacén de Datos

Cada almacén de datos tiene una capa de pequeñas verdades incómodas. Columnas renombradas tres veces. Filas eliminadas de forma lógica que la herramienta de BI incluye silenciosamente. Errores de zona horaria que hacen que los lunes en Singapur aparezcan como domingos. Un campo revenue_usd que es pre-descuento en una tabla y post-descuento en la tabla de al lado.

Pase una semana con quien sea dueño de la capa de analytics. Lleve un cuaderno. Pregúnteles: "¿Qué desearía que la gente supiera antes de consultar esta tabla?" Obtendrá más valor de esa pregunta que de tres semanas leyendo documentación de dbt.

Para el día 30 debería tener: una hoja de cálculo de auditoría, notas de cinco reuniones de seguimiento con partes interesadas, un documento de una página de "puntos clave del almacén de datos" y cero modelos nuevos en marcha.

Días 31-60: Eliminar, Desplegar, Proponer

Ahora empieza a producir trabajo visible. Tres entregables, en este orden.

Eliminar un Modelo Defectuoso, de Forma Pública y con un Memo

Esto suena como algo que limita su carrera. Es lo contrario. Eliminar un modelo defectuoso es lo de mayor impacto que puede hacer como nuevo DS, porque:

  1. Libera cómputo, atención del equipo y ancho de banda de las partes interesadas.
  2. Demuestra que tiene criterio, no solo capacidad de producción.
  3. Establece que "desplegar un modelo" no es una virtud si el modelo está mal.

Elija el peor caso de su auditoría. El candidato clásico es el modelo de churn que ha sido reentrenado dos veces en 18 meses, tiene un 22% de deriva en características, no impulsa ningún play real de retención (los representantes de CS ignoran la puntuación), y cuesta $400 al mes en cómputo. Escriba un memo de una página: qué afirmaba el modelo, qué hacía realmente, cuánto costaba, qué decisión se suponía que debía impulsar, qué propone como reemplazo (a menudo: "un reporte de cohortes simple, actualizado semanalmente").

Envíe el memo a su manager y a la parte interesada original. Deje que respondan. Nueve de cada diez veces dirán "sí, dejamos de mirarlo hace meses." Ahora está eliminado con un registro documentado, y usted ha demostrado al liderazgo que cortará su propio trabajo cuando ese trabajo no justifique su existencia.

Una plantilla breve que funciona:

Memo: Retirar el modelo [nombre del modelo]
Autor: [usted]
Fecha: [fecha]

Qué hace hoy: [una oración]
Qué afirmaba cuando se lanzó: [métrica y valor]
Qué hace realmente en los últimos 90 días: [métrica y valor]
Costo de cómputo: [$/mes]
Decisiones que impulsa: [lista, sea honesto si la respuesta es "ninguna"]
Recomendación: Retirar para el [fecha]. Reemplazar con [cosa más simple o nada].
Riesgo si no lo retiramos: [mantenimiento continuo + falsa confianza en predicciones desactualizadas]

Eso es todo. Una página. Sin apéndices.

Desplegar un Análisis de Resultado Rápido que una Parte Interesada Realmente Pidió

Vuelva a sus notas de las reuniones de seguimiento. Encuentre la solicitud más pequeña y concreta, la que la persona mencionó de pasada, con una decisión clara vinculada. No "deberíamos usar AI para X". Algo como: "me gustaría saber qué paso del onboarding está causando la mayor deserción en los primeros 14 días."

Hágalo. Un resumen fácil de compartir en Slack. Máximo tres gráficos. Recomendación en el primer párrafo. Incluya a la persona que lo pidió y a su manager. No está tratando de ganar una competencia de modelado. Está demostrando que puede convertir una pregunta real en una respuesta real en menos de diez días laborables.

Proponer un Roadmap de ML de 6 Meses Vinculado a 2-3 Métricas de Negocio

Para el día 60 debería tener suficiente contexto para redactar un roadmap. Dos o tres métricas de negocio, como máximo. Para cada una: una hipótesis de 1-2 oraciones, un enfoque de modelo o análisis, una estimación de esfuerzo (pequeño, mediano, grande) y, lo más importante, un criterio de cancelación (qué le haría detenerse en esto).

Los criterios de cancelación son lo que separa un roadmap de una lista de deseos. "Si para la semana 8 el incremento sobre la línea base es inferior al 5%, nos detenemos y reasignamos" es una línea de roadmap. "Construir un modelo de churn" no lo es.

Comparta el roadmap con el ejecutivo que lo contrató. Reciba retroalimentación. Revise. El objetivo es que ese ejecutivo pueda describir sus próximos dos trimestres en una oración a cualquier persona del C-suite.

Días 61-90: Ser Dueño de una Métrica, Presentar y Planificar el H2

Los últimos 30 días tienen como objetivo la transición de "el nuevo DS" a "la persona que es dueña de X".

Ser Dueño de una Métrica de Negocio Vinculada a un Modelo

Esta formulación es fundamental: usted es dueño de la métrica, no del modelo. Si es dueño del "modelo de churn", ha heredado la identidad de otra persona y será juzgado por algo que no diseñó. Si es dueño de "la retención de cuentas a 12 meses en el segmento SMB", puede usar cualquier combinación de modelo, análisis y cambio operativo para mover el número.

Elija una. Solo una. Debe ser:

  • Una métrica que finanzas y el equipo ejecutivo ya rastrean (no invente una nueva)
  • Dentro de su esfera de influencia (un modelo la toca, pero también lo hacen el flujo de trabajo de CS, los precios y el producto)
  • Medible en ventanas de 60-90 días, no de 12 meses

Buenas elecciones comunes para un nuevo DS en B2B SaaS: tasa de churn en SMB, conversión de lead a oportunidad, conversión de prueba gratuita a pago, ingresos de expansión por CSM. Malas elecciones comunes: ingresos totales (demasiadas entradas, nunca obtendrá el crédito), NPS (demasiado ruidoso), "precisión del modelo" (no es una métrica de negocio).

Presentar un Informe de 90 Días al Ejecutivo que lo Contrató

Reunión de 15 minutos. Presentación de cinco diapositivas. La estructura que funciona:

  1. Lo que encontré. La auditoría, en un gráfico (modelos retirados, modelos en buen estado, modelos en observación).
  2. Lo que desplegué. El análisis de resultado rápido, el memo de eliminación, la métrica de la que ahora soy dueño.
  3. Lo que aprendí sobre el negocio. Las dos o tres cosas que le sorprendieron (problemas de calidad de datos, decisiones que no se están tomando por datos, solicitudes que siguen apareciendo).
  4. El roadmap. Su plan de 6 meses, con criterios de cancelación.
  5. Lo que necesito. Headcount, infraestructura, acceso a partes interesadas, decisiones pendientes.

La diapositiva cinco es la más importante y la que más a menudo se omite. Si no puede articular qué necesita para tener éxito en los próximos 90 días, el ejecutivo asumirá que no necesita nada, y luego se preguntará en el mes seis por qué el progreso se detuvo.

Proponer un Plan de ML para H2 con Headcount, Infraestructura y Criterios de Cancelación

Este es el roadmap del día 60, ahora afinado con tres meses de contexto. Tres cosas van en el plan H2 que no estaban en el roadmap original:

  • Matemáticas de headcount. "Para ejecutar este plan necesito X días de ingeniería y Y días de ingeniería de datos por trimestre. Hoy tengo Z. Aquí está la brecha." Sea específico. Los ML engineers son costosos. La capacidad de ingeniería de datos es el cuello de botella en el 60% del trabajo de DS en la mayoría de las empresas B2B SaaS, y decirlo en voz alta temprano lo protege de ser culpado por problemas de entrega que no son suyos.
  • Necesidades de infraestructura. ¿Almacén de características? ¿Seguimiento de experimentos? ¿Una plataforma de inferencia gestionada? Listarlos con costos aproximados. El CFO prefiere ver una partida de $30,000 USD al año ahora que una sorpresa de $30,000 USD en el Q3.
  • Criterios de cancelación, actualizados. Seis meses de trabajo siempre revelan qué apuestas estaban equivocadas. Codifique cuándo se detendrá, no solo cuándo comenzará.

La Conversación en la que el CFO Pregunta sobre el ROI

Esta conversación va a ocurrir. Probablemente en la semana 5 o 6. Suele sonar así: "¿Cuándo empezamos a ver retornos de la inversión en AI?"

Las respuestas incorrectas: "Es una inversión a largo plazo." "La AI toma tiempo." "Todavía estamos en la fase de experimentación." Todas son verdaderas. Ninguna funciona. El CFO está haciendo una pregunta legítima y merece una respuesta legítima.

La respuesta que funciona:

"Ahora mismo estoy en modo auditoría. Encontré dos modelos que nos cuestan aproximadamente $X al mes y no impulsan ninguna decisión, y los voy a retirar para fin de mes. Para el día 90 seré dueño de la métrica de churn en SMB y tendré un roadmap con dos o tres apuestas, cada una vinculada a una métrica de negocio que usted ya rastrea, cada una con un criterio de cancelación. La respuesta honesta a 'cuándo vemos retornos' es: para finales del Q3 si tengo razón, y lo sabremos con suficiente anticipación para redirigir si me equivoco."

Ese es el encuadre. Acciones concretas a corto plazo, una métrica de la que será dueño, una fecha y un plan para fallar rápido si las apuestas no funcionan. Los CFOs responden bien a los criterios de cancelación porque nunca han escuchado a un Data Scientist mencionarlos antes.

Errores Comunes que Hundirán Silenciosamente los Primeros 90 Días

Algunas trampas que atrapan incluso a Data Scientists experimentados:

  • Construir en la semana dos para "parecer productivo". Heredará la culpa de ese modelo para siempre. Resista.
  • Decir sí a solicitudes de "una AI" sin definir la decisión real. Cuando un VP dice "¿podemos usar AI para [cosa vaga]?", la respuesta correcta es "¿qué decisión tomaría de manera diferente con el resultado?" Si no pueden responder, el proyecto aún no existe. No se ofrezca a construirlo de todas formas. (Cómo definir solicitudes vagas de AI profundiza en esto.)
  • Heredar el modelo de churn defectuoso como su KPI. El modelo es una herramienta. La retención es la métrica. Sea dueño de la métrica.
  • Ignorar el costo del trabajo de ingeniería de datos. El 60% de su tiempo en el primer año irá a plomería de datos: arreglar Pipelines, depurar joins, validar que el número del almacén coincida con el número de la herramienta de BI. Preséntelo en el presupuesto. No pretenda que será el 20%.

Cómo Medir el Éxito en el Día 90

La prueba honesta de un primer exitoso 90 días no es "¿desplegó un modelo?". Es:

  • Puede nombrar las tres principales métricas de negocio y qué modelos tocan cada una
  • Un modelo defectuoso está eliminado, con registro documentado
  • Un análisis de resultado rápido fue desplegado y obtuvo reconocimiento del solicitante
  • Es dueño de una métrica, no de cinco
  • El ejecutivo que lo contrató puede describir su roadmap en una oración

Si esas cinco cosas son verdaderas en el día 91, está en posición para un año sólido. Los Data Scientists que se agotan para el mes nueve casi siempre construyeron un modelo nuevo en el mes uno y pasaron los siguientes ocho meses defendiéndolo.

Aprenda Más