Durant set mòduls has seguit la Marta, en Dani i la Lucía. Has vist com AlpinaShop va passar d'un servidor llogat en un proveïdor espanyol a una plataforma a Google Cloud amb lliurament continu, observabilitat, SLO, govern i una factura un 60 % més baixa. Has vist les decisions i també els errors: el MIG que es va arrossegar cinc mòduls, l'endpoint de recomanacions que es va haver d'apagar, la clau de compte de servei perduda durant catorze mesos.

Però has vist decidir altres.

Aquest mòdul és diferent. Aquí no hi ha cap AlpinaShop a qui seguir: hi ha un full en blanc, un conjunt de restriccions i una data. Triaràs un problema, dissenyaràs una solució, la construiràs, la provaràs, la desplegaràs, la mesuraràs, la pagaràs i la defensaràs. De principi a fi, tu sol.

I hi ha una raó pràctica per la qual això importa més que qualsevol lliçó anterior: ningú no et contractarà per haver llegit sobre Cloud Run. Et contractaran perquè pots ensenyar una URL que funciona, un repositori amb la infraestructura escrita com a codi, un tauler amb mètriques reals i una factura de 14 € al mes que saps explicar línia a línia. Això és un porfolio. La resta són apunts.

Aquesta primera lliçó és el plec de condicions del projecte. Defineix què se't demana, amb quins requisits mínims, sota quin límit de cost, amb quins lliurables, amb quina rúbrica t'avaluaràs i en quin termini. Llegeix-la sencera abans d'escriure una línia de codi o de crear un sol projecte de GCP. És literalment la lliçó que evita que d'aquí a tres setmanes tinguis mig sistema i cap idea de si està bé.

