Bienvenido a TaskFlow

### Lunes, 7:50 AM - Segundo acto

El metro de Madrid huele a café y a lunes. Miras el móvil por tercera vez en cinco minutos: la notificación de Slack de TaskFlow sigue ahí, sin abrir. "Bienvenido/a al workspace de TaskFlow". Sonríes. Han pasado exactamente 6 meses y 11 días desde tu primer lunes en FreshMart. Aquel día temblabas. Hoy sientes algo diferente: no es miedo, es anticipación.

FreshMart te transformó. Entraste sin saber qué era una zona raw y saliste montando pipelines de ingesta, discutiendo granularidad con Jorge, y gestionando los CSVs caóticos de María sin pestañear. Elena te enseñó que la calidad del dato es sagrada. Raúl te enseñó que el código que "más o menos funciona" es una bomba de relojería. Y María -- con sus archivos FINAL_v3_BUENO.csv -- te enseñó que los stakeholders tienen urgencias reales y que tu trabajo es servirles sin sacrificar la verdad de los datos.

Pero FreshMart era retail: transacciones, inventario, campañas. Datos que se crean cuando alguien compra algo. Predecibles. Aquí vas a trabajar con COMPORTAMIENTO: qué hacen los usuarios dentro de un producto digital, cuánto tiempo se quedan, qué botones tocan antes de irse para siempre. Es un mundo diferente. Y te emociona.

Un headhunter te contactó por LinkedIn hace 3 semanas. Vio tu perfil actualizado -- "Junior Data Engineer con experiencia en pipelines de ingesta, limpieza de datos con Pandas, modelado dimensional y code reviews" -- y te escribió: "Tengo una oportunidad que encaja contigo. SaaS, equipo pequeño, reto de retención interesante." La entrevista fue con Pablo (tu futuro jefe) y Marcos (senior del equipo). Te preguntaron sobre pipelines, deduplicación de datos, window functions en SQL, y cómo gestionarías una petición urgente de un stakeholder. Les gustó que hablaras de "alinear definiciones antes de construir tablas" como algo natural.

Dos semanas después firmaste. Hoy, lunes a las 8:00 de la mañana, abres la puerta de una oficina en el centro de Madrid. Tercer piso, luz natural, mesas de madera clara, monitores ultrawide. Un cartel en la pared dice "Ship fast, measure everything". Sales del ascensor y un tío alto con camiseta de Spotify te saluda desde la cocina: "Ey, tú eres el nuevo de datos, no? Soy Marcos. Hazte un café y te veo en la sala de reunión a las 9."

### TaskFlow - La empresa

TaskFlow es una herramienta de gestión de proyectos online fundada en Madrid en 2021. Tres ex-ingenieros de Notion y Asana (dos españoles y un portugués) tuvieron una idea: "Notion es demasiado flexible -- te puedes pasar una semana configurándolo. Asana es demasiado rígida -- cuando tu equipo no encaja en su modelo, sufres. Nosotros somos el punto medio: opinionado pero adaptable." Lanzaron la beta en septiembre de 2021, encontraron product-market fit a principios de 2022 (de 1.000 a 10.000 usuarios en 3 meses gracias a un hilo viral en Twitter) y cerraron una Serie A de 8M euros en junio de 2022.

Hoy TaskFlow tiene ~80 empleados repartidos entre producto, ingeniería, ventas y soporte. Su producto permite a equipos organizar trabajo en boards (tipo Kanban), con tareas, subtareas, assignees, fechas límite, automatizaciones y un chat integrado por tarea. El 60% de los usuarios usan la versión gratuita (hasta 5 miembros por workspace). El 40% paga: Plan Pro a 9 euros/usuario/mes o Plan Business a 19 euros/usuario/mes.

• ▹Usuarios activos mensuales (MAU): ~50.000
• ▹Workspaces (equipos/empresas): ~8.200
• ▹Eventos de producto por día: ~2.5 millones
• ▹ARR (Annual Recurring Revenue): ~4.2M euros
• ▹NRR (Net Revenue Retention): 108% -- los que pagan, pagan más cada año
• ▹Retención a 30 días: 61% (era 68% hace 3 meses) -- ESTE es el problema
• ▹Stack del producto: Django + PostgreSQL 14 + React + Kafka + Redis
• ▹Equipo de datos: creado hace 8 meses. Tú eres el cuarto miembro.

