Viernes: que se entienda y se fíen de ella

## Viernes, 10:00. Lo difícil que queda: que se entienda

Tienes un modelo honesto y entiendes por qué el 99% era mentira. Pero nada de eso sirve si Ignacio no lo entiende en la demo de las doce. El viernes es la última milla del oficio, la que muchos técnicos descuidan y la que de verdad decide si tu trabajo cambia algo: convertir un análisis en una decisión que alguien no técnico pueda tomar con confianza. Ignacio no quiere ver tu matriz de confusión ni la palabra «exhaustividad». Quiere saber dos cosas: si puede fiarse de la lista, y a cuánta gente salva su equipo con ella. Tu trabajo de hoy es responder a eso sin mentir y sin marear. La segunda pregunta tiene trampa: tus datos dicen a quién llamar primero, no cuántos se quedan gracias a la llamada, y decirlo así también es no mentir. Hoy terminas el proyecto: las dos consultas de las señales van a `sql/analisis_senales.sql`, la lista final a `src/05_lista.py`, y como última pieza escribes el `README.md` que lo corona.

Antes de contar nada, conviene confirmar con datos las señales legítimas que el modelo honesto sí usa, porque son las que vas a poder explicar. Lola llevaba razón en una cosa: el contrato mensual es la mayor señal de riesgo. Vale la pena comprobarlo con una consulta sencilla, porque darle la razón donde la tiene —con datos, no de palabra— es la mejor forma de que acepte el resto, incluida la parte incómoda. La herramienta para estos cruces rápidos es SQL sobre DuckDB, que lee las mismas tablas en el navegador. Una tasa de baja por tipo de contrato es un `GROUP BY` de libro: agrupas por contrato y, en cada grupo, divides las bajas entre el total de clientes.

La segunda señal, la que Lola no miraba, es el soporte: los clientes que se van llaman más a soporte antes de irse que los que se quedan. Un cliente que de repente abre cinco incidencias en un mes suele estar descontento, y esa señal existe antes de la baja, así que es una feature legítima, con una condición: contar solo los tickets de ANTES de la baja. Comprobar la media de tickets de los que se fueron frente a los que se quedaron pone un número a esa intuición, y es justo el tipo de hallazgo que a Ignacio le gusta: concreto, accionable, y que su equipo puede entender sin saber nada de modelos.

Comunicar datos a alguien que no es técnico es un oficio en sí mismo, y tiene una regla de oro: un gráfico que necesita explicación es un gráfico fallido. Ignacio desconecta en cinco segundos si no entiende un gráfico solo, así que cada decisión visual importa. Dos cosas que conviene tener claras antes de dibujar nada. La primera: elige el tipo de gráfico según la pregunta. Para comparar cantidades (cuántos aciertan los primeros de la lista frente a llamar al azar), barras; para una evolución en el tiempo, líneas; para una sola cifra que importa mucho, el número grande y solo. La segunda: huye de la tarta. El ojo humano compara longitudes mucho mejor que ángulos, así que una barra se lee de un vistazo y una porción de tarta hay que adivinarla. No es manía estética: es que las barras se leen y las tartas se adivinan, y tú no quieres que Ignacio adivine.

Y una decisión que parece pequeña y no lo es: el eje de ese gráfico de barras empieza en cero. Si lo arrancaras en 5 para que la diferencia entre 6 y 23 aciertos de cada 100 llamadas pareciera aún más brutal, estarías exagerando con el dibujo lo que los números ya dicen de sobra. Un gráfico honesto no necesita trucos de escala: multiplicar por cuatro los aciertos se ve por sí solo. Hacer trampa con el eje para «vender» mejor un hallazgo verdadero es la forma más tonta de perder credibilidad, porque el día que alguien se dé cuenta dejará de fiarse también de los gráficos en los que no hiciste trampa. La honestidad del jueves —no inflar el recall con una fuga— tiene que seguir siendo la honestidad del viernes: no inflar la diferencia con el eje.

## Un gráfico que cuenta la verdad sin jerga

El apoyo visual más importante del viernes es el que explica, de un vistazo, para qué sirve la lista honesta. La herramienta para dibujarlo es matplotlib, la librería de gráficos de Python. Un gráfico de barras sencillo que ponga lado a lado cuántos de cada 100 llamados se iban de verdad si llamas al azar (6) y si llamas a los primeros de la lista (23) cuenta la historia entera sin una palabra técnica. El espejismo del 99% no hace falta dibujarlo: se cuenta con una frase («usaba información que no tendremos»). La regla de oro de un gráfico para dirección: cada gráfico cuenta UNA cosa, con los ejes etiquetados, y si necesitas dos frases para explicar qué mira, son dos gráficos. Ignacio desconecta en cinco segundos si no lo entiende solo.

## Primero la conclusión: la pirámide invertida

