Bienvenida a CoberturaYa

## Lunes, 9:30. Tu cuarto encargo, el primero de dificultad media

Ya no eres el que llega el primer día sin saber dónde está el café. Llevas tres encargos a la espalda y se nota: en una operadora de telefonía montaste un modelo para adivinar qué clientes se iban a dar de baja, y aprendiste a desconfiar de las métricas demasiado buenas; en una empresa de sensores de campo predijiste un número y aprendiste a mirar la forma real de los datos antes de creerte una recta; en una ONG lidiaste con una clase rara y aprendiste a medir donde de verdad duele. Hoy empiezas en una central de grúas, y el problema que te espera es de otra familia que no habías tocado todavía. Esta lección no lleva una sola línea de código, y es a propósito: antes de predecir nada conviene entender dónde has aterrizado, quién te pide las cosas, y por qué este problema no se parece a los anteriores.

CoberturaYa es una empresa de asistencia en carretera: cuando a alguien se le muere la batería en el arcén, se le pincha una rueda o el coche no arranca, una aseguradora o un club del automóvil le pasa la llamada a CoberturaYa, que tiene la red de grúas y la central de operaciones para mandar el vehículo adecuado al punto exacto. Nació en 2014 en Zaragoza, cubre casi toda la península y mueve cerca de 1,8 millones de servicios al año, con picos salvajes en las olas de frío, los puentes y las operaciones salida. El negocio se juega en una sola cosa: tener la grúa correcta cerca cuando entra la llamada. Si sobra gente en un turno, se paga por operadores y grúas parados; si falta, el conductor espera una hora en el arcén, la aseguradora se queja y el contrato peligra.

Durante años, los turnos se han dimensionado a ojo: "los lunes por la mañana entran muchas, en invierno más, los puentes son una locura". Funciona a medias, y deja turnos cortos justo cuando entra una ola de averías y turnos sobrados cuando no entra nadie. CoberturaYa tiene años de histórico de servicios con su hora y su zona, pero solo lo ha usado para informes a toro pasado. El salto que quieren dar —y el motivo de tu encargo— es dejar de mirar lo que ya pasó y empezar a anticipar cuántos servicios van a entrar en las próximas horas, por zona y por tramo, para poner el número justo de gente en cada turno.

## El cambio que te va a cambiar la cabeza: de filas independientes a una serie

Aquí está la idea que ordena toda la semana, y conviene entenderla despacio. En tus tres encargos anteriores, cada fila que modelabas era independiente de las demás: un cliente, una parcela, un socio. Daba igual el orden en que los miraras; la baja de un cliente no dependía de la del cliente de la fila de arriba. Aquí no. Aquí tienes una serie temporal: una fila por cada hora, y la demanda de una hora depende de la de la hora anterior, de la de ayer a la misma hora, y de la del mismo día la semana pasada. El tiempo tiene memoria. Esa memoria es buenísima —son las pistas que vas a usar para predecir el futuro—, pero trae una trampa al evaluar que es facilísima de pisar, precisamente porque las filas ya no son independientes.

Fíjate en qué significa "predecir el futuro de una serie". No vas a decir "este cliente se va" (una casilla) ni "esta parcela da 8.000 kilos" a partir de un perfil estático. Vas a decir: "el martes de 8 a 10 en la zona de Zaragoza entrarán unos N servicios". Es un número, como en el campo, así que la pregunta de "¿por cuánto me equivoco?" sigue valiendo. Pero lo que de verdad cambia es de dónde salen las pistas: no de una ficha fija, sino del propio pasado de la serie. Y eso obliga a una regla de oro al medir: el modelo solo puede usar lo que habría sabido en ese momento. En la vida real, cuando predices el martes a las 8, no conoces lo que pasará el martes a las 9. Si al evaluar le dejas verlo, te estás engañando.

## Por qué predecir la demanda vale dinero

