E23 - Cómo crear un equipo de Analytics

Resumen

El episodio plantea cómo construir un equipo de analytics/Data Science desde cero, según el tamaño de la empresa (pequeña, mediana, grande) y su madurez en datos (baja, media, alta). Primero se definen los roles: Data Scientist, Data Engineer, MLOps/ML Engineer, Data Analyst, Business Analyst, Data Translator, Data Architect, Data Visualization Developer, Citizen Data Scientist y líder. Los panelistas critican varios de ellos (Data Translator, Citizen Data Scientist) y coinciden en que el Data Scientist suele ser el "maestro chasquilla" que hace de todo. Después recorren la matriz tamaño × madurez. La base común es Data Engineer (con perfil de Data Architect), Data Scientist y Data Analyst, y el MLOps Engineer se suma cuando hay casos de uso que escalar. La conclusión principal es que el Data Architect/Engineer es esencial desde el inicio aunque no dé valor inmediato, y que todo depende del contexto, el presupuesto y la necesidad de corto plazo de la empresa. También discuten equipos centralizados vs. descentralizados y la importancia de tener pares o mentores.

Capítulos

• 00:00
  IntroSe plantea el ejercicio de armar un equipo de Data Science desde cero y se discuten las condiciones previas: no todo negocio necesita Data Science de inmediato y influye la digitalización. Se define empresa mediana como cerca de 900 millones de pesos anuales (unos 70 millones mensuales) y se menciona que una empresa pequeña parte con un solo Data Scientist senior que hace todo (un "chief analytics"). Se acuerda usar una matriz de tamaño y madurez.
• 08:28
  RolesSe enumeran los roles a revisar (Data Scientist, Data Analyst, Data Engineer, ML Engineer, Citizen Data Scientist, Business Analyst, Data Translator, Data Visualization Developer). Se dice que quien arma el equipo debe conocer los roles; la visión de cada rol se explica en los capítulos siguientes.
• 11:18
  Data ScientistLo definen como el "maestro chasquilla" que hace de todo. Idealmente es quien usa el método científico para crear productos analíticos (modelos, recomendadores). Uno de ellos opina que el rol debería dejar de existir como tal.
• 14:45
  Data EngineerSe explica como el que hace ETL (extract, transform, load): toma los datos y los deja disponibles para que otros los exploten.
• 14:55
  MLOpsE y diferencia con MLEEl MLOps Engineer productiviza los modelos y asegura que la operación funcione; el ML Engineer es especialista en modelos de Machine Learning (teoría, hiperparámetros). En la práctica se suelen mezclar y, con pocos recursos, se juntan en una persona.
• 16:44
  Data AnalystHace análisis exploratorio, reportes automáticos e insights de negocio, a veces con algo predictivo simple. Se comenta que un Data Engineer haciendo un modelo lo hará peor que un Data Scientist haciendo un ETL (menos óptimo, pero llegará a algo), y que hoy los roles se solapan por la formación.
• 19:05
  Business AnalystSe describe como quien viene del negocio, plantea los dolores y saca KPIs de negocio. Se considera muy cercano al Data Analyst y varios lo juntarían en un solo rol con conocimiento de negocio. Se menciona una "ley" sobre cómo la comunicación se complica al aumentar el tamaño del equipo.
• 23:01
  Data TranslatorEs el puente entre negocio y el equipo de datos. Los tres lo critican: debería ser una habilidad de todos y no un rol, porque en la traducción (como en el teléfono) se pierde información. Se nota que falta el líder.
• 24:48
  Data ArchitectSe cita la definición del libro de O'Reilly sobre ingeniería de datos: diseño de un sistema que soporta las necesidades evolutivas de datos de la empresa, con flexibilidad, reversibilidad y trade-offs. Sostienen que debería ser de los primeros roles que se contraten, porque sin datos ordenados los Data Scientists pierden meses limpiando.
• 28:40
  Data Visualizations DevelopperSe ve como alguien con perfil de diseño gráfico de datos (infografías, uso de colores) útil cuando el equipo ya está consolidado y hay que comunicar resultados a un público amplio.