Hay una decisión de orden que separa una demo que funciona de una que aburre, y es contraintuitiva: empieza por la conclusión, no por el camino. Tu instinto, después de una semana de trabajo, es contar el viaje —«primero exploré, luego limpié, luego entrené un modelo que daba 99%, luego descubrí la fuga...»—. Es cómo lo viviste, pero es justo al revés de como lo necesita Ignacio. Él quiere el titular en la primera frase —«el 99% que te dieron era falso; la lista honesta acierta en una de cada cuatro llamadas, cuatro veces más que llamar al azar»— y las pruebas después, solo si las pide. Guardar el hallazgo para el final, como en una novela de misterio, es el error del novato: en una reunión de negocio, el suspense se llama hacer perder el tiempo a quien decide.

## El one-pager y la demo

El entregable de la semana es un informe de una página con tres o cuatro hallazgos y una recomendación clara. Los hallazgos: sí, el contrato mensual es la mayor señal de riesgo (le damos la razón a Lola, con datos); también pesan los tickets de soporte antes de la baja, una señal que ella no miraba; el modelo «del 99%» no era bueno, usaba una columna que solo existe cuando el cliente ya se va; y lo que entregamos es una lista priorizada: de sus primeros, uno de cada cuatro se iba de verdad, cuatro veces más que llamando al azar. La recomendación: usar la lista del modelo honesto para ordenar las llamadas, empezando por los primeros, y no fiarse de métricas globales de acierto en un problema con 5% de bajas. Y una advertencia que va en el mismo papel: estos datos dicen quién se iba a ir, no cuántos se quedan gracias a la llamada. Eso se mide con una prueba: llamar a una parte de la lista elegida al azar, no llamar a la otra y comparar cuántos se van en cada mitad (un A/B).

Esa lista, además, hay que saber medirla, porque es lo que Ignacio va a preguntar: «si mi equipo llama por esta lista, ¿acierta más?». Lola pidió los 2.000 clientes de más riesgo de los 11.400 activos de hoy: un 17,5%. Para saber cuánto acierta una lista así, haces lo mismo en la prueba, donde sí sabes quién se fue: ordenas a los 2.400 por riesgo y te quedas con el mismo 17,5%, los 421 primeros. De esos 421, 96 se iban de verdad: un 23%. Llamando a 421 al azar habrías dado con unos 23, un 6%. Esa medida tiene nombre, precisión en los N primeros (de los N primeros de la lista, qué parte se iba de verdad), y es la que importa cuando el recurso escaso son las llamadas. No caza a todos los que se van —de los 133 de la prueba quedan fuera 37—, pero cada llamada rinde unas cuatro veces más que a bulto. Mira el embudo que cuentas en la demo: ese es el valor del modelo, aunque su recall con umbral 0,5 fuera de 0,03.

## 12:00 — La demo, en directo

Llega el viernes al mediodía. Tienes tres gráficos, el one-pager y la frase de cierre preparada. Antes de la reunión has hecho lo que te dijo Bea: le enseñaste a Lola el gráfico de las tallas... perdón, el gráfico del espejismo frente a la verdad, en privado, para que no se enterara delante de Ignacio de que su «dame la lista» se apoyaba en un modelo tramposo. Llegó encajada. Empiezas por el final, como toca:

1Tú  12:02
2El 99% que os dieron era falso. Usaba una marca interna que solo
3se enciende cuando retención YA ha actuado sobre un cliente, o sea
4cuando ya está de salida. Estaba leyendo el pasado, no prediciendo.
5
6Ignacio  12:03
7A ver, para. ¿Me dijeron 99 y ahora me dices que no vale?
8
9Tú  12:03
10El 99 no vale. El modelo honesto usa solo los datos que de verdad
11tenemos de un cliente activo, y ordena a los clientes de más a
12menos riesgo. Os doy los 2.000 primeros.
13
14Ignacio  12:04
15Vale. La pregunta que me importa: si mi equipo llama por orden de
16esa lista, ¿acierta más que llamando a bulto?
17
18Tú  12:04
19Sí. En la prueba, de cada cuatro llamadas a los primeros de la
20lista, una iba a alguien que se iba a ir. A bulto, una de cada
21dieciocho. Lo que aún no sabemos es cuántos se quedan gracias a
22la llamada: eso se mide llamando a una parte de la lista elegida
23al azar y comparando con la otra.
24
25Ignacio  12:05
26Pues entonces me sirve. Prefiero un número honesto a uno bonito.
27Empezamos a llamar por la lista, y en un mes me traes esa
28comparación. Buen trabajo.
29
30Lola  12:06
31me dolió ayer pero menos mal que lo miraste antes de poner a todo
32el equipo a llamar a la gente equivocada 🙏

Fíjate en lo que ha pasado y en lo que no. No has enseñado una sola línea de código. No has explicado qué es un `train_test_split` ni has pronunciado la palabra «exhaustividad» sin traducirla. No has presentado cinco hallazgos: has presentado uno, con su cifra, y lo has dejado respirar. Ignacio ha tomado una decisión en cinco minutos porque le diste el final primero y el respaldo justo detrás. Y Lola, a la que avisaste en privado el día antes, ha llegado de tu lado en vez de a la defensiva. Esa reunión es el producto de tu semana; todo lo demás —la exploración, la limpieza, los cruces, cazar la fuga— fue el andamio para poder decir esas cuatro frases con la conciencia tranquila.