Para entender por qué este encargo importa, ponte en el lugar de quien cuadra los turnos. Cada turno necesita un número de operadores de teléfono (que cogen las llamadas) y de grúas (que salen al arcén). Si en la zona de Zaragoza el martes de 8 a 10 van a entrar treinta servicios y has puesto gente para diez, los otros veinte conductores esperan, las aseguradoras llaman enfadadas y el contrato se tambalea. Si van a entrar diez y has puesto para treinta, pagas veinte operadores y varias grúas mirando el móvil. Las dos cosas cuestan dinero, y hoy se deciden a ojo.

Si CoberturaYa pudiera decir con antelación "la semana que viene, el martes de 8 a 10 en Zaragoza entrarán unos N servicios, y me equivoco de media en unos pocos", podría dimensionar cada turno con el número justo y un pequeño margen de seguridad donde más se mueve la demanda. Eso no es un informe bonito: es gente parada que se ahorra y conductores que no esperan en el arcén. El problema es que ese modelo no existe. Lo vas a construir tú, y —esto es lo que de verdad importa— vas a saber decir por cuántos servicios te equivocas de verdad, no por cuántos parece que te equivocas en una prueba de laboratorio.

## El equipo: quién te pide qué

En una central pequeña, saber a quién acudir para cada cosa ahorra horas. Estos son los cuatro nombres que vas a oír toda la semana, y no todos quieren lo mismo de ti.

• ▹Severino Lacasa — Data Lead, tu mentor. Físico de formación que acabó en datos, con quince años prediciendo consumo eléctrico hora a hora antes de montar este equipo. Enseña con preguntas en vez de dar respuestas, y es obsesivo con una sola cosa: que evalúes el modelo como se va a usar de verdad. Su frase: «Vas a predecir el futuro con el pasado. Si al evaluar le dejas ver el futuro, te estás engañando.» En cuanto alguien dice «me da un R² de 0,95», pregunta «¿y cómo partiste los datos?».
• ▹Rebeca Pardiñas — Responsable de la Central de Grúas, tu stakeholder. Doce años en centrales de asistencia, empezó cogiendo llamadas de gente tirada en el arcén. Conoce el pulso de la demanda como nadie, y ya tiene su conclusión antes de ver un dato: «la demanda es facilísima, lunes a tope, finde flojo, y cuando hiela se dispara; dame el número y cuadro los turnos». No es cerrada: es que cada semana sin modelo es un turno mal dimensionado. Te pasa los datos y mete prisa.
• ▹Guillem Roig — Ingeniero de Datos, tu compañero. Telecos y cuatro años montando los extractos del CAU, el software de la central. Conoce todas las marranadas del registro de servicios: fechas en varios formatos, zonas escritas a mano, huecos cuando el sistema se cae de madrugada, avisos que entran dos veces. Es tu apoyo del día a día, aunque a veces te suelta un atajo sin explicarlo. Repite una frasecita a la que nadie hace mucho caso: «ojo con partir los datos de una serie como si fueran independientes, que el tiempo tiene memoria».
• ▹Casilda Berrocal — Directora de Operaciones, la audiencia de la demo del viernes. Veinticinco años en operaciones de asistencia. No quiere ver tu código ni tus gráficas: quiere saber si puede fiarse del número para poner la gente del turno del martes y por cuánto te puedes equivocar sin dejarla corta de grúas. Si le enseñas algo que no se entiende en cinco segundos, desconecta. Prefiere una cifra honesta incómoda a una bonita que le explote en una ola de frío.

Hay una tensión sana entre Severino y Rebeca que vas a vivir toda la semana, y conviene entenderla en vez de sufrirla. Rebeca quiere el número ya y da por hecho que «la demanda se predice sola»; Severino quiere que el número sea honesto, el que de verdad se va a cumplir, no uno inflado por una evaluación tramposa. Las dos posturas tienen parte de razón, y tú estás en medio. La lección que te llevas no es «hazle caso a una»: es que darle a alguien un número que no se va a cumplir, solo porque es el que quería oír, es la forma más fácil de dejar a una central sin grúas el día de más demanda.

## Dónde vive cada dato: el stack de CoberturaYa

