Tu proyecto funciona, mide y mejora la línea base. Falta el último tramo, que es el que diferencia un ejercicio privado de un trabajo profesional: comunicarlo de forma que otra persona pueda entenderlo, juzgarlo y reproducirlo. En esta lección final escribirás el informe del proyecto con una plantilla concreta, prepararás el repositorio para que cualquiera lo ejecute, te evaluarás con una rúbrica seria —la misma con la que evaluaremos, con sus luces y sus sombras, el proyecto de referencia de Rutalia— y, si tienes ocasión de presentarlo en vivo, tendrás un guion de diez minutos. Y como esta es la última lección del curso, terminaremos donde debe terminar un curso: mirando atrás al camino completo y adelante a lo que viene después.

1. El informe final: estructura y plantilla
2. Justificar las decisiones: la tabla "por qué este algoritmo y no otro"
3. Presentar resultados con honestidad
4. El README y el repositorio reproducible
5. Rúbrica de autoevaluación
6. El proyecto de referencia, evaluado
7. Presentación oral breve (si aplica)
8. Conclusión del curso

El informe no es un diario de lo que hiciste; es un documento para un lector que no estuvo allí. De 4 a 8 páginas (o su equivalente en Markdown), con esta estructura fija:

Consejo de escritura: redacta primero las secciones 4-5 (ya tienes el CSV y las tablas de 07-02) y después el resto. Los resultados son el esqueleto; la narrativa se construye alrededor.

La sección de métodos gana o pierde credibilidad en un punto: ¿elegiste cada algoritmo por una razón o porque era el último que habías estudiado? La forma más eficaz de demostrarlo es una tabla que enfrente cada decisión con las alternativas que descartaste — aquí es donde brilla el DECISIONES.md que fuiste anotando en 07-02. La del proyecto de referencia:

Fíjate en el patrón de cada fila: alternativa nombrada, criterio explícito (calidad, coste, riesgo) y, cuando existe, un número. "Elegí X porque me gusta" no aparece nunca.

La tentación al escribir resultados es enseñar solo la ejecución buena. Es la versión editorial del cherry-picking que criticamos en las métricas de 05-02, y un lector competente lo huele a distancia. Tres reglas:

• Reporta variabilidad, no un número. "−41 % de media sobre 10 instancias × 5 semillas, rango [−33 %, −47 %]" dice la verdad; "hasta un 47 % de mejora" es marketing. Si hay una instancia donde tu método pierde, aparece en la tabla.
• Cuenta lo que no funcionó. En Rutalia: el húngaro apenas movió la aguja (todos los repartidores salen del mismo depósito) y una red neuronal para los tiempos no superó a la regresión. Documentar ambos suma credibilidad: demuestra que probaste alternativas y mediste antes de decidir.
• Compara siempre en igualdad de condiciones. Mismas instancias, mismas semillas de datos para todas las variantes, misma métrica calculada por el mismo evaluador. Si una variante usa información que otra no tiene, dilo.

Formato de la tabla principal del informe (la que diseñaste por adelantado en 07-01):

El informe convence; el repositorio demuestra. El estándar es simple: una persona con Python y sin contexto debe pasar de git clone a reproducir tu tabla principal en menos de diez minutos. El README mínimo:

Checklist del repositorio antes de darlo por cerrado:

• [ ] requirements.txt con versiones; nada instalado "de memoria".
• [ ] Ninguna ruta absoluta ni dependencia de tu máquina.
• [ ] Semillas fijadas: dos ejecuciones dan la misma tabla.
• [ ] Los datos se generan con un script (o hay instrucciones de descarga); no subas datasets pesados ni, bajo ningún concepto, datos personales.
• [ ] El informe está dentro del repositorio (informe/INFORME.md).
• [ ] Prueba de fuego: clónalo en un directorio limpio y sigue tu propio README al pie de la letra.

Evalúate con esta rúbrica antes de considerar el proyecto terminado; cada nivel es acumulativo (el "bueno" incluye lo del "aceptable").

Interpretación práctica: todo en "aceptable" es un proyecto aprobado; el objetivo razonable para 20-40 horas es "bueno" en todos los criterios y "excelente" en los dos que más se alineen con tu proyecto. Un "insuficiente" en cualquier criterio manda: se corrige antes de pulir nada más.

Pasamos la rúbrica al planificador de Rutalia tal como quedó en 07-02, con la honestidad que pedimos un par de secciones más arriba:

Puntos fuertes honestos: la medición y la integración, que era justo lo que el curso más ha entrenado. Puntos débiles honestos: los bordes — casos límite sin probar y limitaciones del dato sintético poco discutidas. Es un proyecto "bueno con dos excelentes", y esa frase, con su justificación, es exactamente lo que deberías poder escribir del tuyo.

Si tienes ocasión de presentar el proyecto (una reunión de equipo, un meetup, una entrevista técnica), diez minutos bastan si se estructuran así:

Ensáyala una vez con reloj: el error universal es gastar seis minutos en contexto y correr en los resultados, que es justo lo que el público venía a ver.

• Error: el informe-diario. "Primero probé X, luego me di cuenta de que Y…" — el lector quiere el resultado organizado, no la cronología. El proceso solo aparece cuando justifica una decisión.
• Error: cherry-picking involuntario. Regenerar resultados "una última vez" y quedarte con la ejecución que salió mejor. Los números del informe salen del CSV de experimentos, con sus semillas fijadas, y de ningún otro sitio.
• Error: README aspiracional. Instrucciones que "deberían funcionar" pero nadie ha seguido desde cero. La prueba del clon limpio no es opcional.
• Error: autoevaluarse al alza. La rúbrica solo sirve si el nivel se justifica con evidencia señalable (¿dónde están esos tests?, ¿dónde está ese rango entre semillas?). Evalúa como si el proyecto fuera de otra persona.
• Consejo: pide una lectura externa. Un compañero que lea solo el informe debe poder responder: ¿qué problema resuelve, cuánto mejora y cómo lo sé? Si falla alguna, el informe —no el lector— tiene el problema.
• Consejo: el repositorio es tu portfolio. Un proyecto reproducible con medición seria dice más en una entrevista técnica que diez certificados. Púlelo pensando en ese lector.

