El mòdul 6 es va tancar amb una promesa: el cas d'estudi el tries tu. Durant sis mòduls has vist com Rutalia —la nostra empresa fictícia de logística d'última milla— convertia problemes reals en models, els models en algorismes i els algorismes en decisions mesurables. Ara et toca recórrer aquest mateix camí amb un problema propi. Aquesta primera lliçó del projecte final té un únic objectiu: que en surtis amb una especificació escrita, validada i realista del teu projecte. Sembla poc, però és la fase on més projectes autodidactes moren: qui comença a programar sense especificació sol acabar amb un script enorme que no respon cap pregunta. Aquí definirem què fa bo un projecte final, veurem un catàleg d'idees, aprendràs a escriure l'especificació amb una plantilla concreta, i l'aplicarem completa al projecte de referència de Rutalia que ens acompanyarà durant tot el mòdul.

1. Què fa bo un projecte final: integrador, mesurable, acotat
2. Catàleg d'idees de projecte
3. La plantilla d'especificació
4. El projecte de referència de Rutalia, especificat complet
5. Validar l'especificació abans d'escriure codi

Un projecte final d'aquest curs no és "un programa que funciona". És un experiment algorísmic documentat: planteges un problema, el resols combinant tècniques del curs i demostres amb números que la teva solució és millor que una alternativa simple. Tres propietats el defineixen:

Ha de combinar tècniques d'almenys 2-3 mòduls diferents del curs. Això no és un caprici acadèmic: al mòdul 6 vas veure que els problemes reals no es resolen mai amb un sol algorisme. El dia operatiu de Rutalia (06-01) va encadenar clustering, algorisme hongarès, veí més proper i 2-opt; el sistema de recomanació (06-04) va barrejar filtratge col·laboratiu amb mètriques de classificació. Un projecte que només implementa Dijkstra és un exercici d'una lliçó, no un projecte final.

Ha d'existir una mètrica d'èxit numèrica i una línia base contra la qual comparar-la. La línia base és la solució més ximple que resol el problema de cap a cap: rutes en ordre aleatori, predicció "sempre la mitjana", assignació per ordre d'arribada. Sense línia base no pots afirmar res: un 18 % d'error és bo? Depèn de si la solució trivial dona un 19 % o un 60 %.

Entre 20 i 40 hores de feina. Menys, i no dona temps a integrar diversos mòduls amb mesurament seriós; més, i l'estudiant autodidacta l'abandona. L'eina per acotar és la secció "fora d'abast" de l'especificació: escriure explícitament el que no faràs és tan important com escriure el que sí.

Pots seguir el projecte de referència de Rutalia tal qual, adaptar-lo a un altre domini o triar una idea diferent. Aquest catàleg et dona vuit punts de partida contrastats; totes compleixen les tres propietats si s'acoten bé. La dificultat és orientativa (★ = assequible en ~20 h, ★★★ = exigeix les 40 h).

Consells per triar:

• Tria un domini que coneguis o que t'atregui. Hi passaràs 20-40 hores; la motivació és el recurs més escàs de l'autodidacta.
• No triïs per dificultat, tria per claredat de la mètrica. El projecte 5 (★) ben mesurat val més que el 6 (★★★) a mitges.
• Traslladar el de referència al teu domini és legítim i recomanable: el mateix esquema "predir → agrupar → assignar → ordenar → comparar" funciona per a repartiments, tècnics de manteniment, visites comercials o recollida de residus.

L'especificació és un document d'una o dues pàgines que escrius abans de la primera línia de codi. Copia-la literalment i omple cada camp:

Dues notes sobre els camps que més es descuiden:

• Dades (camp 2). L'opció per defecte en aquest curs és generar-les sintèticament, com vam fer amb el dataset de 2000 lliuraments del mòdul 5: controles el volum, la distribució i la llavor, i no hi ha cap risc ètic ni legal. Si fas servir dades públiques, comprova la llicència i que estiguin anonimitzades d'origen. Fer servir dades reals de persones —encara que "només sigui per provar"— queda fora d'aquest projecte, sense excepcions.
• Fites (camp 7). Cada fita ha de produir alguna cosa executable o mesurable, no "avançar en X". "H2: el model de regressió prediu temps amb MAE < 4 min en test" és una fita; "H2: treballar en el model" no ho és.

Apliquem la plantilla, completa i sense buits, al projecte que desenvoluparem a 07-02 i avaluarem a 07-03. Fixa't en el nivell de concreció: aquest és l'estàndard que ha d'assolir la teva especificació.

Abans de donar l'especificació per bona, sotmet-la a aquesta checklist de viabilitat. Cada "no" és una revisió obligatòria, no un detall:

