El módulo 6 se cerró con una promesa: el caso de estudio lo eliges tú. Durante seis módulos has visto cómo Rutalia —nuestra empresa ficticia de logística de última milla— convertía problemas reales en modelos, los modelos en algoritmos y los algoritmos en decisiones medibles. Ahora te toca recorrer ese mismo camino con un problema propio. Esta primera lección del proyecto final tiene un único objetivo: que salgas de ella con una especificación escrita, validada y realista de tu proyecto. Parece poco, pero es la fase donde más proyectos autodidactas mueren: quien empieza a programar sin especificación suele acabar con un script enorme que no responde ninguna pregunta. Aquí definiremos qué hace bueno a un proyecto final, veremos un catálogo de ideas, aprenderás a escribir la especificación con una plantilla concreta, y la aplicaremos completa al proyecto de referencia de Rutalia que nos acompañará durante todo el módulo.

1. Qué hace bueno a un proyecto final: integrador, medible, acotado
2. Catálogo de ideas de proyecto
3. La plantilla de especificación
4. El proyecto de referencia de Rutalia, especificado completo
5. Validar la especificación antes de escribir código

Un proyecto final de este curso no es "un programa que funciona". Es un experimento algorítmico documentado: planteas un problema, lo resuelves combinando técnicas del curso y demuestras con números que tu solución es mejor que una alternativa simple. Tres propiedades lo definen:

Debe combinar técnicas de al menos 2-3 módulos distintos del curso. Esto no es un capricho académico: en el módulo 6 viste que los problemas reales nunca se resuelven con un solo algoritmo. El día operativo de Rutalia (06-01) encadenó clustering, algoritmo húngaro, vecino más cercano y 2-opt; el sistema de recomendación (06-04) mezcló filtrado colaborativo con métricas de clasificación. Un proyecto que solo implementa Dijkstra es un ejercicio de una lección, no un proyecto final.

Debe existir una métrica de éxito numérica y una línea base contra la que compararla. La línea base es la solución más tonta que resuelve el problema de punta a punta: rutas en orden aleatorio, predicción "siempre la media", asignación por orden de llegada. Sin línea base no puedes afirmar nada: ¿un 18 % de error es bueno? Depende de si la solución trivial da un 19 % o un 60 %.

Entre 20 y 40 horas de trabajo. Menos, y no da tiempo a integrar varios módulos con medición seria; más, y el estudiante autodidacta lo abandona. La herramienta para acotar es la sección "fuera de alcance" de la especificación: escribir explícitamente lo que no vas a hacer es tan importante como escribir lo que sí.

Puedes seguir el proyecto de referencia de Rutalia tal cual, adaptarlo a otro dominio o elegir una idea distinta. Este catálogo te da ocho puntos de partida contrastados; todas cumplen las tres propiedades si se acotan bien. La dificultad es orientativa (★ = asequible en ~20 h, ★★★ = exige las 40 h).

Consejos para elegir:

• Elige un dominio que conozcas o te atraiga. Vas a pasar 20-40 horas con él; la motivación es el recurso más escaso del autodidacta.
• No elijas por dificultad, elige por claridad de la métrica. El proyecto 5 (★) bien medido vale más que el 6 (★★★) a medias.
• Trasladar el de referencia a tu dominio es legítimo y recomendable: el mismo esquema "predecir → agrupar → asignar → ordenar → comparar" funciona para repartos, técnicos de mantenimiento, visitas comerciales o recogida de residuos.

La especificación es un documento de una o dos páginas que escribes antes de la primera línea de código. Cópiala literalmente y rellena cada campo:

Dos notas sobre los campos que más se descuidan:

• Datos (campo 2). La opción por defecto en este curso es generarlos sintéticamente, como hicimos con el dataset de 2000 entregas del módulo 5: controlas el volumen, la distribución y la semilla, y no hay ningún riesgo ético ni legal. Si usas datos públicos, comprueba la licencia y que estén anonimizados de origen. Usar datos reales de personas —aunque "solo sea para probar"— queda fuera de este proyecto, sin excepciones.
• Hitos (campo 7). Cada hito debe producir algo ejecutable o medible, no "avanzar en X". "H2: el modelo de regresión predice tiempos con MAE < 4 min en test" es un hito; "H2: trabajar en el modelo" no lo es.

Aplicamos la plantilla, completa y sin huecos, al proyecto que desarrollaremos en 07-02 y evaluaremos en 07-03. Fíjate en el nivel de concreción: este es el estándar que debe alcanzar tu especificación.

Antes de dar la especificación por buena, sométela a esta checklist de viabilidad. Cada "no" es una revisión obligatoria, no un detalle:

• [ ] ¿Existe una línea base trivial? Debes poder escribirla en menos de una tarde. Si ni siquiera la solución tonta es fácil, el problema está mal acotado.
• [ ] ¿La métrica se puede calcular con un script? Si medir el éxito requiere juicio humano ("las rutas parecen razonables"), no es una métrica.
• [ ] ¿Los datos se pueden generar u obtener en menos de 1 hora? Un generador sintético de 50 líneas de numpy cumple; "encontraré un dataset por internet" no cumple hasta que el dataset esté descargado y cargado.
• [ ] ¿Cada algoritmo previsto tiene su lección en la tabla? Si aparece una técnica que el curso no ha cubierto, o la sustituyes o la justificas como extensión pequeña.
• [ ] ¿La suma de horas de los hitos está entre 20 y 40? Y ningún hito supera las 8 horas: si uno lo hace, divídelo.
• [ ] ¿La sección "fuera de alcance" tiene al menos 3 entradas? Si no se te ocurren, es que aún no has pensado en todo lo que el proyecto podría tragarte.

Una técnica útil: escribe la última tabla del informe final antes de empezar (columnas: variante, tiempo total, mejora %, tiempo de cómputo). Si sabes exactamente qué tabla quieres poder rellenar al final, toda decisión intermedia se vuelve más fácil.

• Error: el proyecto-plataforma. "Haré una web con login donde se suban pedidos y…" — eso es un proyecto de desarrollo web, no de algoritmos. Todo lo que no sea generar datos, ejecutar algoritmos y medir resultados va a "fuera de alcance".
• Error: la métrica retroactiva. Decidir cómo medir después de implementar invita al autoengaño: acabarás eligiendo la métrica en la que tu solución queda bien. Métrica y línea base se fijan aquí, por escrito.
• Error: datos reales "porque son más auténticos". Además del problema ético y legal (recuerda 06-04: sesgo, privacidad, Reglamento europeo de IA), los datos reales traen limpieza infinita que consume el presupuesto de horas. Los sintéticos te dejan controlar la dificultad.
• Error: alcance en expansión silenciosa. El síntoma es la frase "ya que estoy, añado…". El antídoto es releer la sección 6 de tu especificación cada vez que la pronuncies.
• Consejo: especificación corta y congelada. Una-dos páginas. Cuando la valides con la checklist, trátala como un contrato contigo mismo: los cambios se anotan y se justifican, no se improvisan.
• Consejo: si dudas entre dos ideas, especifica las dos. Son 30 minutos por plantilla, y la checklist casi siempre decide sola cuál es viable.

Los ejercicios de este módulo son los hitos de tu propio proyecto: no tienen una única solución, sino criterios de autoevaluación.

Elige tu proyecto (del catálogo, adaptado o propio) y escribe un párrafo justificando que es integrador (¿qué 2-3 módulos combina y cómo se encadenan sus salidas?), medible (¿qué número, contra qué base?) y acotado (¿qué dejas fuera?).

Rellena la plantilla de las 7 secciones para tu proyecto, con el nivel de detalle del ejemplo de Rutalia: tabla de algoritmos con lecciones, métrica con instancias y objetivo numérico, y plan de hitos con horas.

Pasa la checklist de viabilidad a tu especificación. Para cada punto que falle, modifica la especificación (no la checklist) y anota qué cambiaste.

Ejercicio 1 — criterios de autoevaluación. Tu párrafo es sólido si: (a) nombra lecciones concretas, no módulos vagos ("uso k-means de 05-05", no "uso ML"); (b) explica el encadenamiento — la salida de una técnica es la entrada de la siguiente, como matriz de tiempos → clustering → asignación en Rutalia; (c) la métrica cabe en una frase con un número objetivo. Señal de fallo: si al releerlo no sabrías por dónde empezar a programar, es demasiado vago.

Ejercicio 2 — solución orientativa. Compara tu documento con el de Rutalia sección a sección y pregúntate: ¿mi sección es igual de concreta? En particular: la sección de datos debe incluir volumen, campos y semilla; la tabla de algoritmos debe tener una fila por fase del pipeline; cada hito debe ser verificable por un tercero que solo lea el entregable. Si tu especificación completa ocupa menos de media página, falta concreción; si supera dos páginas, sobra plataforma.

Ejercicio 3 — criterios de autoevaluación. El resultado esperado es que algo haya cambiado: en la práctica, ninguna primera especificación pasa la checklist limpia. Los ajustes más habituales (y buena señal de que estás validando de verdad) son: recortar el alcance de los datos, sustituir un algoritmo no cubierto por uno del curso y partir un hito de 12 horas en dos. Si tu checklist salió perfecta a la primera, revisa con más dureza el punto de la línea base trivial: es donde más se cuela el optimismo.

Ya tienes lo más difícil: un proyecto elegido y una especificación validada que cabe en una página y en 20-40 horas. Hemos visto que un buen proyecto final es integrador (2-3 módulos encadenados), medible (métrica + línea base fijadas por adelantado) y acotado (con un "fuera de alcance" explícito), y hemos dejado el proyecto de referencia de Rutalia —el planificador de reparto con predicción de tiempos— completamente especificado como vara de medir. En la próxima lección (07-02) toca convertir el papel en código: montaremos la estructura del proyecto, construiremos primero la línea base que funciona de punta a punta y añadiremos las capas algorítmicas una a una, midiendo en cada hito. La especificación que acabas de escribir será el mapa; no lo pierdas de vista.