--- title: "7.5.1 Roles del quant: del research a producción" description: "Quant researcher, developer, trader, data engineer, risk quant y ML engineer: qué hace cada uno, con qué herramientas y qué partes del curso lo preparan." url: "https://pythonparatrading.com/curso-python-trading/nivel-7/roles-del-quant/" lang: "es" image: "https://pythonparatrading.com/og/curso-python-trading/nivel-7/roles-del-quant.png" --- # 7.5.1 · Roles del quant: seis oficios alrededor de un mismo sistema > «Quant» no es un puesto, es una familia. La misma estrategia pasa por quien consigue y limpia los datos, quien encuentra la señal, quien la convierte en un sistema, quien la opera, quien vigila su riesgo y quien mantiene los modelos en producción. Esta lección describe los seis roles, los cruza con el temario en una matriz que se puede ejecutar y simula cómo se reparte su jornada. - Curso: [Nivel 7: Producción, MLOps, regulación, carrera y capstone](https://pythonparatrading.com/curso-python-trading/nivel-7/) - Módulo: 7.5 · Carrera profesional quant - Duración: 45 min - Requisitos: [2.2.4 · Diario de investigación y registro de experimentos contra el data snooping](https://pythonparatrading.com/curso-python-trading/nivel-2/diario-de-investigacion-y-registro-de-experimentos/), [4.5.1 · Arquitectura de un sistema en vivo: de los datos a la reconciliación](https://pythonparatrading.com/curso-python-trading/nivel-4/arquitectura-de-un-sistema-en-vivo/) ## Al terminar esta lección - Distinguir las responsabilidades, los entregables y las herramientas de quant researcher, quant developer, quant trader, data engineer, risk quant y ML engineer. - Situar cada rol en los módulos del curso con una matriz de competencias explícita y discutible. - Medir con código la distancia entre una autoevaluación y lo que pide cada rol, y convertirla en una lista de lecciones que repasar. - Modelar la jornada de un rol como una máquina de estados y un proceso de interrupciones, y razonar sobre el tiempo de foco que deja. ## Un mismo sistema, seis oficios Un sistema de trading sistemático es una cadena: datos que entran, una señal que se investiga, un programa que la ejecuta, una persona que lo opera, unos límites que lo contienen y, si hay modelos de machine learning, un ciclo que los reentrena y los vigila. En una firma grande, cada eslabón tiene su equipo; en una pequeña, o para un trader independiente, una sola persona hace varios. Saber qué eslabón se ocupa en cada momento ayuda a decidir qué aprender, qué delegar y a qué puestos optar. ```mermaid flowchart TB DE[Data engineer] --> QR[Quant researcher] QR --> QD[Quant developer] ML[ML engineer] --> QD QD --> QT[Quant trader] RQ[Risk quant] --> QT QT --> QR ``` La flecha de vuelta, del trader al researcher, es la que más se olvida: lo que se observa en real (costes, fills, deriva) vuelve a la investigación. Los nombres son los habituales en el sector, pero no están normalizados: el mismo trabajo puede llamarse *quantitative analyst*, *strategist*, *research engineer* o *portfolio analyst* según la firma. Por eso esta lección define cada rol por sus entregables y no por el título. Una referencia pública para las tareas es O*NET, la base de ocupaciones del Departamento de Trabajo de EE. UU. Su ficha *Financial Quantitative Analysts* (13-2099.01) recoge 21 tareas, entre ellas «aplicar técnicas matemáticas o estadísticas a problemas prácticos de finanzas, como la valoración de derivados, la negociación de valores, la gestión del riesgo o la regulación», «desarrollar librerías de modelos» y «dar soporte analítico a researchers o traders»; entre los títulos que la ficha cita como reportados figuran *Quantitative Analyst*, *Quantitative Research Analyst* y *Portfolio Manager*. La de *Financial Risk Specialists* (13-2054.00) incluye «diseñar análisis de escenarios con eventos de mercado severos» y «contribuir al desarrollo de sistemas de gestión del riesgo»[^1]. Son descripciones del mercado laboral de EE. UU., útiles como vocabulario; no son un estándar europeo ni una garantía de lo que pide cada oferta. ## Qué hace cada rol | Rol | Entregable | Herramientas típicas | Módulos del curso | |---|---|---|---| | Quant researcher | Hipótesis probada, informe y prototipo reproducible | pandas, Polars, statsmodels, scikit-learn, notebooks, registro de experimentos | 0.7, 2.1–2.6, 4.1, 5 | | Quant developer | Sistema en producción: datos en vivo, órdenes, estado, pruebas | Python tipado, pytest, asyncio, APIs de bróker, NautilusTrader o LEAN, Docker | 2.4, 4.4, 4.5, 7.1, 7.2 | | Quant trader | Operativa diaria, ejecución y decisiones dentro de límites | Plataforma del bróker, monitores, informes de ejecución, griegas | 1.1, 3, 4.2, 4.3 | | Data engineer | Datos limpios, versionados y a tiempo | Parquet, DuckDB, orquestadores, colas, validación de esquemas | 1.3, 1.4, 6.6, 7.2 | | Risk quant | Medidas, límites, escenarios de estrés y controles | VaR y ES, stress testing, valoración de derivados, informes | 3.4, 4.2, 7.4 | | ML engineer | Modelos servidos, vigilados y reentrenables | scikit-learn, PyTorch, MLflow, ONNX, monitorización de deriva | 5, 6, 7.3 | - **Quant researcher.** Formula hipótesis de ventaja (lección 2.2.1), las contrasta con datos y estadística honesta y descarta la mayoría. Su riesgo profesional es el sobreajuste, y sus herramientas para combatirlo son las del módulo 2.5. Un buen researcher deja un rastro que otro puede reproducir: diario, datos versionados y código (2.2.4). - **Quant developer.** Convierte el prototipo en un sistema que no se cae, o que se cae de forma controlada: estados de órdenes, reconexiones, idempotencia y conciliación (4.5), estructura de proyecto, pruebas y rendimiento (7.1), despliegue (7.2). Su riesgo es el error silencioso: la orden duplicada o el dato desfasado que nadie ve. - **Quant trader.** Opera el sistema y decide dentro de límites: cuándo pausar, cómo ejecutar órdenes grandes (4.3), qué hacer ante un evento que el modelo no conoce. En estrategias de opciones o de futuros gestiona griegas y roll (módulos 3.1 y 3.5). Es quien primero ve que algo no cuadra. - **Data engineer.** Construye y mantiene los flujos de datos: descarga con reintentos, limpieza, ajustes por eventos corporativos, universos sin sesgo de supervivencia y almacenamiento eficiente (1.4), a escala cuando hace falta (6.6). Su trabajo es invisible cuando funciona. - **Risk quant.** Mide y limita: VaR y Expected Shortfall con su backtesting, estrés por correlación y liquidez, riesgo de derivados (4.2), valoración independiente (3.4). En una firma regulada traduce las exigencias normativas en controles (7.4). - **ML engineer.** Lleva modelos a producción y los mantiene sanos: registro de experimentos y de modelos, reentrenamiento con validación, champion/challenger, vigilancia de la deriva y servicio eficiente (7.3), con la base de validación financiera del nivel 5. ## La matriz de competencias La tabla anterior se puede convertir en datos. La matriz siguiente asigna a cada bloque del temario un peso por rol: 0 si es ajeno al puesto, 1 si es útil, 2 si es importante y 3 si es núcleo. Es una valoración del curso, no una encuesta: está escrita para que se pueda discutir y cambiar, y el código que la usa no depende de los números concretos. ```python import pandas as pd ROLES = ["researcher", "developer", "trader", "data_eng", "risk", "ml_eng"] # 0 = ajeno, 1 = útil, 2 = importante, 3 = núcleo del puesto MATRIZ = pd.DataFrame.from_records([ # competencia, módulos del curso, pesos por rol (orden de ROLES) ("Estadística y econometría", "0.7 2.1", 3, 1, 2, 1, 3, 2), ("Backtesting y validación", "2.4 2.5", 3, 2, 2, 0, 2, 2), ("Derivados y valoración", "3.4 3.5", 2, 1, 3, 0, 3, 0), ("Carteras y riesgo", "4.1 4.2", 2, 1, 3, 0, 3, 1), ("Microestructura y ejecución", "1.1 4.3", 1, 2, 3, 1, 1, 0), ("Datos y pipelines", "1.4 6.6", 2, 2, 1, 3, 1, 2), ("Sistemas en vivo", "4.4 4.5", 0, 3, 2, 1, 1, 1), ("Machine learning", "5.1 5.4", 2, 1, 1, 1, 1, 3), ("LLMs y datos alternativos", "6.2 6.7", 1, 1, 0, 2, 0, 2), ("Ingeniería de software", "7.1 7.2", 1, 3, 1, 3, 1, 3), ("MLOps", "7.3", 0, 2, 0, 2, 0, 3), ("Regulación y ética", "7.4", 1, 1, 2, 1, 3, 1), ], columns=["competencia", "modulos", *ROLES]).set_index("competencia") print(MATRIZ[ROLES].sum().rename("suma de pesos").to_string()) ``` ```output researcher 18 developer 20 trader 20 data_eng 15 risk 19 ml_eng 20 ``` La figura de la cabecera dibuja la misma matriz: cada cuadrado es un peso, y el tamaño, su valor. La suma de pesos indica la amplitud de cada rol. El data engineer es el más concentrado (15); el developer, el trader y el ML engineer, los más amplios (20). Las competencias núcleo de cada uno: ```python for rol in ROLES: print(rol) for competencia in MATRIZ.index[MATRIZ[rol] == 3]: print(" -", competencia) ``` ```output researcher - Estadística y econometría - Backtesting y validación developer - Sistemas en vivo - Ingeniería de software trader - Derivados y valoración - Carteras y riesgo - Microestructura y ejecución data_eng - Datos y pipelines - Ingeniería de software risk - Estadística y econometría - Derivados y valoración - Carteras y riesgo - Regulación y ética ml_eng - Machine learning - Ingeniería de software - MLOps ``` Dos lecturas de la matriz. La ingeniería de software es núcleo para tres roles (developer, data engineer y ML engineer) y no es ajena a ninguno: el código es el medio de trabajo de todos. Y la regulación solo es núcleo para el risk quant, la celda en ámbar de la figura, aunque nadie pueda ignorarla: un bot mal diseñado puede incurrir en manipulación de mercado (lección 7.4.5), y eso afecta a quien lo programa y a quien lo opera. ## Autoevaluación y brecha Con la matriz, una autoevaluación con la misma escala (0 a 3) se convierte en una cobertura por rol: la parte de lo que pide el rol que ya se tiene, ponderada por el peso. Saber más de lo que se pide no compensa lo que falta en otra competencia, así que lo que excede se recorta. $$ \text{cobertura}_r = \frac{\sum_c \min(\text{tengo}_c, \text{pide}_{c,r})}{\sum_c \text{pide}_{c,r}} $$ ```python # Autoevaluación de ejemplo, de 0 (nada) a 3 (lo domino) YO = pd.Series({ "Estadística y econometría": 2, "Backtesting y validación": 3, "Derivados y valoración": 1, "Carteras y riesgo": 2, "Microestructura y ejecución": 1, "Datos y pipelines": 2, "Sistemas en vivo": 1, "Machine learning": 2, "LLMs y datos alternativos": 1, "Ingeniería de software": 2, "MLOps": 0, "Regulación y ética": 1, }) def cobertura(yo, matriz=MATRIZ, roles=ROLES): """Parte cubierta de lo que pide cada rol, ponderada por peso.""" pide = matriz[roles] tengo = pide.clip(upper=yo, axis=0) # lo que sobra no suma return (tengo.sum() / pide.sum()).sort_values(ascending=False) print(cobertura(YO).map("{:.0%}".format).to_string()) ``` ```output researcher 89% developer 70% ml_eng 70% risk 68% data_eng 67% trader 65% ``` El perfil de ejemplo, alguien que ha hecho bien el nivel 2 y a medias los demás, cubre el 89 % de lo que pide el rol de researcher y entre el 65 % y el 70 % del resto. La cobertura no es una nota: con la escala de 0 a 3 y doce competencias es una medida gruesa, buena para ordenar prioridades y mala para comparar personas. Para el rol de developer, la lista concreta: ```python def brecha(rol, yo, matriz=MATRIZ): falta = (matriz[rol] - yo).clip(lower=0) tabla = matriz.loc[falta > 0, ["modulos"]].assign( pide=matriz[rol], tengo=yo, falta=falta) return tabla.sort_values(["falta", "pide"], ascending=False) brecha("developer", YO) ``` ```output modulos pide tengo falta competencia Sistemas en vivo 4.4 4.5 3 1 2 MLOps 7.3 2 0 2 Ingeniería de software 7.1 7.2 3 2 1 Microestructura y ejecución 1.1 4.3 2 1 1 ``` La brecha se lee como un plan: sistemas en vivo (módulos 4.4 y 4.5) y MLOps (7.3) primero, porque faltan dos puntos en cada uno; después ingeniería de software (7.1 y 7.2) y microestructura (1.1 y 4.3). Con los pesos y la autoevaluación en código, el plan se recalcula cada vez que cambian, que es la ventaja sobre una lista mental. ## Un día de trabajo, como modelo Las descripciones de puesto dicen qué se hace, no cómo se reparte el día. Dos modelos sencillos ayudan a pensarlo. El primero describe la sesión de un quant trader como una máquina de estados, igual que el sistema que opera (lección 4.5.1): cada evento solo es válido en ciertos estados. ```mermaid stateDiagram-v2 [*] --> preapertura preapertura --> sesion: datos_ok preapertura --> incidencia: datos_mal sesion --> incidencia: alerta incidencia --> sesion: resuelta incidencia --> cierre: kill_switch sesion --> cierre: fin_mercado cierre --> revision: conciliado revision --> [*]: informe ``` Una bitácora ficticia de un día, con dos alertas resueltas, recorrida por la máquina: ```python from datetime import datetime TRANSICIONES = { ("preapertura", "datos_ok"): "sesion", ("preapertura", "datos_mal"): "incidencia", ("sesion", "alerta"): "incidencia", ("incidencia", "resuelta"): "sesion", ("incidencia", "kill_switch"): "cierre", ("sesion", "fin_mercado"): "cierre", ("cierre", "conciliado"): "revision", ("revision", "informe"): "fuera", } # Bitácora de un día ficticio de un quant trader (hora de Madrid) BITACORA = [ ("08:00", "inicio"), ("08:40", "datos_ok"), ("11:20", "alerta"), ("11:55", "resuelta"), ("15:40", "alerta"), ("15:55", "resuelta"), ("17:35", "fin_mercado"), ("18:05", "conciliado"), ("18:30", "informe"), ] def recorrer(bitacora, transiciones=TRANSICIONES): """Minutos en cada estado; un evento imposible es un error.""" hora = lambda h: datetime.strptime(h, "%H:%M") estado, desde = "preapertura", hora(bitacora[0][0]) minutos = {} for h, evento in bitacora[1:]: nuevo = transiciones.get((estado, evento)) if nuevo is None: raise ValueError(f"{h}: «{evento}» no vale en {estado}") dur = (hora(h) - desde).seconds // 60 minutos[estado] = minutos.get(estado, 0) + dur estado, desde = nuevo, hora(h) return estado, minutos final, minutos = recorrer(BITACORA) print("Estado final:", final) for estado, m in minutos.items(): print(f" {estado:<12}{m:>4} min") ``` ```output Estado final: fuera preapertura 40 min sesion 485 min incidencia 50 min cierre 30 min revision 25 min ``` De 10 horas y media, 50 minutos fueron incidencias y 95 minutos se fueron en preapertura, cierre y revisión: tareas que no aparecen en un backtest y que alguien tiene que hacer cada día. La máquina rechaza una bitácora imposible (una alerta «resuelta» sin estar en incidencia), lo que la hace útil también para auditar registros reales. El segundo modelo mide el tiempo de foco. Cada rol recibe interrupciones (una alerta, una pregunta, un fallo de datos) a un ritmo y con una duración media distintos. Los parámetros son **supuestos**, no datos: el trader recibe muchas interrupciones cortas; el data engineer, pocas y largas; el researcher, pocas. Con 250 días simulados por rol, el modelo cuenta cuántos bloques de 90 minutos sin interrupción quedan entre las 9:00 y las 18:00: ```python import numpy as np # Supuestos del modelo (no son datos): interrupciones por hora y # duración media en minutos, por rol INTERRUPCIONES = {"researcher": (0.3, 15), "developer": (0.6, 25), "trader": (1.5, 10), "data_eng": (0.5, 30), "risk": (0.7, 20), "ml_eng": (0.5, 20)} def simular_dia(tasa, media, rng, inicio=9 * 60, fin=18 * 60): """Minutos de interrupción y bloques de foco de >= 90 minutos.""" t, bloques, perdido = inicio, 0, 0 while True: siguiente = t + rng.exponential(60 / tasa) foco = min(siguiente, fin) - t bloques += int(foco // 90) if siguiente >= fin: return perdido, bloques dura = min(rng.exponential(media), fin - siguiente) perdido += dura t = siguiente + dura rng = np.random.default_rng(7) filas = [] for rol, (tasa, media) in INTERRUPCIONES.items(): dias = [simular_dia(tasa, media, rng) for _ in range(250)] perdido, bloques = np.array(dias).T filas.append((rol, perdido.mean() / 60, bloques.mean(), (bloques == 0).mean())) dia = pd.DataFrame(filas, columns=["rol", "horas_interrumpidas", "bloques_90", "dias_sin_bloque"]) dia.set_index("rol").round(2) ``` ```output horas_interrumpidas bloques_90 dias_sin_bloque rol researcher 0.60 4.06 0.00 developer 1.85 2.64 0.03 trader 1.74 1.12 0.28 data_eng 1.72 3.06 0.02 risk 1.66 2.50 0.03 ml_eng 1.33 3.04 0.00 ``` *Fig. — Bloques de foco de 90 minutos o más por día, por rol, en 250 jornadas simuladas con interrupciones aleatorias (9:00 a 18:00) (esquema).* Barras por rol con la media de bloques de foco de al menos 90 minutos al día: researcher 4,06; developer 2,64; trader 1,12, destacado y el más bajo; data engineer 3,06; risk 2,50; ML engineer 3,04. Las interrupciones por hora y su duración son supuestos del modelo, no datos. El developer y el trader pierden un tiempo parecido (1,85 y 1,74 horas al día), pero el trader conserva 1,12 bloques de foco de media y en el 28 % de los días ninguno; el developer, 2,64. La diferencia está en la frecuencia: muchas interrupciones cortas trocean el día. La consecuencia práctica es de organización, no de carácter: el research profundo de un trader cabe fuera de la sesión, y un developer de guardia necesita guardias rotatorias para que el resto del equipo conserve sus bloques. ## Cómo usar el resto del nivel Los proyectos de capstone del nivel 7 se pueden leer con la misma matriz. C1 (sistema multi-activo de futuros en NautilusTrader) es sobre todo trabajo de developer y trader; C2 (libro de opciones con griegas en tiempo real), de trader y risk quant; C3 (cartera con ML, HRP y fiscalidad), de researcher y ML engineer; C4 (plataforma con LLMs y datos alternativos), de data engineer y ML engineer; C5 (market making o arbitraje en cripto), de developer y trader. Elegir el capstone según el rol al que se aspira convierte el proyecto en una prueba de ese rol, que es lo que pregunta una entrevista (lección 7.5.3). Dos advertencias. La primera: en equipos pequeños los roles se funden, y un perfil con cobertura alta en dos roles contiguos (researcher y developer, o data engineer y ML engineer) es más útil que uno perfecto en uno solo. La segunda: la matriz describe competencias, no valía; la escala de 0 a 3 la rellena cada uno sobre sí mismo, con los sesgos de cualquier autoevaluación. Contrastarla con trabajo publicado (un repositorio, un informe reproducible) es el objeto de la lección 7.5.3. ## Ejercicios 1. Añade a la matriz un rol de **quant de ejecución** (*execution quant*), que diseña algoritmos de ejecución y mide costes, con los pesos que te parezcan razonables, y calcula su cobertura con la autoevaluación de ejemplo. **Solución.** ```python ejec = pd.Series({ "Estadística y econometría": 2, "Backtesting y validación": 1, "Derivados y valoración": 0, "Carteras y riesgo": 1, "Microestructura y ejecución": 3, "Datos y pipelines": 2, "Sistemas en vivo": 3, "Machine learning": 1, "LLMs y datos alternativos": 0, "Ingeniería de software": 2, "MLOps": 1, "Regulación y ética": 2, }) m7 = MATRIZ.assign(ejecucion=ejec) print(cobertura(YO, m7, ROLES + ["ejecucion"]) .map("{:.0%}".format).to_string()) ``` ```output researcher 89% developer 70% ml_eng 70% risk 68% data_eng 67% ejecucion 67% trader 65% ``` Con estos pesos, el rol de ejecución queda entre los de menor cobertura para el perfil de ejemplo, porque concentra el peso en microestructura y sistemas en vivo, justo donde la autoevaluación es más baja. Los pesos son una opinión: lo útil es que, al cambiarlos, la conclusión se recalcula y se puede discutir con números. 2. Un equipo establece guardias rotatorias: el developer de guardia recibe el doble de interrupciones y los demás developers, una de cada cuatro (0,15 por hora). ¿Cuántos bloques de foco ganan los que no están de guardia? **Solución.** ```python rng = np.random.default_rng(11) for nombre, tasa in [("de guardia", 1.2), ("sin guardia", 0.15), ("sin guardias", 0.6)]: dias = np.array([simular_dia(tasa, 25, rng) for _ in range(250)]) print(f"{nombre:<13}{dias[:, 1].mean():>5.2f} bloques de 90 min") ``` ```output de guardia 1.25 bloques de 90 min sin guardia 4.85 bloques de 90 min sin guardias 2.63 bloques de 90 min ``` Quien no está de guardia pasa de 2,63 bloques diarios a 4,85; el de guardia baja a 1,25. Con cuatro developers y una guardia por semana, cada uno tiene tres semanas de cada cuatro con casi el doble de tiempo de foco. El modelo es grosero (interrupciones independientes, duración exponencial), pero el orden de magnitud explica por qué los equipos de producción separan guardia y desarrollo. 3. Elige el rol al que aspiras y escribe, para el capstone que elegirías, tres entregables que demuestren las competencias núcleo de ese rol según la matriz. **Solución.** Un ejemplo para el rol de risk quant con el capstone C2: un informe de VaR y Expected Shortfall del libro de opciones con su backtesting (Kupiec y Christoffersen, lección 4.2.3); un conjunto de escenarios de estrés con saltos de volatilidad y de correlación aplicados a las griegas (4.2.4 y 4.2.6); y una tabla de límites (delta, vega, pérdida diaria) con el control que los aplica antes de cada orden y su registro de incumplimientos. Los tres cubren las competencias núcleo del rol (estadística, derivados, carteras y riesgo, regulación) y se pueden enseñar en una entrevista. [^1]: O*NET OnLine, U.S. Department of Labor, Employment and Training Administration: fichas [13-2099.01 Financial Quantitative Analysts](https://www.onetonline.org/link/summary/13-2099.01), [13-2054.00 Financial Risk Specialists](https://www.onetonline.org/link/summary/13-2054.00) y [15-2051.00 Data Scientists](https://www.onetonline.org/link/summary/15-2051.00) (sitio actualizado el 6/10/2026), consultadas el 23/10/2026. Licencia CC BY 4.0; las citas son traducciones propias. ## Autoevaluación 1. Un modelo de reversión a la media funciona en el backtest, pero hay que llevarlo a un sistema que recibe datos en directo, envía órdenes al bróker y se recupera de una desconexión. ¿Qué rol es el responsable natural de ese paso? - A. El quant researcher, porque el modelo es suyo - B. El risk quant - C. El quant developer: convertir research en software de producción fiable es su núcleo - D. El data engineer *Respuesta C: El quant developer: convertir research en software de producción fiable es su núcleo.* El researcher entrega una especificación y un prototipo; el developer construye el sistema con estados de órdenes, reconexiones, idempotencia y pruebas (módulos 4.4, 4.5 y 7.1). En equipos pequeños pueden ser la misma persona, pero son dos trabajos distintos. 2. En la matriz de la lección, ¿para qué rol es la regulación una competencia núcleo? - A. Para el risk quant - B. Para el quant researcher - C. Para el ML engineer - D. Para ninguno *Respuesta A: Para el risk quant.* Es la celda en ámbar de la figura de la cabecera. El risk quant traduce límites regulatorios e internos en medidas y controles; el resto de roles necesita conocerlos (peso 1 o 2), pero no es su entregable. La matriz es una valoración del curso, no una encuesta del sector. 3. Con la autoevaluación de ejemplo, el rol con mayor cobertura es el de researcher (89 %) y el de developer queda en el 70 %. ¿Qué dice la función `brecha` que hay que repasar primero para el de developer? - A. Estadística y econometría - B. Derivados y valoración - C. Machine learning - D. Sistemas en vivo (4.4 y 4.5) y MLOps (7.3), con dos puntos de diferencia cada uno *Respuesta D: Sistemas en vivo (4.4 y 4.5) y MLOps (7.3), con dos puntos de diferencia cada uno.* `brecha` ordena por lo que falta y, a igualdad, por el peso que pide el rol. Sistemas en vivo es núcleo para el developer (3) y la autoevaluación da 1; MLOps pide 2 y da 0. 4. En la simulación de interrupciones, el trader tiene de media 1,12 bloques de foco de 90 minutos al día y el researcher más de 4, con más o menos las mismas horas interrumpidas que el developer. ¿Qué conclusión es correcta? - A. El trader trabaja menos - B. Lo que destruye el foco es la frecuencia de las interrupciones, no solo su duración total: muchas interrupciones cortas parten el día en trozos inservibles para trabajo profundo - C. La simulación demuestra que el trading no necesita concentración - D. Los números son datos del sector *Respuesta B: Lo que destruye el foco es la frecuencia de las interrupciones, no solo su duración total: muchas interrupciones cortas parten el día en trozos inservibles para trabajo profundo.* Trader y developer pierden un tiempo parecido (unas 1,7 a 1,9 horas), pero el trader recibe 1,5 interrupciones por hora frente a 0,6. Los parámetros son supuestos del modelo, no datos: la lección es el mecanismo, que cada uno puede recalibrar con su propia jornada. ## Ideas clave - Los seis roles trabajan sobre el mismo sistema en eslabones distintos: datos (data engineer), señal (researcher), software (developer), operativa (trader), límites (risk quant) y modelos en producción (ML engineer). - Los títulos cambian de una firma a otra; lo estable son los entregables. O*NET, del Departamento de Trabajo de EE. UU., describe al quant analyst por tareas como aplicar técnicas estadísticas a valoración, trading o riesgo y mantener librerías de modelos. - La matriz de competencias de la lección es una valoración explícita del curso que se puede discutir y cambiar; su valor está en hacer comparables los roles y medir brechas con código. - Con la autoevaluación de ejemplo, la cobertura va del 89 % (researcher) al 65 % (trader), y la brecha del developer apunta a sistemas en vivo y MLOps. - La jornada de cada rol se puede modelar: como máquina de estados (la sesión del trader) o como proceso de interrupciones. Con los supuestos de la lección, el trader conserva 1,1 bloques de foco de 90 minutos al día y el researcher, 4,1. ## Recursos ### Research - [Introducción al Quant Research](https://pythonparatrading.com/quant-research/) · Research-0023 · 8 min ### Documentación - [O*NET OnLine: 13-2099.01 Financial Quantitative Analysts](https://www.onetonline.org/link/summary/13-2099.01) · onetonline.org - [O*NET OnLine: 13-2054.00 Financial Risk Specialists](https://www.onetonline.org/link/summary/13-2054.00) · onetonline.org - [O*NET OnLine: 15-2051.00 Data Scientists](https://www.onetonline.org/link/summary/15-2051.00) · onetonline.org Lección anterior: [7.4.7 · Ética: datos personales, inteligencia artificial y la venta de señales](https://pythonparatrading.com/curso-python-trading/nivel-7/etica-datos-personales-ia-y-senales/) Lección siguiente: [7.5.2 · Dónde trabajar: qué hace cada empresa y qué dicen los registros](https://pythonparatrading.com/curso-python-trading/nivel-7/donde-trabajar-ecosistema-espana-y-europa/)