### La fase actual: retención o muerte

TaskFlow sabe adquirir usuarios. El funnel de captación funciona: SEO, contenido, producto freemium, boca a boca. Cada mes entran ~3.000 workspaces nuevos. El problema es que muchos se van después del primer mes. La retención a 30 días cayó de 68% en enero a 61% en marzo. En SaaS, eso es una emergencia silenciosa. Si no la frenas, da igual cuántos usuarios captes -- el balde tiene un agujero.

Andrés López (CTO y cofundador) creó el equipo de datos hace 8 meses para responder una pregunta: "Por qué se van los usuarios y cómo lo frenamos?" Contrató a Pablo como PM de datos, a Sandra como analytics engineer, y a Marcos como senior data engineer hace 4 meses. Tú eres la cuarta pieza: el data engineer que va a construir la infraestructura de eventos que Sandra necesita para sus modelos y que Lucía (Product) necesita para tomar decisiones.

### El stack técnico de datos

• ▹App backend: Django + PostgreSQL 14 (RDS) -- estable, bien testeado
• ▹Eventos de producto: Kafka (MSK) -> S3 (JSON Lines particionados por fecha)
• ▹Data Warehouse: Amazon Redshift -- tablas de suscripciones y usuarios. SIN eventos.
• ▹Transformaciones: dbt Core (Sandra lo gestiona) -- 23 modelos bien documentados
• ▹BI: Looker -- 12 dashboards, la mayoría de métricas financieras
• ▹Data Lake: S3 (raw events particionados) -- 6 meses de histórico sin explotar
• ▹Procesamiento: Spark (EMR) -- Sandra lo probó una vez y dijo "es mucho para mí"
• ▹Lenguajes: Python 3.11, SQL -- estandar del equipo
• ▹Repo: GitHub (taskflow-data) -- PRs obligatorios, CI con tests básicos

### Los problemas que vas a resolver esta semana

1. 01.Eventos sin explotar: Kafka lleva 6 meses emitiendo eventos pero nadie los ha metido en el warehouse.
2. 02.Sin cohortes reales: la "retención" actual es un conteo mensual de MAUs. No hay análisis de cohortes por semana de signup.
3. 03.Datos desconectados: suscripciones (quién paga) en Redshift. Eventos (qué hacen) en S3. No hay JOIN entre ambos.
4. 04.Tracking con bugs: David (backend) implementó el tracking rápido. Hay duplicados, timestamps incorrectos y eventos mal definidos.
5. 05.Churn sin explicación: saben QUE se van los usuarios pero no POR QUE.
6. 06.Sin alertas de calidad: el mes pasado Kafka estuvo 3 días sin emitir board_viewed y nadie se enteró.

### Tu equipo -- las personas con las que vas a trabajar

### Pablo Herrera - PM de Datos (tu jefe directo)

Pablo tiene 36 años. Antes de TaskFlow fue Product Manager en Typeform durante 4 años (donde aprendió que los datos de producto son oro) y luego Head of Analytics en una startup de HR-tech que cerró (donde aprendió que sin datos fiables una empresa muere). Entró en TaskFlow hace 10 meses para construir el equipo de datos desde cero.

Personalidad: organizado hasta el extremo. Documenta TODO en Notion -- tiene una página por proyecto con objetivos, timeline, definiciones de métricas y decisiones tomadas. A veces sobre-documenta: pasas más tiempo describiendo lo que vas a hacer que haciéndolo. Pero eso es mejor que el caos de "nadie sabe qué estamos haciendo". Protege al equipo del ruido exterior: filtra las peticiones de producto, prioriza por impacto y dice "no" a cosas que no son prioritarias aunque el stakeholder insista.