Y fíjate en cómo reacciona Lola, porque ese momento define tu carrera más que cualquier modelo. Le has quitado la razón a tu stakeholder principal, y sin embargo no ha quedado como una derrota suya, sino como una buena decisión de equipo. ¿Por qué? Porque no fuiste a por Lola, fuiste a por el dato. En ningún momento dijiste «te equivocabas»; dijiste «el 99% usaba una columna que solo existe cuando el cliente ya se va». El hallazgo era contra una idea, no contra una persona. Cuidar esa diferencia —corregir el dato sin humillar a quien lo defendía— es lo que hace que la próxima vez Lola te traiga sus dudas antes de decidir, en vez de esconderte los datos. Un científico de datos al que la gente teme deja de recibir información; uno en quien confía la recibe toda.

Una estructura que funciona para casi cualquier presentación a dirección tiene cuatro partes, y cabe de sobra en los veinte minutos que te da Ignacio. Primero, el contexto en una frase: qué te pidieron (ordenar a los clientes por riesgo). Segundo, el marco: qué salía bien, para que nadie crea que vienes solo con malas noticias (el contrato y los tickets son señales reales y potentes). Tercero, el titular: el 99% era falso y por qué, con la cifra que lo sostiene. Y cuarto, la recomendación en un verbo: usad la lista honesta y empezad por los primeros. Fíjate en que dedicas al marco más tiempo del que parece necesario, y es a propósito: un hallazgo incómodo se recibe mucho mejor cuando antes has reconocido lo que sí funcionó. Empezar por la mala noticia pone a la gente a la defensiva.

## La sorpresa del viernes: tenías un proyecto montado sin saberlo

Antes de cerrar el portátil, Raúl te pide una cosa más: «abre la carpeta del proyecto y mírala entera». Lo haces, y es cuando cae la ficha. Aquella carpeta vacía que te dejó el lunes ya no está vacía. Cada ejercicio que resolviste esta semana, uno detrás de otro, ha ido a parar a un fichero concreto, y ahora el proyecto está completo. Los bloques de explorar que escribiste el lunes son `src/01_explorar.py`. La limpieza y el target del martes, `src/02_limpiar.py`. El modelo del miércoles, `src/03_modelo.py`. La evaluación honesta del jueves, `src/04_evaluar.py`. La lista de hoy, `src/05_lista.py`. Y al lado, las consultas SQL de las señales y los datos. No montaste el proyecto de golpe: lo montaste sin darte cuenta, pieza a pieza, mientras creías que solo estabas resolviendo ejercicios sueltos.

Esto es lo que de verdad te llevas a casa, aparte de la lista: un proyecto que puedes abrir en un editor, entender de un vistazo y enseñar en una entrevista. Cuando alguien te pregunte «¿y tú qué sabes hacer?», no tendrás que explicarlo con palabras: podrás abrir este repositorio y recorrerlo. Los ficheros numerados cuentan la historia solos —explorar, limpiar, modelar, evaluar, listar—, el requirements dice de qué depende, y el README, que escribes ahora mismo, cuenta qué hace y, sobre todo, el hallazgo honesto de la semana. Un acierto del 99% que no sabes defender no cabe en un portfolio; un proyecto que cuenta cómo cazaste una fuga, sí.

## Lo que te llevas de tu primera semana

Ha sido tu primera semana. Llegaste el lunes con un encargo —ordenar a los clientes por riesgo de baja— y te vas el viernes habiendo cambiado cómo un equipo entero prioriza su trabajo. No por saber más scikit-learn que nadie, sino por no dejar tranquilo un número que estaba demasiado limpio, por hacerte la pregunta de Raúl columna por columna, y por contar la verdad de forma que alguien pudiera actuar. Cada susto de la semana es un error clásico que ya sabes evitar: celebrar la accuracy en un problema desbalanceado, meter al modelo una columna que lee el futuro, fiarte de un número sin saber de dónde sale, soltar una mala noticia a bocajarro. Los has vivido una vez, y por eso la próxima no te pillan.

Y el método que te llevas vale para cualquier modelo que construyas a partir de ahora, en una telco o en lo que sea: entender el problema antes de tocar los datos, limpiar con propósito, construir el target y las features con cuidado de que existan al predecir, desconfiar de todo resultado demasiado bueno, y comunicar el hallazgo de forma que mueva una decisión. El modelo era el 10%; el otro 90% —el que de verdad decidió si tu trabajo servía— es tuyo ya. La próxima profesión traerá datos nuevos y preguntas nuevas, pero la desconfianza sana hacia tus propios resultados, que es lo más difícil de aprender, la has empezado a construir esta semana.