Los tres hitos finales de tu proyecto — y del curso.

Escribe el informe de tu proyecto con la plantilla de 8 secciones, incluyendo la tabla de decisiones (mínimo 3 filas con alternativas reales) y la tabla de resultados con media y rango entre semillas.

Deja el repositorio en estado final: README con pasos de reproducción, requirements, semillas fijadas, y supera la prueba del clon limpio siguiendo tus propias instrucciones.

Evalúa tu proyecto criterio a criterio con la rúbrica, justificando cada nivel con evidencia concreta, e identifica: (a) tu criterio más fuerte, (b) el más débil y (c) la única mejora que harías con 4 horas más.

Ejercicio 1 — criterios de autoevaluación. Test del lector externo: alguien que no conozca tu proyecto debe extraer del informe el problema, la mejora numérica y cómo se midió, en menos de cinco minutos. Verifica además: cada fila de la tabla de decisiones nombra una alternativa real y un criterio (no "era la más adecuada"); la sección de resultados contiene al menos un resultado negativo o neutro; ningún número del informe es imposible de rastrear hasta tu CSV de experimentos.

Ejercicio 2 — solución orientativa. El estándar es literal: clon en directorio limpio, seguir el README palabra por palabra, obtener la tabla principal. Fallos típicos que descubre esta prueba: un import que dependía de tu PYTHONPATH, un fichero de datos que existía en tu máquina pero no se genera, una dependencia sin versión que ya no se instala igual. Si reproducir tarda más de 10 minutos de trabajo humano (el cómputo puede tardar lo que necesite), simplifica los pasos, no las instrucciones.

Ejercicio 3 — criterios de autoevaluación. Una autoevaluación creíble casi nunca es plana: lo normal es una mezcla de niveles, como la del proyecto de referencia. Sospecha de ti mismo si te has dado "excelente" en todo (revisa con la evidencia en la mano) y también si te has dado "aceptable" en todo (probablemente estás siendo injusto en tu criterio fuerte). La respuesta a (c) es la más valiosa: si la mejora que elegirías es de código o medición, tu instinto de ingeniería está bien calibrado; si es "añadir otra técnica más", relee la sección de cuándo parar de 07-02.

Y con tu informe escrito, tu repositorio reproducible y tu rúbrica rellenada, el curso termina.

Mira el camino andado. Empezaste en el módulo 1 aprendiendo a nombrar el coste de las cosas —notación asintótica, análisis de complejidad, recursión y programación dinámica, las estructuras que lo hacen posible— cuando Rutalia era solo una empresa con paquetes que entregar y nosotros ni siquiera sabíamos medir cuánto costaba entregarlos. En el módulo 2 aprendiste a optimizar: programación lineal, mochilas y viajantes (aquel óptimo de 35,22 km), backtracking, genéticos y hormigas compitiendo sobre los mismos problemas. El módulo 3 convirtió la ciudad en un grafo de nueve zonas y te dio BFS, Dijkstra, árboles de expansión, flujos y emparejamientos. El módulo 4 afinó la búsqueda y la ordenación, de la búsqueda binaria sobre la respuesta hasta A*. El módulo 5 añadió la pieza que faltaba —aprender de los datos: regresión, clasificación, redes neuronales desde cero, clustering sobre 2000 entregas— y el módulo 6 lo mezcló todo en casos reales, del día operativo con su 72 % de mejora a la ética de los modelos con consecuencias. Y en este módulo 7 dejaste de seguir el caso de estudio y lo construiste tú: especificación, desarrollo por capas, medición honesta y comunicación profesional.

Eso es lo que sabes hacer ahora, y conviene decirlo sin rodeos: sabes modelar un problema difuso como un problema formal, elegir el algoritmo con criterio (y descartar alternativas con números), predecir el coste antes de ejecutar, medir contra una línea base con variabilidad, y comunicar el resultado de forma reproducible. Esa cadena completa —no ningún algoritmo suelto— es la competencia que separa a quien ha estudiado algoritmos de quien resuelve problemas con ellos.

Próximos pasos, concretos:

• Programación competitiva (Codeforces, AtCoder, Advent of Code) para ganar velocidad y reflejos con las técnicas de los módulos 1-4; empieza por problemas de dificultad media y date tiempo.
• OR-Tools de Google para optimización industrial: en 06-01 lo dejamos citado; ahora tienes la base para usar sus solvers de VRP y programación entera entendiendo qué hacen por dentro.
• Los clásicos: Introduction to Algorithms (CLRS) como referencia de profundidad, The Algorithm Design Manual (Skiena) para el instinto de modelado, y Algorithms (Sedgewick) si prefieres partir del código.
• Especialización: si te atrapó el módulo 5, sigue con un curso serio de machine learning y lleva tus modelos a producción con las cautelas de 06-04; si te atraparon los módulos 2 y 3, la investigación operativa y la optimización combinatoria tienen profundidad para años.

Rutalia era ficticia; lo que has construido sobre ella, no. La próxima vez que alguien te traiga un problema enredado —rutas, horarios, recomendaciones, datos que no caben— reconocerás el patrón: modelar, combinar, medir. Las herramientas son tuyas y ya sabes usarlas. Ha sido un placer hacer este viaje contigo. Hasta la próxima, y buen código.