Antes de tocar nada, conviene saber de dónde salen los datos y por qué tú trabajas en Python y no en la herramienta que ve la dirección. CoberturaYa usa Power BI para los paneles de la dirección de operaciones: cuántos servicios entraron ayer, cómo van los tiempos de espera. Eso describe lo que ya pasó, y para eso está bien. Pero para predecir cuántos servicios entrarán hay que construir una serie temporal, derivar sus pistas y entrenar un modelo, y eso vive en Python —pandas para preparar, scikit-learn para el modelo—, con algo de SQL para agregar los extractos. Esta semana te quedas en esa fase: nadie espera que toques Power BI.

Los datos nacen en sitios distintos y por eso llegan descoordinados. Cada aviso que atiende la central queda registrado en el CAU, el software de operaciones, con su hora y su zona. La meteorología la manda un proveedor externo en ficheros, con la temperatura por zona y hora. El calendario de festivos es un fichero aparte. Y los tramos que hay que predecir —los próximos días por zona y hora— vienen en su propio fichero, todavía sin demanda, porque aún no ha pasado. Nadie ha unido nunca esas fuentes en una serie limpia, ordenada y continua. Mira el viaje entero de un vistazo.

## La semana que tienes por delante

Tu semana sigue el ritmo de un proyecto real. El lunes montas el proyecto y exploras los datos sin tocarlos. El martes limpias los avisos, los agregas a una serie por zona, fecha y hora, y fabricas las pistas que usará el modelo: la demanda de hace una hora, de hace un día, de hace una semana, y unas medias móviles y el calendario. El miércoles entrenas tu primer modelo y te llevas una alegría enorme. El jueves esa alegría se complica —y es el día que de verdad te hace científico de datos—. Y el viernes conviertes todo en algo que Casilda pueda entender en cinco segundos y en una predicción que Rebeca pueda usar para cuadrar los turnos. Fíjate en una cosa: el día que de verdad entrenas un modelo con ganas es solo el miércoles. El resto es entender, limpiar, dudar y contar, y esa proporción no es un capricho: es cómo se reparte el tiempo en el trabajo real.

## Dos entregables: la predicción y el repositorio

Antes de cerrar el primer día, Severino te deja una cosa clara que cambia cómo trabajas toda la semana. El viernes no entregas solo un número para Casilda. Entregas dos cosas. La primera es el mensaje para negocio: la predicción de demanda de los próximos tramos y, por delante, el error honesto con el que la central puede dimensionar los turnos. La segunda es un repositorio de proyecto ordenado, el mismo que usarías si esto fuera a producción. «Cuando acabes», te dice Severino, «no tendrás un montón de trozos de código sueltos: tendrás un proyecto que puedes abrir, entender y subir a tu GitHub como pieza de portfolio». Un repositorio es, sin misterio, la carpeta de un proyecto con sus ficheros organizados de una forma que cualquiera reconoce: dónde están los datos, dónde el código, dónde lo que el código produce.

Esto tiene una consecuencia que notarás cada día aunque al principio no te des cuenta. Cada ejercicio de código que resuelvas no es un trozo aislado: es un fragmento de un fichero concreto del proyecto. Los ejercicios de explorar van llenando un fichero; los de limpieza y features, otro; los del modelo, otro; los de evaluación, otro. Tú los resuelves de uno en uno, centrado en el problema de ese momento, pero por debajo estás escribiendo un programa completo y ordenado. El viernes, al mirar atrás, descubrirás que lo que parecían ejercicios sueltos era, todo el tiempo, un proyecto de forecasting montándose pieza a pieza. Este es el esqueleto que ya te han dejado preparado; no hace falta memorizarlo, es el mapa de lo que tendrás el viernes.

Lo único que importa que te lleves hoy es la idea de fondo, que ordena toda la semana: no estás haciendo ejercicios, estás construyendo un proyecto de forecasting. Y un número honesto, que de verdad se cumple cuando la central lo use, vale mucho más que uno bonito que te explota el primer martes de hielo. Ya sabes cuál es tu encargo y por qué importa. Mañana empiezas a mirar los datos de verdad.