• [ ] Existeix una línia base trivial? L'has de poder escriure en menys d'una tarda. Si ni tan sols la solució ximple és fàcil, el problema està mal acotat.
• [ ] La mètrica es pot calcular amb un script? Si mesurar l'èxit requereix judici humà ("les rutes semblen raonables"), no és una mètrica.
• [ ] Les dades es poden generar o obtenir en menys d'1 hora? Un generador sintètic de 50 línies de numpy compleix; "ja trobaré un dataset per internet" no compleix fins que el dataset estigui descarregat i carregat.
• [ ] Cada algorisme previst té la seva lliçó a la taula? Si hi apareix una tècnica que el curs no ha cobert, o la substitueixes o la justifiques com a extensió petita.
• [ ] La suma d'hores de les fites està entre 20 i 40? I cap fita no supera les 8 hores: si una ho fa, divideix-la.
• [ ] La secció "fora d'abast" té almenys 3 entrades? Si no se te n'acudeixen, és que encara no has pensat en tot el que el projecte podria empassar-se't.

Una tècnica útil: escriu la darrera taula de l'informe final abans de començar (columnes: variant, temps total, millora %, temps de còmput). Si saps exactament quina taula vols poder omplir al final, tota decisió intermèdia es torna més fàcil.

• Error: el projecte-plataforma. "Faré una web amb login on es pengin comandes i…" — això és un projecte de desenvolupament web, no d'algorismes. Tot el que no sigui generar dades, executar algorismes i mesurar resultats va a "fora d'abast".
• Error: la mètrica retroactiva. Decidir com mesurar després d'implementar convida a l'autoengany: acabaràs triant la mètrica en què la teva solució queda bé. Mètrica i línia base es fixen aquí, per escrit.
• Error: dades reals "perquè són més autèntiques". A més del problema ètic i legal (recorda 06-04: biaix, privacitat, Reglament europeu d'IA), les dades reals porten una neteja infinita que consumeix el pressupost d'hores. Les sintètiques et deixen controlar la dificultat.
• Error: abast en expansió silenciosa. El símptoma és la frase "ja que hi soc, hi afegeixo…". L'antídot és rellegir la secció 6 de la teva especificació cada vegada que la pronunciïs.
• Consell: especificació curta i congelada. Una-dues pàgines. Quan la validis amb la checklist, tracta-la com un contracte amb tu mateix: els canvis s'anoten i es justifiquen, no s'improvisen.
• Consell: si dubtes entre dues idees, especifica-les totes dues. Són 30 minuts per plantilla, i la checklist gairebé sempre decideix tota sola quina és viable.

Els exercicis d'aquest mòdul són les fites del teu propi projecte: no tenen una única solució, sinó criteris d'autoavaluació.

Tria el teu projecte (del catàleg, adaptat o propi) i escriu un paràgraf justificant que és integrador (quins 2-3 mòduls combina i com s'encadenen les seves sortides?), mesurable (quin número, contra quina base?) i acotat (què deixes fora?).

Omple la plantilla de les 7 seccions per al teu projecte, amb el nivell de detall de l'exemple de Rutalia: taula d'algorismes amb lliçons, mètrica amb instàncies i objectiu numèric, i pla de fites amb hores.

Passa la checklist de viabilitat a la teva especificació. Per cada punt que falli, modifica l'especificació (no la checklist) i anota què has canviat.

Exercici 1 — criteris d'autoavaluació. El teu paràgraf és sòlid si: (a) anomena lliçons concretes, no mòduls vagues ("faig servir k-means de 05-05", no "faig servir ML"); (b) explica l'encadenament — la sortida d'una tècnica és l'entrada de la següent, com matriu de temps → clustering → assignació a Rutalia; (c) la mètrica cap en una frase amb un número objectiu. Senyal de fallada: si en rellegir-lo no sabries per on començar a programar, és massa vague.

Exercici 2 — solució orientativa. Compara el teu document amb el de Rutalia secció a secció i pregunta't: la meva secció és igual de concreta? En particular: la secció de dades ha d'incloure volum, camps i llavor; la taula d'algorismes ha de tenir una fila per fase del pipeline; cada fita ha de ser verificable per un tercer que només llegeixi el lliurable. Si la teva especificació completa ocupa menys de mitja pàgina, hi falta concreció; si supera dues pàgines, hi sobra plataforma.

Exercici 3 — criteris d'autoavaluació. El resultat esperat és que alguna cosa hagi canviat: a la pràctica, cap primera especificació no passa la checklist neta. Els ajustos més habituals (i bon senyal que estàs validant de debò) són: retallar l'abast de les dades, substituir un algorisme no cobert per un del curs i partir una fita de 12 hores en dues. Si la teva checklist ha sortit perfecta a la primera, revisa amb més duresa el punt de la línia base trivial: és on més s'esmuny l'optimisme.

Ja tens el més difícil: un projecte triat i una especificació validada que cap en una pàgina i en 20-40 hores. Hem vist que un bon projecte final és integrador (2-3 mòduls encadenats), mesurable (mètrica + línia base fixades per endavant) i acotat (amb un "fora d'abast" explícit), i hem deixat el projecte de referència de Rutalia —el planificador de repartiment amb predicció de temps— completament especificat com a vara de mesurar. A la propera lliçó (07-02) toca convertir el paper en codi: muntarem l'estructura del projecte, construirem primer la línia base que funciona de cap a cap i hi afegirem les capes algorísmiques una a una, mesurant a cada fita. L'especificació que acabes d'escriure serà el mapa; no el perdis de vista.