Cómo comunica: siempre con estructura. Un mensaje de Pablo empieza con el contexto ("esto viene porque Lucía necesita X para la board review del jueves"), sigue con el problema ("no tenemos datos de eventos en el warehouse") y termina con lo que espera de ti ("necesito que esta semana tengas la tabla de cohortes lista"). Nunca te manda un "ey, puedes hacer una cosa?" sin explicar el por qué. Su emoji favorito es el ??.

Frase típica: "Antes de ponerte a codear, asegúrate de que entiendes qué pregunta de negocio estamos respondiendo."

### Sandra Vidal - Analytics Engineer (tu aliada)

Sandra tiene 32 años. Estudió Estadística en la Complutense, hizo un máster en Business Analytics y trabajó 3 años como analista en Cabify. Allí descubrió dbt y se obsesionó: "Es la primera herramienta que trata SQL como código de verdad -- con tests, documentación y versionado." Lleva 8 meses en TaskFlow y es la persona de referencia para todo lo que es modelado de datos.

Personalidad: detallista, estructurada, amable pero firme. Para ella un NULL sin documentar es un pecado mortal. Una columna sin descripción en el schema.yml de dbt es un crimen. Tiene un documento de "Convenciones de nomenclatura" de 14 páginas que espera que leas tu primer día. Nombres de columnas siempre en snake_case con prefijo de la entidad (user_created_at, no created_at). Los modelos de dbt siguen la convención stg_ -> int_ -> fct_ / dim_. Si le mandas un PR con una columna llamada "data" o "info", te lo devuelve con un comentario educado pero inequívoco.

Cuando te explica algo, dibuja en Miro. Tiene un tablero con el modelo de datos completo de TaskFlow y lo actualiza cada semana. Es tu aliada natural: ella sabe DONDE están las cosas y tú sabes COMO moverlas. Juntos sois el equipo que TaskFlow necesita. Su emoji favorito es ??.

Frase típica: "Cómo has definido usuario activo? Porque si no lo alineamos con lo que usa producto, vamos a tener dos números distintos para lo mismo."

### Marcos Delgado - Senior Data Engineer (tu tech lead informal)

Marcos tiene 35 años. 8 años de experiencia. Ex-Spotify (data platform team, 3 años construyendo pipelines a escala planetaria), ex-Glovo (real-time pipelines para delivery, 2 años). Entró en TaskFlow hace 4 meses para liderar la parte de ingeniería de datos.

Personalidad: RELAJADO. Senior de verdad -- no necesita demostrar nada. Responde en Slack con 2-3 palabras pero si le preguntas en persona te da 20 minutos de contexto con diagramas en la pizarra. Prefiere calls de 5 minutos a threads de 30 mensajes. Te da autonomía pero está disponible si te atascas. Piensa en SISTEMAS, no en scripts: "Si tu pipeline se rompe porque un campo cambió de nombre, tu pipeline está mal diseñado."

Odia los pipelines frágiles. Insiste en idempotencia ("si lo ejecutas 2 veces, el resultado es el mismo"). Le gusta que le digas "estoy atascado" temprano, no el viernes a las 18:00. En standups dice poco pero siempre pregunta algo que nadie había pensado. No usa emojis. Nunca.

Frase típica: "Antes de optimizar, asegúrate de que funciona. Antes de que funcione, asegúrate de que entiendes el problema."

### Lucía Fernández - Product Manager (stakeholder principal)

Lucía tiene 30 años. Trabajó en UX Research en Figma (2 años), luego fue PM en una startup de e-learning. En TaskFlow desde el principio -- empleada número 12. Conoce el producto mejor que nadie.

Personalidad: RAPIDA. Lista, enfocada en el usuario, impaciente con los tiempos pero razonable si le explicas por qué. Piensa en voz alta -- a veces te dice lo que necesita antes de haberlo pensado del todo. Sus mensajes de Slack empiezan SIEMPRE con "Ey," seguido de lo que necesita. Urgente pero no irrespetuosa: si le dices "eso me lleva 3 días porque necesito X" ella responde "ok, entiendo, para cuándo entonces?". El problema es cuando no le explicas y solo dices "no puedo" -- ahí se frustra.