1. Què se't demana exactament i per què així
2. Com triar el problema: criteris d'un projecte de porfolio que funciona
3. Quatre propostes desenvolupades
4. Portar el teu propi problema (i l'advertiment que no et pots saltar)
5. Requisits funcionals mínims obligatoris
6. Requisits no funcionals obligatoris
7. La restricció de cost: el requisit que més t'ensenyarà
8. Lliurables i el seu format
9. La rúbrica d'avaluació
10. Planificació: esforç per fase i cronograma
11. Gestió del risc: els cinc errors que enfonsen un projecte final
12. Com treballar amb la documentació oficial
13. Què fer quan alguna cosa no funciona
14. La teva decisió d'avui

L'encàrrec, en una frase:

Construeix a Google Cloud, de principi a fi i amb les teves pròpies mans, una plataforma completa per a un problema que triïs tu, recorrent les mateixes etapes que has vist recórrer a AlpinaShop, i deixa-la documentada, mesurada, segura i reproduïble des de zero.

No és «fes una demo». Una demo és un contenidor desplegat a Cloud Run amb gcloud run deploy i una captura de pantalla. Això ho fa qualsevol en vint minuts i no demostra res, perquè la feina real no és desplegar: és tot el que envolta el desplegament.

El que sí que demostra criteri és això:

El projecte està dissenyat per tocar totes les capes del curs, no per aprofundir en una. És deliberat: un projecte que només demostra BigQuery competeix amb milers de projectes que demostren BigQuery. Un projecte que demostra que saps connectar còmput, dades, identitat, xarxa, lliurament i observabilitat —i explicar per què cada peça és on és— competeix amb molt pocs.

Quant temps costa. Entre 40 i 60 hores de feina real si hi vas per primera vegada. Repartides en 4-6 setmanes a ritme de tarda solta i cap de setmana, és perfectament factible. Si te'n surten 15 hores, és que estàs fent una demo. Si te'n surten 150, és que l'abast se t'ha escapat de les mans, i hi ha un apartat sencer sobre això més avall.

Què NO se't demana. Convé dir-ho aviat, perquè la meitat del risc d'aquest mòdul és fer de més:

• No se't demana una aplicació bonica. Una interfície lletja però funcional puntua igual que una preciosa.
• No se't demana un model de machine learning propi. Una API preentrenada compleix el requisit d'IA.
• No se't demana alta disponibilitat multiregió. Una regió n'hi ha ben bé prou.
• No se't demana Kubernetes. Cloud Run és l'opció recomanada per defecte.
• No se't demana un volum de dades gran. Mil files fictícies demostren el mateix que deu milions i costen zero.
• No se't demana que estigui «acabat» en el sentit d'un producte. Se't demana que estigui complet en el sentit que totes les capes existeixen i funcionen juntes.

L'elecció del problema és la decisió amb més conseqüències de tot el mòdul, i es pren la primera hora. Un mal problema converteix el projecte en una tortura de sis mesos; un de bo el converteix en quatre caps de setmana entretinguts.

Cinc criteris, per ordre d'importància:

Si tries «plataforma de trading algorítmic» i no saps què és un llibre d'ordres, gastaràs el 70 % del temps aprenent finances en comptes d'aprendre GCP. El domini ha de ser tan obvi per a tu que puguis escriure els requisits funcionals de memòria en vint minuts.

Bons dominis: reserves, catàlegs, inventaris, incidències, seguiment de flotes, cursos, cites, gestió de socis. Tothom entén com funciona una reserva.

Mals dominis: qualsevol cosa amb normativa complexa (sanitat real, banca, assegurances), qualsevol cosa amb algoritmes que són el producte (motors de recomanació de debò, optimització de rutes òptima), qualsevol cosa que depengui d'una integració externa que no controles.

Prova de descriure el teu projecte en una frase. Si necessites dues «i», ja és massa gran.

• ✅ «Una plataforma on els usuaris reserven places en refugis de muntanya.»
• ⚠️ «Una plataforma on els usuaris reserven places en refugis i els guardes gestionen disponibilitat i hi ha un marketplace de guies.»
• ❌ «Un ERP per a la gestió integral de refugis.»

L'abast es retalla abans de començar, no a mitges. Retallar a mitges vol dir llençar feina feta.

Necessitaràs dades per a la base de dades operativa, per al magatzem analític i per al component d'IA. Si el teu domini necessita dades que no pots inventar de manera creïble (imatges mèdiques etiquetades, transaccions bancàries reals), canvia de domini.

Un bon projecte es pot sembrar amb un script de 60 línies de Python que generi 2.000 files coherents: dates que tenen sentit, imports en un rang raonable, distribució amb una mica d'estacionalitat perquè el tauler de control no surti pla.

El requisit d'«aplicació + emmagatzematge + base de dades + dades + analítica + IA» ha de sortir del problema, no forçar-se a sobre. Si has d'inventar una excusa per encabir-hi Pub/Sub, el projecte està mal triat.

Pregunta't: hi ha alguna cosa que passi de manera asíncrona? Hi ha fitxers per pujar? Hi ha alguna cosa per analitzar històricament? Si les tres respostes són que sí, el projecte encaixa sol.

Passaràs 50 hores amb això, moltes d'elles depurant permisos IAM a les onze de la nit. Si el tema t'avorreix el primer dia, el projecte no s'acaba. Aquest criteri sembla tou i és el que mata més projectes.

Puntua cada idea que se t'acudeixi d'1 a 5 en cada criteri. Si alguna columna treu menys de 3, descarta-la:

Si no tens una idea pròpia clara, fes servir una d'aquestes quatre. Estan dimensionades per al mòdul, tenen dades inventables i exerciten totes les capes obligatòries. Les quatre són fictícies.

El problema. Una federació fictícia de muntanyisme gestiona 12 refugis al Pirineu. Avui les reserves es fan per telèfon i s'apunten en un full de càlcul per refugi. Hi ha sobrevenda, no se sap l'ocupació real fins que arriba el cap de setmana, i no hi ha manera de saber quins refugis funcionen millor.

Què construeixes.

• Web pública on un excursionista busca refugi i data, veu places lliures i reserva.
• Zona privada on el guarda de cada refugi consulta les reserves del dia.
• Pujada de fotos del refugi a un bucket, amb generació de miniatures.
• Cada reserva publica un esdeveniment que alimenta el magatzem analític.
• Tauler de control d'ocupació per refugi, mes i tipus de plaça.
• Component d'IA: anàlisi de sentiment de les opinions que deixen els excursionistes (API preentrenada) o etiquetatge automàtic de les fotos.

Dades fictícies. 12 refugis amb nom, coordenades i capacitat; 2.000 reserves repartides en 18 mesos amb estacionalitat d'estiu; 400 opinions en text lliure.

Dificultat: mitjana-baixa. És la proposta de referència d'aquest mòdul i la que es fa servir en totes les solucions dels exercicis.

El que ensenya d'interessant. La gestió de la disponibilitat té una condició de cursa real (dues persones reservant l'última plaça), cosa que dona peu a una transacció de debò i a una prova d'integració amb sentit.

El problema. Una cadena fictícia de tres clíniques veterinàries necessita gestionar les fitxes dels animals, les cites i les històries clíniques. Avui fan servir un programa d'escriptori instal·lat en un ordinador per clínica, sense accés remot.

Què construeixes.

• Web autenticada on el personal dona d'alta animals i propietaris, i programa cites.
• Pujada de radiografies i fotos de l'evolució d'una lesió a un bucket amb classe d'emmagatzematge per antiguitat.
• Recordatoris de cita: la creació d'una cita publica un missatge que dispara un enviament simulat.
• Tauler de control d'ocupació d'agenda, motius de consulta més freqüents i facturació per clínica.
• Component d'IA: extracció d'entitats del text lliure de la història clínica (API de llenguatge natural) per etiquetar diagnòstics, o classificació de les imatges pujades.

Dades fictícies. 3 clíniques, 8 veterinaris, 600 animals, 3.500 cites històriques, 1.200 notes clíniques en text lliure.

Dificultat: mitjana.