• 31:27
  Citizen Data ScientistPersona sin conocimiento técnico profundo que usa herramientas como H2O, SageMaker o cajitas de arrastrar para hacer análisis. Las herramientas les parecen útiles, pero no el rol: debería haber supervisión y conocimientos básicos (por ejemplo train/test), y a futuro el análisis de datos podría ser tan básico como leer y escribir.
• 36:16
  LíderRol de gestión; no es necesario que sea experto técnico pero sí que entienda lo básico para dimensionar tiempos y comunicarse con el equipo. Será quien venda los productos al resto de la compañía y priorice.
• 40:28
  MemesMemes sobre el Data Engineer como "Superman" que salva con los datos, ofertas de LinkedIn que piden de todo para posiciones junior, el Data Scientist como maestro chasquilla y la gente que cree que el equipo de analytics sabe dónde están todos los datos.
• 45:40
  Cómo comenzaríamos un equipo dependiendo del tamaño y madurez de datosSe propone una matriz de tamaño (pequeña, mediana, grande) por madurez (baja, media, alta), donde la madurez va de 1 a 5 según qué tan data driven es la empresa.
• 48:30
  Empresa pequeña, baja madurezSe debate partir con un Data Architect, aunque es difícil de vender por no generar dinero al inicio. Proponen un Data Engineer con perfil de arquitecto y de negocio, o la base de tres roles (Data Engineer/Architect, Data Scientist, Data Analyst). En una empresa de siete personas sería un solo Data Scientist que hace de todo; también se propone un solo perfil Data Engineer + Analyst.
• 55:40
  Empresa mediana, baja madurezSe recomienda contratar según la necesidad inmediata: tras el Data Engineer, puede ser un Data Analyst para reportes y "vender el área", o un Data Scientist si hay un modelo urgente. Se sugiere un perfil con dos roles a la vez.
• 01:00:30
  Empresa grande, baja madurezSe discute un equipo de dos Data Architects, un Data Engineer y un Data Analyst, y se rechazan Citizen y Translator.
• 01:04:08
  Empresa pequeña, media madurezUn Data Engineer que combine funciones, con alguien que haga también de Analyst.
• 01:04:53
  Empresa mediana, media madurezYa están las bases y se necesita al menos un Data Scientist (quizás dos), manteniendo al Data Engineer; el Data Scientist debe tener rol de business analyst. Se desechan Translator y Citizen Data Scientist, y se deja el Data Visualization Developer solo para empresas grandes de madurez alta como última prioridad (o si el negocio depende de gráficos para el usuario final). En este tramo se abre una discusión sobre equipos centralizados vs. descentralizados y sobre por qué el Data Scientist necesita mentores y pares (formación continua, área en constante cambio, rol transversal).
• 01:22:42
  Empresa grande, media madurezMantienen el Data Architect por la evolución de la infraestructura y el Data Analyst, y agregan un segundo Data Scientist y un MLOps Engineer a los 6 meses o al primer año para productivizar modelos.
• 01:23:59
  Empresa pequeña, alta madurezEs raro pero posible (por ejemplo, tres expertos fundadores); se mantiene el equipo mínimo y no se cambia mucho.
• 01:25:03
  Empresa mediana, alta madurezSe suma un MLOps Engineer dedicado, justificado porque los casos de uso ya generan valor y hay que productivizarlos.
• 01:26:17
  Empresa grande, alta madurezSe repite el equipo de grande/madurez media, con un Data Scientist extra, y el MLOps Engineer desde el inicio; se escala según los casos de negocio.
• 01:27:25
  ProporciónSe concluye que no hay una proporción correcta y depende del contexto. Reconocen que partieron con puros Data Scientists, lo que fue un error, y que a veces en la empresa ya hay gente con las habilidades fuera del equipo de analytics.
• 01:30:54
  Gobierno del DatoMencionan que faltó el rol de gobierno/seguridad del dato, que será más importante cuando las leyes avancen.
• 01:32:43
  CierreConclusiones: el Data Engineer/Architect es esencial desde el comienzo aunque no dé valor instantáneo; hay que ser realista y asumir que en empresas chicas se hace un poco de todo; el equipo genérico de tres roles (Data Engineer, Analyst, Scientist) es una buena respuesta estándar; y todo depende del contexto y de la necesidad de corto plazo.

Palabras clave