Hace preguntas que parecen simples pero son complejas: "Qué porcentaje de usuarios usa boards vs listas?" (parece un COUNT pero implica definir qué es un usuario, qué es "usar", y cómo manejas los que usan ambos). Cambia la pregunta cuando ve los primeros datos: "Ah, pero y si lo segmentamos por plan?" No entiende por qué "solo un número" puede llevar 2 días. Su emoji favorito es ??.

Frase típica: "No necesito que sea perfecto, necesito una primera aproximación para el jueves. Si luego hay que refinar, refinamos."

### David Martin - Backend Engineer (dueño del tracking)

David tiene 28 años. Ingeniero informático, 3 años en TaskFlow. Construyó el sistema de eventos cuando le pidieron "meter analytics al producto". Lo hizo solo, en 2 semanas, sin especificación formal. Es uno de los mejores ingenieros de backend de la empresa pero el tracking fue un side-project que hizo rápido entre otras prioridades.

Personalidad: técnico puro. Documenta en comments del código, no en documentos externos. Si le preguntas algo te manda un snippet de código como respuesta. Honesto con los bugs: cuando le señalarás un problema diré "sí, eso está mal, fue un hack que hice rápido". Colaborador pero ocupado -- el equipo de backend tiene sus propias prioridades y David no puede dejarlo todo para arreglar tracking.

Su definición de "funciona" es "Kafka recibe el evento y no se cae". La semántica del evento (qué significa exactamente task_updated? incluye cambios de asignación?) te la tiene que explicar de memoria porque no está documentada en ningún sitio. Prefiere 5 minutos de call a 20 mensajes. No usa emojis.

Frase típica: "El evento se emite cuando se llama a save() en el modelo. Si hay duplicados es porque el retry del producer está a 3. Puedo bajarlo a 1 pero perdemos fiabilidad."

### Las dinámicas del equipo

• ▹Pablo y Lucía: buena relación profesional. Pablo filtra las peticiones de Lucía para que no bombardeen al equipo. A veces Lucía intenta saltarse a Pablo y hablarte directamente -- Pablo lo tolera pero prefiere enterarse.
• ▹Sandra y tú: tu aliada natural. Ella conoce el modelo de datos, tú la ingeniería. Os necesitáis mutuamente. Sandra te va a enseñar cómo están las tablas en dbt y tú le vas a alimentar los eventos que ella necesita.
• ▹David y el equipo de datos: colaborador pero vive en otro mundo. Cuando le pides algo tarda 1-2 días porque tiene sus propias prioridades. No es mala voluntad -- es que está a tope.
• ▹Marcos y Sandra: se respetan mutuamente. A veces discrepan sobre dónde debe vivir una transformación (en el pipeline o en dbt?) pero lo resuelven con argumentos técnicos, sin drama.
• ▹Pablo y Marcos: Pablo confía en Marcos para decisiones técnicas. Si Marcos dice "eso va a llevar 3 días", Pablo no discute.
• ▹Sandra (inicio): llega con ligera desconfianza hacia ti -- el último junior que tuvieron "rompió" un modelo de dbt su primera semana. Se irá relajando cuando vea que preguntas antes de actuar.

### 9:00 AM - El onboarding con Marcos

Te sientas en la sala de reunión con tu café. Marcos entra sin prisa, con un portátil bajo el brazo. No abre presentación ni Notion -- abre directamente una terminal.

