Viernes: que se entienda y se fíen del número

## Viernes, 10:00. De tu portátil al negocio

Toda la semana has entendido, limpiado, modelado y descubierto. Hoy toca la parte que decide si el trabajo sirve de algo: convertirlo en algo que otra persona pueda usar sin saber nada de modelos. A las doce tienes la demo con Mariano, el comercial, que no quiere ver tu código ni tus gráficas de residuos: quiere saber si puede prometerle a una cooperativa una predicción de cosecha y por cuánto se equivoca. Y Nuria quiere la lista de parcelas a las que bajarles el riego. Hoy cierras el repositorio: el último fichero de código, los gráficos limpios y el README que cualquiera lee al abrir el proyecto.

Lo primero es lo que de verdad pidió Nuria el lunes: predecir el rendimiento de las parcelas nuevas, las de este año que aún no se han cosechado. Para eso usas el bosque aleatorio —el modelo que ve la forma real, no el lineal que oculta el techo— entrenado con toda la tabla de modelado. Le das las features de las 250 parcelas nuevas y te devuelve, para cada una, su rendimiento estimado. Pero la predicción sola no es lo valioso; lo valioso es cruzarla con el hallazgo del agua: de esas 250 parcelas nuevas, marcar cuáles riegan por encima del óptimo de 450 milímetros, porque esas son a las que hay que avisar de que bajen el riego para cosechar más.

## Los gráficos para Mariano

Mariano decide en cinco segundos o desconecta, así que los gráficos tienen que contar la historia sin una palabra de jerga. Dos son imprescindibles. El primero y más importante es el scatter del riego contra el rendimiento con la joroba marcada y el óptimo señalado: es el gráfico estrella del caso, porque se entiende de un vistazo y es el que cambia la cabeza de Nuria. El segundo es la comparación de los dos modelos en error medio: una barra para el lineal (1.573 kg/ha) y otra para el bosque (1.162), para enseñar por qué el bosque es el bueno. Y una cifra grande, sola: el error que Mariano puede prometer sin quedar mal, los 1.162 kg/ha del bosque.

## El informe: tres hallazgos y una recomendación

El mini-informe (el one-pager) resume la semana en lo que de verdad importa para el negocio, y tiene una estructura sencilla: tres hallazgos y una recomendación. Primero, que se puede predecir el rendimiento de una parcela con un error medio de unos 1.162 kg/ha. Segundo, que el modelo lineal se queda corto porque la relación riego-cosecha no es una recta. Y tercero, el hallazgo que lo cambia todo: hay un techo de riego, y pasado cierto punto regar más baja la cosecha; un grupo de parcelas está regando por encima de ese punto, perdiendo agua y kilos a la vez. La recomendación sale sola: usar el bosque para predecir y avisar a las parcelas que riegan de más de que bajen el riego hasta el óptimo.

## La demo: la cara de Nuria

En la demo pasa lo que tenía que pasar. Mariano va al grano: «¿le puedo decir a una cooperativa cuánto va a dar su parcela, sí o no?». Y tú: «Sí, con un error medio de unos 1.162 kilos por hectárea. Y además les damos un extra: hemos visto que varias parcelas riegan de más y por eso cosechan menos, no más». Mariano se extraña —«¿cómo que menos, si Nuria lleva toda la vida diciendo que más agua es más cosecha?»— y tú le enseñas la joroba. Nuria se queda mirando la curva y suelta: «vaya. Pues le llevo toda la vida diciendo a las de Lorca que rieguen más». Y Mariano cierra: «pues eso es oro para vender: no solo le predecimos la cosecha, le ahorramos agua».

Ese momento —cuando Nuria cambia de opinión mirando tus datos— es el caso entero. No ha sido el modelo con mejor R²; ha sido el hallazgo que cambia una decisión real: a qué parcelas bajarles el riego para cosechar más gastando menos agua. Eso es lo que de verdad hace un científico de datos: no entrenar modelos, sino cambiar decisiones con datos honestos. Y lo has hecho en tu segundo encargo.

## Cerrar el repositorio

Queda la última pieza, la que convierte un montón de scripts en una pieza de portfolio: el README, el fichero que cualquiera lee primero al abrir el proyecto en GitHub, y el requirements.txt con las librerías que usa. El README no es un trámite: es la portada de tu trabajo. Tiene que decir qué hace el proyecto, cómo se ejecuta (instalar el requirements y correr los scripts de src/ en orden, del 01 al 05) y, lo más importante, el hallazgo honesto de la semana: que la relación riego-cosecha no es una recta, que hay un techo del agua, y que eso cambia la recomendación. Al escribirlo, el proyecto que montaste pieza a pieza se convierte en algo que puedes enseñar.

Y con eso cierras tu segundo encargo. Vienes de un primer trabajo donde aprendiste a desconfiar de los números demasiado buenos; aquí has aprendido algo distinto y complementario: que el mejor modelo no es siempre el más preciso, sino el que ve la forma real de las cosas. Un modelo lineal te habría dado un número decente y una conclusión cómoda y equivocada. Mirar la forma —dibujar los puntos de verdad— te dio el hallazgo que vale más que el modelo entero. Esa mirada es la que te vas a llevar al tercer encargo, y al siguiente.