⚠️ Avís important per a aquesta proposta. Encara que les dades dels animals no són dades personals, les dels seus propietaris sí que ho són. Treballa exclusivament amb noms, telèfons, correus i adreces inventats. No copiïs una base de dades real de cap clínica, ni «anonimitzada»: l'anonimització mal feta és reidentificable i et fica en un problema d'RGPD que no té res a veure amb aprendre GCP.

El problema. Una empresa fictícia de repartiment d'última milla amb 30 furgonetes vol saber on són els seus vehicles, quines entregues porten fetes i quant triga cada ruta.

Què construeixes.

• Ingesta de posicions: un simulador publica cada 30 segons la posició de cada furgoneta en un topic.
• Servei web amb un mapa que mostra l'estat actual de la flota i el detall de cada ruta.
• Emmagatzematge dels albarans signats (imatges) en un bucket.
• Base de dades operativa amb vehicles, rutes, parades i entregues.
• Tauler de control de puntualitat, quilòmetres per ruta i entregues fallides per motiu.
• Component d'IA: OCR sobre els albarans escanejats (API de visió) per extreure el número de comanda.

Dades fictícies. 30 vehicles, 12 rutes, 90 dies d'històric amb unes 400 entregues diàries, i un generador de posicions GPS que segueix trajectòries plausibles.

Dificultat: mitjana-alta. És la proposta amb més volum de dades i la que més exercita el streaming, però també la que més fàcilment es dispara de cost si deixes el simulador encès. Llegeix-ho com un advertiment: aquí el requisit de cost és part del repte.

⚠️ La posició geogràfica d'una persona identificable és una dada personal de categoria sensible. Treballa amb vehicles i conductors inventats, mai amb dades reals d'una flota.

El problema. Una escola fictícia de formació tècnica vol substituir el seu muntatge de vídeos en un disc compartit i matrícules per correu per una plataforma pròpia.

Què construeixes.

• Catàleg públic de cursos i zona privada de l'alumne amb el seu progrés.
• Materials (PDF, vídeos) en un bucket, servits amb CDN i URL signades.
• Base de dades operativa amb cursos, lliçons, matrícules i progrés.
• Esdeveniments de «lliçó completada» que alimenten el magatzem analític.
• Tauler de control de taxa de finalització per curs, lliçons on la gent abandona i activitat setmanal.
• Component d'IA: generació d'un resum automàtic de cada lliçó amb un model generatiu, o cerca semàntica sobre el contingut mitjançant embeddings.

Dades fictícies. 20 cursos, 250 lliçons, 800 alumnes i 40.000 esdeveniments de progrés.

Dificultat: mitjana. És la proposta que més s'assembla a aquest mateix curs, cosa que la fa fàcil de raonar i difícil que et sorprengui.

Portar un problema propi és la millor opció si compleixes els cinc criteris de l'apartat 2. Un projecte que resol alguna cosa que tu entens i que t'importa es defensa molt millor en una entrevista que una plantilla, perquè així que et pregunten «i per què això?» tens una resposta de debò.

Però hi ha una línia que no es creua:

⚠️ No facis servir dades reals de la teva empresa, ni de l'empresa de ningú.

Ni una exportació «que ja està anonimitzada». Ni un bolcat de la base de dades de desenvolupament. Ni el fitxer de clients amb els noms canviats. Ni les converses del sistema de suport «que no porten noms».

Tres motius, qualsevol d'ells suficient:

1. Legal. L'RGPD no distingeix entre «producció» i «un projecte que estic fent per aprendre». Si tractes dades personals necessites base jurídica, finalitat, minimització i una relació contractual amb l'encarregat del tractament. Un projecte de porfolio al teu compte personal de GCP no té res d'això.
2. Contractual. Gairebé qualsevol contracte laboral o de confidencialitat prohibeix treure dades de l'empresa a un entorn que l'empresa no controla. El teu projecte de GCP és exactament això.
3. Pràctic. Un projecte de porfolio s'ensenya. Es posa a GitHub, es comparteix la URL, es projecta en una entrevista. Si conté dades reals, acabes de publicar-les.

El que sí que pots fer: replicar l'estructura del problema real amb dades inventades. L'esquema, els fluxos, les regles de negoci i les dificultats tècniques són teus i no són confidencials; les dades, no. Un generador de dades sintètiques de 80 línies resol això en una tarda.

I si tot i així el teu projecte tractarà dades que s'assemblen a dades personals (noms, correus, adreces, encara que inventats), aplica des del principi el que vas veure a 04-07 i a 07-04: xifratge en repòs amb claus gestionades, mínim privilegi, retenció definida amb esborrat real, i registres que no escriguin aquests camps. No perquè les teves dades inventades ho necessitin, sinó perquè l'hàbit és el lliurable.

Abans d'acceptar-la, omple això. Si alguna casella queda buida, la idea no està a punt:

L'apartat d'abast exclòs és el més important del document i el que tothom deixa en blanc. Escriure «no hi haurà pagaments», «no hi haurà app mòbil», «no hi haurà multiidioma», «no hi haurà rols més enllà d'admin i usuari», «no hi haurà notificacions per correu reals» és el que et salva d'aquí a tres setmanes, quan et vingui de gust afegir qualsevol d'aquestes coses.

Aquests sis són obligatoris. Sigui quin sigui el teu problema, han d'existir. Estan formulats com a llista verificable: cadascun té un criteri de «fet» comprovable amb una comanda.

Detall de cadascun:

RF-1 — Aplicació web contenidoritzada. Contenidoritzada vol dir que existeix un Dockerfile i que la imatge es construeix a CI, no al teu portàtil. La recomanació per defecte és Cloud Run (07-02): escala a zero, no pagues quan ningú no la fa servir, i el contracte és senzill. Si tries GKE, que sigui perquè tens un motiu escrit, no per lluir-te: un clúster encès es menja el pressupost del projecte sencer.

RF-2 — Emmagatzematge d'objectes. No val un bucket buit creat per complir. Ha de formar part del flux: l'usuari puja alguna cosa, o l'aplicació serveix alguna cosa des d'allà. Aplica el de 02-02: accés uniforme a nivell de bucket, res públic tret del que ho hagi de ser, i una regla de cicle de vida encara que sigui trivial.

RF-3 — Base de dades gestionada. Gestionada, no un contenidor amb PostgreSQL dins. L'arbre de decisió de 02-06 et diu quina: relacional amb transaccions → Cloud SQL; documents amb accés per clau i escalat a zero → Firestore. Per a la majoria d'aquests projectes, Cloud SQL PostgreSQL a la instància més petita o Firestore són les respostes correctes.

RF-4 — Ingesta o processament. És el requisit que més gent interpreta de menys. No n'hi ha prou que l'app escrigui a la BD. Hi ha d'haver un flux asíncron o programat que porti dades d'un lloc a un altre: un topic de Pub/Sub que recull esdeveniments, un job de Cloud Run que cada nit bolca a BigQuery, una funció que es dispara en pujar un fitxer. És la peça que demostra que entens la diferència entre el pla operatiu i l'analític (04-01, 04-04).

RF-5 — Tauler de control. Quatre visualitzacions que responguin preguntes, no quatre gràfics bonics. «Quin refugi té més cancel·lacions?» és una pregunta. «Distribució de reserves» no ho és. Looker Studio sobre BigQuery és gratis i suficient (04-07).

RF-6 — Component d'IA. Comença sempre per una API preentrenada. Vision, Natural Language o Gemini resolen el requisit en dues hores i funcionen. Entrenar un model propi amb Vertex AI és opcional, costa diners i és la font número u de projectes que no s'acaben. Si et sobra temps al final, aleshores sí: substitueix l'API per un model teu i documenta la comparació amb la línia base, exactament com va fer la Lucía a DA-003.

Aquí és on aquest projecte se separa d'una demo. Vuit requisits, tots obligatoris, tots verificables:

Els tres que la gent es salta i no hauria:

RNF-1 (IaC de debò). El criteri no és «tinc uns fitxers .tf». El criteri és que el sistema es reconstrueix des de zero. La prova es fa a 08-04 i és implacable: destrueixes l'entorn de desenvolupament sencer i el tornes a crear. Si no arrenca, el teu IaC no era IaC: era documentació amb sintaxi de Terraform.

RNF-3 (sense claus JSON). Aquesta és la que més et diferenciarà. La majoria de projectes de porfolio tenen un credentials.json al repositori o, en el millor dels casos, al .gitignore. Configurar Workload Identity Federation entre GitHub Actions o Cloud Build i GCP costa mitja hora la primera vegada i és exactament el que fa un professional. I recorda el cas d'AlpinaShop: una clau perduda durant catorze mesos.