1Marcos (sala de reunion, 9:05 AM):
2
3"Mira, el setup es bastante estandar. Te lo resumo en 3 minutos
4y luego te doy accesos para que explores solo.
5
6El producto emite eventos a Kafka cuando los usuarios hacen cosas.
7Crear tareas, completar tareas, abrir boards, lo que sea. Esos
8eventos aterrizan en S3 como JSON particionado por fecha.
9
10En Redshift tenemos las tablas transaccionales: usuarios,
11workspaces, suscripciones, invoices. Lo que NO tenemos es los
12eventos. Llevan 6 meses acumulandose en S3 sin que nadie los
13toque.
14
15El repo es taskflow-data. Clonalo, en el README tienes como
16levantar el entorno local. Sandra tiene un doc de convenciones
17que te va a compartir -- leelo antes de tu primer PR.
18
19Accesos que te doy ahora:
20- GitHub: ya estas en el org, te invito al repo
21- Redshift: read-only de momento, write cuando Pablo lo apruebe
22- S3: read-only al bucket de eventos
23- Looker: viewer
24
25Preguntas?"
26
27Tu: "Los eventos de Kafka ya están en S3? O tengo que construir
28esa parte también?"
29
30Marcos: "Ya están. Hay un Kafka Connect que los dumpea a S3 cada
315 minutos. Lo que falta es cogerlos de S3, limpiarlos y cargarlos
32en Redshift. Eso es tu proyecto."
33
34Tu: "Y el formato? JSON Lines?"
35
36Marcos: "Si. Un JSON por linea. Particionado por event_type y
37fecha. La ruta es s3://taskflow-events/raw/{event_type}/{year}/
38{month}/{day}/. Tienes 6 meses de histórico. Son... no se,
39cálculo que unos 450 millones de eventos en total."
40
41Tu: "..."
42
43Marcos: "Tranquilo, no vas a cargar los 450 millones está semana.
44Empieza con una semana de muestra. Luego escalamos."

Marcos te deja los accesos configurados y se va: "Si te atascas con algo, mándame un mensaje. Prefiero 5 minutos de call a que estás 2 horas dándole vueltas." Y se va. Sin ceremonias. Es su estilo.

### 9:45 AM - Tu primer standup

1#data-team | Lunes 9:45 AM
2
3Pablo Herrera  9:45 AM
4?? Standup lunes
5Equipo, bienvenida para nuestro nuevo data engineer! ??
6Se incorpora hoy con experiencia en FreshMart (retail, pipelines
7de ingesta, modelado). Esta semana le asigno el proyecto de
8retención por cohortes.
9
10Updates:
11- Marcos: pipeline de billing (ETA miercoles)
12- Sandra: modelos de activacion de usuarios
13- Nuevo: onboarding hoy + primer ticket mañana
14
15@everyone por favor dale la bienvenida y ayudadle con lo que
16necesite está primera semana.
17
18Sandra Vidal  9:47 AM
19Bienvenido/a! ?? Cuando te instales avisame y te pasó el doc de
20convenciones. Es lectura obligatoria antes de tu primer PR jaja
21(no es broma)
22
23Marcos Delgado  9:51 AM
24Ya le he dado accesos. Tiene todo lo que necesita.
25
26Lucia Fernandez  9:53 AM
27Ey, bienvenido/a! ?? Cuando puedas te cuento el contexto del
28proyecto de retención. Pablo sabe los detalles pero si necesitas
29la perspectiva de producto estoy aquí.
30
31    ?? 3   ?? 2   ?? 1

Sonríes. El equipo parece acogedor. Sandra te da un toque de atención sobre las convenciones (nota mental: leer ese documento HOY). Marcos es escueto pero resolutivo. Lucía ya está pensando en lo que necesita de ti. Pablo tiene todo bajo control.

### 10:00 AM - El cafe con Sandra (no programado)

Vas a la cocina a por tu segundo café y Sandra está allí. Se presenta en persona -- es más alta de lo que esperabas, pelo corto, camiseta de dbt Labs. "Tú eres el nuevo, no? Bienvenido. Oye, te voy a hacer una pregunta directa: en FreshMart, cómo gestionabais las convenciones de naming?" Le cuentas que Elena tenía reglas estrictas y que aprendiste a respetar snake_case y nombres descriptivos. Sandra asiente, satisfecha.

