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. 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, incluido el 96% incómodo. 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 mucho más a soporte en los meses previos que los que se quedan. Un cliente que de repente abre cinco incidencias en un mes está mandando una señal de descontento, y esa señal existe antes de la baja, así que es una feature legítima y potente. 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 (la exhaustividad del espejismo frente a la del modelo honesto), 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 0,30 para que la diferencia entre 0,38 y 0,93 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: la caída de 0,93 a 0,38 es dramática por sí sola. 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 caída 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, por qué pasaste del 99% al 96% y por qué eso es bueno. 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 la exhaustividad del espejismo (0,93, con la columna fuga) y la del modelo honesto (0,38, sin ella) cuenta la historia entera sin una palabra técnica: «el número de la izquierda era mentira porque usaba información que no tendremos; el de la derecha es real». 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 buena caza a 4 de cada 10 pero son de verdad»— 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 en la que los primeros son de riesgo real. 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.

Esa lista, además, hay que saber dimensionarla, porque es lo que Ignacio va a preguntar: «¿a cuánta gente salva mi equipo con esto?». De los 2.400 clientes de la prueba, el modelo honesto marca 59 como «se va»; de esos, 50 se iban de verdad y 9 son falsas alarmas. En vez de llamar a bulto a miles, retención llama a 59 y acierta en 50. No caza a todos los que se van —se le escapan 83—, pero convierte una lista imposible de recorrer en una lista corta y de calidad. Mira el embudo que cuentas en la demo: ese es el valor del modelo, aunque su recall del 0,38 suene bajo.

## 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 retencion YA ha actuado sobre un cliente, o sea
4cuando ya esta 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, con solo los datos que de verdad
11tenemos de un cliente activo, caza a 4 de cada 10 de los que se van
12y los pone los PRIMEROS de la lista.
13
14Ignacio  12:04
15Vale. La pregunta que me importa: si mi equipo llama por orden de
16esa lista, ¿acierta mas que llamando a bulto?
17
18Tú  12:04
19Mucho mas. De 59 clientes que marca, 50 se iban de verdad.
20
21Ignacio  12:05
22Pues entonces me sirve. Prefiero un numero honesto a uno bonito.
23Empezamos a llamar por la lista. Buen trabajo.
24
25Lola  12:06
26me dolio ayer pero menos mal que lo miraste antes de poner a todo
27el 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.