RNF-7 (SLO). Un SLO no és «vull que vagi ràpid». És: «el 99 % de les peticions a /api/* responen en menys de 800 ms, mesurat sobre finestra de 28 dies». Amb el seu pressupost d'error calculat i visible. Ocupa una tarda i és del que més impressiona en una entrevista, perquè gairebé ningú de nivell júnior no sap formular-lo.

Fixa ara un límit mensual i escriu-lo. El projecte ha de poder construir-se i mantenir-se dins del crèdit de prova de Google Cloud (300 USD / 90 dies en el moment d'escriure això — verifica-ho, les condicions canvien) o, si el crèdit se t'ha esgotat, per sota d'un límit mensual que fixes tu.

Valors de referència raonables:

Per què la restricció és part de l'exercici i no un inconvenient. Qualsevol pot construir una arquitectura que funcioni amb diners infinits. El que distingeix un bon enginyer del núvol és construir-la amb els diners que hi ha. La restricció de cost t'obligarà a prendre exactament les decisions que es prenen en una empresa real:

• Escalar a zero en comptes de tenir capacitat reservada (Cloud Run vs. MIG).
• Triar la instància més petita que compleix, i mesurar si compleix.
• Apagar els entorns de desenvolupament a la nit.
• Particionar les taules de BigQuery per no escanejar 1,2 TB cada vegada que s'obre el tauler.
• No deixar un clúster de GKE encès «per provar».
• Posar cicle de vida als buckets des del dia u.
• Retenir registres 30 dies i no 400.

Tot això és 07-05 aplicat a la teva butxaca, que és la millor manera d'aprendre-ho.

Abans de crear un sol recurs. Literalment el primer dia, abans que res:

I l'avís que cal repetir sempre: un pressupost avisa, no impedeix. Si deixes encès alguna cosa cara, el pressupost t'envia un correu mentre el comptador continua pujant. El que impedeix de debò són les quotes (07-07) i el costum de mirar l'informe de facturació cada pocs dies. Posa't un recordatori: cada dimarts i cada dissabte, obrir l'informe de costos. Trenta segons.

⚠️ Tots els preus d'aquest mòdul són ordres de magnitud, no tarifes. Els preus de Google Cloud canvien, varien per regió i depenen de descomptes i del nivell gratuït. Consulta sempre la calculadora oficial i la pàgina de preus del servei abans de comprometre una xifra al teu document d'arquitectura.

Set lliurables. Els tres primers són el projecte; els quatre següents són el que fa que el projecte es pugui avaluar i defensar.

Estructura del repositori (es detalla a 08-03, però decideix-la ja):

Crea aquest esquelet avui, encara que estigui buit. Els directoris buits amb un README.md d'una línia que digui què hi anirà valen més que la millor intenció d'organitzar-ho després.

Aquesta és la rúbrica amb la qual t'autoavaluaràs a 08-05. Llegeix-la ara, perquè saber com et puntuaran canvia el que construeixes.

100 punts, repartits en set blocs:

A. Disseny i decisions (20 punts)

B. Implementació funcional (20 punts) — 3 punts per requisit funcional complert (18) + 2 punts si el flux complet funciona d'extrem a extrem sense intervenció manual.

C. Infraestructura com a codi (15 punts)

D. Seguretat i identitat (15 punts)

E. Lliurament i proves (10 punts)

F. Observabilitat, SLO i cost (10 punts)

G. Documentació i presentació (10 punts)

Aquesta darrera línia no és cap broma. L'autoavaluació honesta és part de la nota: a 08-05 veuràs que reconèixer i prioritzar el deute tècnic suma punts, i amagar-lo els resta.

Estimació per a un projecte de dificultat mitjana, primera vegada, treballant sol:

Multiplica per 1,5 si és el teu primer projecte al núvol. No és pessimisme: és l'observació empírica que la primera vegada que configures Workload Identity Federation hi trigues dues hores i la segona, quinze minuts.

Les quatre fites són punts de control, no adorns. A cadascuna t'atures i comproves:

Si vas amb retard, retalla funcionalitat, mai requisits no funcionals. Una aplicació amb dues pantalles, IaC completa i seguretat impecable puntua molt per sobre d'una amb vuit pantalles i un credentials.json al repositori.

Aquests cinc no són «errors habituals». Són les cinc causes per les quals els projectes de porfolio no s'acaben. Reconeix-los ara i tindràs la meitat de la feina feta.

Com es manifesta. La setmana 2 afegeixes «seria fàcil encabir-hi també pagaments». La setmana 3, notificacions. La setmana 4, una app mòbil. La setmana 6 tens nou coses a mitges i cap acabada.

Per què passa. Perquè afegir funcionalitat és divertit i acabar no ho és. I perquè l'abast exclòs no estava escrit.

La contramesura. La llista d'exclusions de l'apartat 4, escrita i signada per tu el primer dia. Quan se t'acudeixi alguna cosa nova, no la descartis: apunta-la en un apartat ## Següents passos del README. Això converteix la temptació en un lliurable de la presentació, on puntua.

Com es manifesta. El dia u obres l'editor i comences l'aplicació. Tres setmanes després tens una app bonica i cap infraestructura, cap IaC, cap seguretat. I aleshores intentes «ficar-li Terraform» a una cosa que ja existeix, que és el doble de feina.

Per què passa. Perquè programar és el que saps fer i la resta fa mandra.

La contramesura. L'ordre de 08-03: organització → xarxa → identitat → estat → dades → aplicació. L'aplicació és la fase 4 de 8, no la 1. I hi ha una raó tècnica dura: el projectId no es pot canviar i la xarxa no es pot refer sense destruir-ho tot. El que es decideix primer és el que és car de canviar.

Com es manifesta. Tot amb roles/owner «perquè funcioni ara», una clau JSON descarregada «temporalment», la contrasenya de la BD en una variable del codi. L'última setmana intentes arreglar-ho, ho trenques tot i acabes deixant-ho com estava.

Per què passa. Perquè el mínim privilegi fa mal al principi: cada permís que falta és un error 403 i mitja hora de depuració.

La contramesura. Començar restrictiu i obrir només el que falla. gcloud policy-troubleshoot et diu exactament quin permís falta (ho tens a 03-04). Fa mal la primera setmana i no fa mal mai més. I el bloc D de la rúbrica val 15 punts que es perden sencers si fas això malament.

Com es manifesta. Deixes un clúster de GKE encès un cap de setmana. O un job de Dataflow en streaming. O una instància de Cloud SQL gran «perquè vagi ràpid». El dilluns tens 180 € gastats i el crèdit de prova a la meitat.

Per què passa. Perquè al núvol no veus el maquinari. Un servidor apagat a casa teva no consumeix; una VM encesa al núvol sí, encara que no la facis servir.

La contramesura. Tres coses, totes de l'apartat 7: el pressupost creat abans que res, la revisió de l'informe de costos dues vegades per setmana, i el costum de destruir l'entorn de desenvolupament quan no el facis servir. Això últim és un superpoder que només tens si el teu IaC és de debò:

Si això funciona, el teu projecte de desenvolupament costa zero quan no treballes. I de passada estàs executant la prova més dura de RNF-1 cada setmana, gratis.

Com es manifesta. L'última setmana t'asseus a escriure el document d'arquitectura i no recordes per què vas triar Firestore en comptes de Cloud SQL. Escrius una justificació inventada a posteriori, que es nota, i que a més potser no és la raó real.

Per què passa. Perquè documentar sembla que no fa avançar el projecte.

La contramesura. El docs/diario.md. Cada sessió de treball, tres línies:

Tres línies per sessió, vint sessions: seixanta línies que es converteixen soles en el document d'arquitectura, en els ADR i en la meitat de la presentació. És la inversió amb millor retorn de tot el mòdul.

L'últim és el risc de debò. La mitigació real contra l'abandonament és que el projecte sigui petit i et vingui de gust, que és el que deien els criteris 2 i 5.

Passaràs una part substancial del projecte llegint documentació. Fer-ho bé és una habilitat, i aquestes són les regles:

1. La documentació oficial és la font. Tota la resta és context. Un blog de 2021, una resposta d'Stack Overflow de 2019 o un vídeo de YouTube poden ajudar-te a entendre un concepte, però no per copiar comandes: la CLI canvia, els rols es reanomenen, els serveis es deprequen. El curs mateix, per molt actualitzat que estigui a 2026, és una foto d'un moment.

2. Les quatre seccions que cal conèixer de cada servei:

La secció de quotes i límits és la que menys gent llegeix i la que més disgustos evita. Saber que Cloud Run té un límit de temps de petició, o que BigQuery té un màxim d'operacions de taula al dia, canvia el disseny.

3. El registre de Terraform és tan important com la documentació de GCP. Per a cada recurs que creïs, registry.terraform.io/providers/hashicorp/google/latest/docs et dona els arguments exactes, quins són obligatoris, quins forcen recreació del recurs (ForceNew) i què es pot importar. Aquest ForceNew és la diferència entre un apply de 20 segons i un que destrueix la teva base de dades.

4. Les notes de versió existeixen. Cada servei té la seva pàgina de release notes. Abans de donar per perduda una funcionalitat, mira si va sortir el mes passat.

5. Quan la documentació i el missatge d'error es contradiuen, guanya el missatge d'error. I quan el missatge d'error diu «permission denied», gairebé sempre té raó: no és un bug, et falta un permís.

T'encallaràs. Diverses vegades. El mètode següent resol la gran majoria de bloquejos en menys de vint minuts, i l'important és aplicar-lo en ordre en comptes de provar coses a l'atzar:

Pas 1 — Llegeix l'error sencer. Complet, fins al final, inclòs el details i l'enllaç que de vegades inclou. La meitat dels errors de GCP diuen literalment quin permís falta o quina API cal activar.

Pas 2 — Està activada l'API? És la causa número u d'errors inexplicables la primera setmana:

Pas 3 — És un permís? Si l'error conté 403, PERMISSION_DENIED o does not have permission, és un permís, sense excepció:

Pas 4 — És la xarxa? Si el símptoma és un temps d'espera esgotat i no un rebuig, és xarxa:

Pas 5 — El recurs és com et penses? Un describe desmunta la meitat de les hipòtesis equivocades:

I si al cap de vint minuts continues igual: canvia de tasca. Documenta el bloqueig a docs/diario.md amb l'error exacte i el que ja has provat, i vés-te'n a una altra fase. Tornar-hi l'endemà amb el cap fred resol més bloquejos que insistir tres hores seguides. Aquest consell sembla d'autoajuda i és purament estadístic.

Abans de passar a 08-02, cinc coses. No són opcionals i no porten més de dues hores:

• [ ] Triar el problema. Una de les quatre propostes o el teu, validat amb la plantilla de l'apartat 4.
• [ ] Escriure la frase. Una frase sense «i». Enganxa-la a la primera línia del README.
• [ ] Escriure les cinc exclusions. El que el teu projecte no farà.
• [ ] Fixar el límit de cost. Un número en euros al mes, escrit al README.
• [ ] Crear el repositori amb l'esquelet de carpetes i el primer commit.

Si no pots fer les cinc avui, el teu problema encara no està triat. Torna a l'apartat 2.

Triar un problema que no entens perquè sona impressionant. «Plataforma d'anàlisi de risc creditici amb IA» sona millor que «reserves de refugis» fins que et toca modelar el risc creditici. En una entrevista, un projecte senzill ben explicat guanya sempre a un de complex que balbucejes.

Confondre «complet» amb «gran». El projecte s'avalua per capes cobertes, no per funcionalitat. Dues pantalles amb IaC, CI/CD, SLO i seguretat valen 80 punts; quinze pantalles sense res d'això valen 45.

Crear els projectes de GCP abans d'haver llegit 08-02. El projectId és immutable. Si crees test-1234 perquè tenies pressa, ho ensenyaràs a l'entrevista. Espera't a la lliçó de disseny, on es decideix la convenció de noms.

Fer servir el crèdit de prova com si fos infinit. 300 USD semblen molt fins que deixes un GKE encès: un clúster estàndard de tres nodes es menja uns 100 € al mes ell sol. Cloud Run escala a zero; GKE Autopilot no costa zero però costa poc; GKE estàndard costa des del minut u.

Deixar el component d'IA per al final i triar entrenar un model. És l'ordre invers al correcte: posa l'API preentrenada a la fase 6 (dues hores, funciona) i només si sobra temps, substitueix-la per un model propi. Un component d'IA senzill que funciona val els 3 punts; un d'ambiciós a mitges val 0.

No llegir la rúbrica fins al final. La rúbrica és el plec. Tot el que facis que no estigui a la rúbrica és temps que no puntua. Tingues-la oberta en una pestanya durant tot el mòdul.

Consell: fes un git commit al final de cada sessió, encara que no funcioni. L'historial de commits és un lliurable en si mateix: un repositori amb 60 commits distribuïts en sis setmanes explica una història de feina real. Un amb 3 commits gegants n'explica una altra.

Consell: desa totes les captures i tots els números des del principi. La captura del tauler el dia que va funcionar, el resultat de la primera prova de càrrega, la factura del primer mes. A 08-05 els necessitaràs i reconstruir-los és impossible.

Consell: posa una alarma real al calendari. Dues sessions fixes per setmana, al calendari, amb nom. Els projectes personals no moren per dificultat tècnica: moren perquè mai no hi ha un moment.

Els exercicis d'aquest mòdul són fites del teu propi projecte. Les solucions mostren la mateixa fita resolta sobre RefugioReserva, el projecte de referència, perquè tinguis un model sense poder copiar el teu.

Tria el teu problema i omple la plantilla de validació de l'apartat 4 completa: nom, frase d'una línia sense «i», el problema amb el seu usuari, abast inclòs (màxim 5 punts), abast exclòs (mínim 5 punts), la taula de com compleixes els sis requisits funcionals, l'origen i volum de les dades fictícies i el risc principal.

Després, puntua la teva idea amb la taula de decisió dels cinc criteris. Si algun criteri treu menys de 3, canvia d'idea o ajusta-la fins que pugi.

Decideix el teu límit mensual, justifica'l en dues línies i crea el pressupost real al teu compte de facturació amb llindars al 50, 90 i 100 %. Documenta en una taula quins serveis esperes fer servir, amb quina configuració mínima i quin ordre de magnitud de cost tens al cap (l'afinaràs a 08-02 amb la calculadora).

A més, escriu la resposta a aquesta pregunta: si d'aquí a tres setmanes descobreixes que vas al 200 % del teu límit, què és el primer que apagues? Aquest ordre de prioritat escrit per endavant és el que et salva de decidir amb pressa.

Adapta el cronograma de l'apartat 10 a la teva disponibilitat real (hores per setmana que pots dedicar de debò, no les que t'agradaria). Produeix un diagrama mermaid amb les teves dates i les teves quatre fites, i per a cada fita escriu el seu criteri de pas i què retallaries si no el compleixes.

Crea el repositori amb l'esquelet de carpetes de l'apartat 8, el README.md amb la frase del projecte, les exclusions i el límit de cost, i el docs/diario.md amb la seva primera entrada. Fes el primer commit.

Solució 1 — Definició i acotació de RefugioReserva

Puntuació amb la taula de decisió:

Solució 2 — Restricció de cost de RefugioReserva

Límit fixat: 12 € al mes. Justificació: el crèdit de prova ja està consumit, i vull que el projecte pugui quedar-se encès indefinidament com a peça de porfolio sense que em faci mal. 12 € és aproximadament el que costa un domini (prorratejat) més una instància mínima de base de dades.

Totes aquestes xifres són ordres de magnitud a data d'escriptura i per a europe-west1. Cal refer-les amb la calculadora oficial a 08-02 abans de donar el disseny per bo.

Si arribo al 200 % (24 €/mes), aquest és l'ordre d'apagada, decidit per endavant:

1. Apagar Cloud SQL fora de l'horari de treball amb un job programat (arrenca a les 9, s'atura a les 23). Estalvi immediat: ~60 % de la partida gran. Risc: la demo no funciona de matinada; assumible.
2. Reduir la retenció de registres a 7 dies i desactivar els registres d'accés a dades si els hagués activat.
3. Buidar Artifact Registry deixant només les 3 últimes imatges.
4. Migrar de Cloud SQL a Firestore. És la mesura nuclear: elimina el 80 % del cost però implica refer la capa de dades. Només si les tres anteriors no basten, i seria un ADR nou amb les seves conseqüències.
5. Destruir l'entorn de desenvolupament i treballar només contra producció, amb més cura.

El que no faria: treure el balancejador o el certificat (trenca RNF-5), ni desactivar el monitoratge (trenca RNF-6). Retallar requisits no funcionals per estalviar 2 € és canviar 15 punts de rúbrica pel preu d'un cafè.

Solució 3 — Pla i terreny de RefugioReserva

Disponibilitat real declarada: 8 hores per setmana (dues tardes de 2 h entre setmana + 4 h el dissabte). Sobre una estimació de 50 hores, en surten 7 setmanes amb una mica de marge, no 6. És preferible reconèixer-ho ara que anar amb retard des de la setmana 1.

El terreny preparat:

Fixa't en dos detalls del .gitignore: *.tfvars i *credentials*.json. El primer evita pujar valors per entorn que de vegades porten secrets; el segon és una xarxa de seguretat per si algun dia, amb pressa, descarregues una clau. No n'hauries de descarregar cap —RNF-3—, però la xarxa de seguretat no fa nosa.

I fixa't sobretot en l'última línia del diari: no crear encara cap projecte de GCP. És la disciplina que separa aquest mòdul d'un tutorial.

Ja tens el plec de condicions complet.

Saps què se't demana: una plataforma completa de principi a fi, no una demo, amb totes les capes del curs connectades i explicades. I saps què no se't demana, que és igual d'important: ni bellesa, ni escala, ni models propis, ni alta disponibilitat.

Saps triar el problema amb cinc criteris per ordre —domini conegut, abast en una frase sense «i», dades inventables, diverses capes naturals i que et vingui de gust— i tens quatre propostes desenvolupades amb les seves dades, la seva dificultat i els seus riscos, a més de l'opció de portar la teva amb una regla que no es negocia: dades reals, mai, ni «anonimitzades», ni de la teva empresa, per motius legals, contractuals i pràctics.

Tens els sis requisits funcionals amb el seu criteri de «fet» i la comanda que ho verifica, i els vuit no funcionals que separen un projecte d'una demo: IaC reproduïble, CI/CD amb prova, mínim privilegi sense claus JSON, secrets gestionats, HTTPS propi, tauler i alerta, un SLO mesurat i un pressupost amb avís.

Tens la restricció de cost entesa com el que és: no un inconvenient, sinó el requisit que t'obliga a prendre les mateixes decisions que es prenen en una empresa —escalar a zero, la instància més petita que compleix, particionar, apagar el que no es fa servir— i amb el recordatori que un pressupost avisa però no impedeix.

Tens els set lliurables amb el seu format i la seva ubicació, la rúbrica de 100 punts repartida en set blocs amb criteris verificables un a un, i la lectura honesta de la puntuació, inclòs l'avís que un 98 probablement vol dir que t'has puntuat amb benevolència.

Tens la planificació: 48-75 hores repartides en deu fases, un cronograma de referència amb quatre fites i, a cadascuna, el seu criteri de pas i què retallar si no hi arribes —sempre funcionalitat, mai requisits no funcionals.

I tens els cinc errors que enfonsen un projecte final, amb el seu símptoma, la seva causa i la seva contramesura: abast excessiu (exclusions escrites), començar pel codi (l'ordre de fases, perquè el projectId no es canvia), seguretat al final (restrictiu des del dia u i policy-troubleshoot com a aliat), oblidar el cost (pressupost primer i destroy els divendres) i no documentar sobre la marxa (tres línies de diari per sessió, la inversió amb millor retorn del mòdul).

A la propera lliçó, 08-02, passes del plec al plànol: traduir cada requisit a un servei concret amb la seva justificació i la seva alternativa descartada, dibuixar els tres diagrames que serveixen, decidir l'estructura de projectes i la convenció de noms abans de crear res, dissenyar la xarxa i la identitat sobre paper, modelar les dades amb el seu cicle de vida, estimar el cost amb la calculadora i comparar-lo amb el teu límit, definir els teus SLO i escriure els teus primers ADR.

I no toquis la consola de GCP fins llavors. El projectId no es canvia.