1Sandra (en la cocina, cafe en mano):
2
3"Mira, te voy a ser honesta. El último junior que tuvimos
4-- antes de que llegaras -- era técnico pero impaciente.
5Su primer día hizo un PR directo a staging sin leer las
6convenciones. Le puso 'data' como nombre de columna. Rompio
74 modelos downstream. Desde entonces soy... protectora con
8el staging.
9
10No te lo digo para asustarte. Te lo digo para que entiendas
11por que soy detallista en los reviews. No es personal.
12Es trauma institucional." (rie)
13
14Tu: "Lo entiendo perfectamente. En FreshMart Elena me
15devolvio mi primer PR 3 veces por naming. Al cuarto intento
16aprendi."
17
18Sandra: "Perfecto. Entonces nos vamos a llevar bien.
19Lee el doc de convenciones hoy. Si tienes dudas, preguntame
20ANTES de hacer el PR. Prefiero responder 10 preguntas a
21hacer 1 code review doloroso."
22
23Tu: "Hecho."
24
25Sandra: "Bien. Ah, y una cosa más: cuando empieces con los
26eventos, ven a hablar conmigo antes de disenar la tabla.
27Tengo contexto sobre que campos necesito para mis modelos
28de dbt. Si diseñas sin saber eso, vas a tener que rehacer."
29
30Tu: "Gracias por el heads up. Manana te busco."
31
32Sandra: "??" (literalmente dice "emoji de grafica" en voz
33alta y se va con su cafe)

Esa conversación informal de 5 minutos te ha dado más información útil que una hora de documentación. Ahora sabes: Sandra es protectora pero no hostil, hay un trauma previo con un junior, ella QUIERE que le preguntes antes de actuar, y necesitas coordinar con ella el diseño de tablas. En FreshMart aprendiste que las relaciones se construyen en la cocina, no en las reuniones formales. Aquí no es diferente.

### 11:30 AM - El kickoff con Pablo

Pablo te invita a una Meet de 30 minutos. Tiene la camara encendida, un Notion abierto a un lado, y empieza con su estructura habitual: contexto, problema, objetivo, deadline.

1Pablo Herrera (Meet, 11:30 AM):
2
3"Contexto: la retención a 30 días cayo de 68% a 61% en los
4últimos 3 meses. El CEO lo presenta al board cada trimestre
5y el proximo board es en 2 semanas. Lucia necesita datos
6para su deck.
7
8Problema: no tenemos análisis de cohortes real. Lo que
9reportamos ahora es un conteo mensual de MAUs -- eso no es
10una cohorte. Una cohorte real es: de los usuarios que se
11registraron la semana 10, que porcentaje sigue activo en la
12semana 11, 12, 14, 18...
13
14Para calcular eso necesitamos saber CUANDO se registro cada
15usuario (lo tenemos en Redshift) y CUANDO fue su última
16actividad (lo tenemos en S3 pero NO en Redshift).
17
18Objetivo está semana:
191. Ingestar eventos de producto de S3 a Redshift
202. Calcular tabla de cohortes de retención
213. Identificar features correlacionadas con retención
224. Demo el viernes con resultados preliminares
23
24Sandra te ayuda con definiciones y modelado. Marcos con infra.
25Lucia es tu stakeholder de producto -- ella te dira que
26preguntas necesita responder.
27
28Deadline: demo el viernes a las 16:00.
29Dudas?"

### 12:00 PM - El documento de Sandra

1Sandra Vidal  12:02 PM (DM)
2Hola! Te mando el doc de convenciones ??
3https://notion.so/taskflow/data-conventions-v4
4
5Lee al menos las secciones de:
6- Nomenclatura de columnas
7- Nomenclatura de modelos dbt
8- Definicion de métricas (está la vamos a actualizar juntos)
9
10No hace falta que te lo memorices todo hoy. Pero antes de tu
11primer PR necesito que al menos conozcas la estructura de
12nombres. Si tienes dudas preguntame, prefiero que preguntes
13a que inventes ??
14
15Ah, y una cosa: el último junior que tuvimos (antes de que
16llegaras) le puso "data" como nombre de columna en un staging.
17Le dio a merge sin review y rompio 4 modelos downstream.
18Desde entonces el PR review es OBLIGATORIO para todo lo que
19toca staging. No te lo tomes personal si soy detallista en
20los reviews -- es trauma ??
21
22Tu  12:10 PM
23Jaja lo entiendo perfectamente. En FreshMart también teniamos
24reglas estrictas de naming. Lo leo ahora mismo.
25Pregunta rápida: que prefijo usais para las tablas staging de
26eventos? stg_? raw_?
27
28Sandra Vidal  12:12 PM
29stg_ para staging (limpieza básica, tipos correctos)
30int_ para intermediate (transformaciones, joins)
31fct_ para fact tables (métricas, granulares)
32dim_ para dimensions (entidades, lookup)
33
34Para eventos seria algo como:
35stg_product_events -> int_user_daily_activity -> fct_retention_cohorts
36
37Luego te lo explico con más detalle si quieres ??
38
39Tu  12:14 PM
40Perfecto, tiene sentido. Gracias Sandra!
41
42    ?? 1

Diferencia clave con FreshMart: en FreshMart Elena te llevaba de la mano. Te decía qué hacer, cómo hacerlo, y revisaba cada línea. Aquí Pablo te da contexto y deadline, pero no te dice COMO hacerlo. Se espera que explores solo, preguntes cuando te atascas de verdad (no cuando tienes pereza de buscar), y propongas soluciones antes de pedir que te las den.

Tu contrato dice "Data Engineer" -- sin "junior". El equipo espera que seas autónomo en tareas de complejidad media. Marcos te hace onboarding técnico pero no te microgestiona: te da accesos y te deja explorar. Si en 2 horas no has avanzado, se espera que PIDAS AYUDA -- no que estás callado.

### Lo que te llevas de FreshMart (y lo nuevo)

• ▹Ya sabes: explorar datos con Pandas sin miedo
• ▹Ya sabes: escribir SQL con JOINs, CTEs y agregaciones
• ▹Ya sabes: hacer PRs, recibir code review y no tomártelo personal
• ▹Ya sabes: que la zona raw es sagrada
• ▹Ya sabes: que los requisitos cambian y hay que preguntar antes de asumir
• ▹Ya sabes: gestionar peticiones de stakeholders con prioridades
• ▹Nuevo: eventos de producto (JSON, no transacciones de compra)
• ▹Nuevo: Kafka como fuente de datos (no CSVs manuales)
• ▹Nuevo: métricas SaaS -- retención, churn, cohortes, MRR, NRR
• ▹Nuevo: dbt como estándar de transformación
• ▹Nuevo: un equipo más técnico y un producto digital

Cierras el portátil a las 18:30. Primer día completado: accesos configurados, documento de convenciones leído (al menos por encima), contexto del proyecto claro, equipo conocido. Mañana empiezas con los datos de verdad. Te sientes preparado.

### Rituales del equipo (para que los tengas)

• ▹Standup: L-V 9:45 - async en #data-team (10 min lectura)
• ▹Weekly planning: Lunes 10:30 - Pablo + equipo datos (30 min Meet)
• ▹Data sync con Producto: Miércoles 16:00 - Lucía trae preguntas (30 min)
• ▹Code review: continuo - Marcos aprueba, Sandra comenta
• ▹Demo: Viernes 16:00 - se muestra progreso semanal a stakeholders
• ▹1:1 con Pablo: Jueves 11:00 - feedback y bloqueos (15 min)

### Canales de Slack que usarás

• ▹#data-team - Canal del equipo. Standups async aquí.
• ▹#data-eng - Solo ingenieros de datos (tú, Marcos, Sandra para temas técnicos).
• ▹#product-analytics - Canal compartido con producto. Lucía pide cosas aquí.
• ▹#data-quality - Alertas automáticas (todavía casi vacío -- tú lo vas a llenar).
• ▹#backend-data - Canal con el equipo de backend para temas de tracking.

Un detalle que notas: la cultura de TaskFlow es más asíncrona que la de FreshMart. En FreshMart había muchas calls. Aquí la gente escribe bien en Slack, usa threads, y reserva las calls para cuando son necesarias. Marcos literalmente prefiere una call de 5 minutos a un thread de 30 mensajes -- pero él es la excepción. Sandra y Pablo son personas de Slack. Lucía es de Slack pero con tendencia a DMs directos cuando tiene urgencia.