Has construït un sistema complet. Funciona, està provat, està mesurat i costa el que vas dir que costaria.

I ara ve la part que gairebé ningú no prepara i que decideix la meitat del resultat: explicar-ho.

Això no és cap adorn ni cap tràmit acadèmic. És una observació repetida en qualsevol procés de selecció tècnic: de dos candidats amb projectes equivalents, el que pot explicar en tres minuts per què va triar Cloud Run en lloc de GKE, quant li costa al mes i què passa quan cau la base de dades aconsegueix la feina; el que ensenya una URL i diu «està fet amb Google Cloud», no. La feina tècnica és la mateixa. La diferència és que un dels dos va fer la feina de comunicar-la.

Hi ha una raó estructural per a això. En qualsevol organització, les decisions tècniques les pren gent que no ha construït el sistema: un responsable que decideix el pressupost, un company que l'haurà de mantenir, un entrevistador que té quaranta minuts. Si la teva feina només existeix al teu cap i al repositori, per a tots ells no existeix. Comunicar no és vendre: és fer que la feina sigui utilitzable per altres.

Aquesta lliçó cobreix les set peces: els tres públics i com canvia el missatge per a cadascun, l'estructura de la presentació diapositiva a diapositiva, com ensenyar una arquitectura sense perdre ningú, la demostració amb el seu guió i el seu pla B, com parlar de xifres, la documentació lliurable amb plantilles llestes per copiar, l'autoavaluació honesta amb la rúbrica de 08-01, les preguntes que et faran amb respostes model, la revisió entre iguals i la neteja final.

1. Per què comunicar la feina és part de la feina
2. Els tres públics
3. L'estructura de la presentació, diapositiva a diapositiva
4. Com ensenyar l'arquitectura
5. La demostració
6. Parlar de xifres
7. La documentació lliurable
8. L'autoavaluació amb la rúbrica
9. Les preguntes que et faran
10. La revisió entre iguals
11. La neteja final
12. El guió de presentació de RefugioReserva

Abans del que cal fer, el que cal evitar. Tots quatre són extraordinàriament comuns:

L'antídot dels quatre és el mateix: decisions i xifres. «Vaig triar Cloud Run en lloc de GKE perquè el clúster costava 100 € al mes des del minut u i no necessitava res de Kubernetes; el sistema em costa 10,20 € i aguanta 100 usuaris concurrents amb un p95 de 634 ms» no és un catàleg, no és un tutorial, no es disculpa i no exagera. És verificable.

No estàs demostrant que saps fer servir Google Cloud. Estàs demostrant cinc coses, i només una d'elles és tècnica:

1. Que prens decisions i les justifiques. L'habilitat més valorada i la més rara.
2. Que coneixes les restriccions. Cost, temps, complexitat. Un enginyer sense restriccions no és un enginyer.
3. Que acabes les coses. Un projecte complet, encara que petit, val més que tres a mitges.
4. Que saps el que no saps. El deute tècnic reconegut és senyal de maduresa.
5. Que pots treballar amb altres. Documentació, ADR, runbook: tot això és per als altres.

La mateixa arquitectura, tres presentacions diferents. No és maquillatge: és que els tres públics necessiten respondre preguntes diferents.

Cinc frases, zero argot:

«La federació gestionava 12 refugis per telèfon i amb fulls de càlcul. Tenien set sobrevendes l'any i cap dada per decidir on invertir. Ara les reserves es fan soles, la sobrevenda és impossible per disseny, i hi ha un tauler de control amb l'ocupació de cada refugi. Costa 10 € al mes i es pot apagar sencer en cinc minuts si deixés d'interessar.»

Fixa't en el que no hi apareix: ni Cloud Run, ni Terraform, ni PostgreSQL. I en el que sí: el problema en els seus termes, el resultat en els seus termes, el cost, i la reversibilitat —que a un directiu li importa més del que sembla, perquè la seva por no és que no funcioni, és quedar-se atrapat.

La traducció de termes tècnics a termes de negoci:

Aquí sí que entres en detall, però l'eix continua sent per què, no què. El que un company vol saber: quins compromisos vas acceptar, què es trenca primer quan alguna cosa falla, on és el deute i com s'opera això un dimarts a les vuit del vespre.

La secció que més valoren, i que gairebé ningú no prepara: «el que faria diferent».

En una entrevista, el projecte és un pretext per parlar de com penses. L'entrevistador no auditarà el teu Terraform: et preguntarà per què, què vas descartar, què passa si, i quant costa.

L'estructura de 90 segons que has de tenir memoritzada (te la demanaran literalment: «explica'm un projecte teu»):

«[Problema, 15 s] Vaig construir una plataforma de reserves per a una federació fictícia de refugis de muntanya, que gestionava 12 refugis per telèfon i tenia sobrevendes.

[Arquitectura, 20 s] És una aplicació a Cloud Run contra PostgreSQL gestionat amb IP privada, amb les fotos a Cloud Storage, els esdeveniments per Pub/Sub cap a BigQuery i un tauler de control a Looker Studio. Tot en Terraform, desplegat per CI/CD sense claus.

[La decisió interessant, 30 s] La decisió que més em va fer pensar va ser la base de dades. Firestore era gratis i Cloud SQL em costava 8 € al mes d'un pressupost de 12. Vaig triar Cloud SQL perquè el cor del problema és el control d'aforament, i necessitava una transacció amb bloqueig de fila: vaig escriure una prova de concurrència amb vint fils barallant-se per l'última plaça, i amb la implementació ingènua set aconseguien reservar-la. Vaig compensar el cost apagant la base a la nit.

[Les xifres, 15 s] Em costa 10,20 € al mes, aguanta 100 usuaris concurrents amb un p95 de 634 ms, es reconstrueix sencer des de zero en 14 minuts i he assajat la reversió: 38 segons.

[L'honestedat, 10 s] El que vaig deixar fora expressament: no hi ha WAF, perquè el balancejador costava més que tot el projecte junt. Està documentat com a deute amb la seva condició de revisió.»

Noranta segons. Cinc blocs. Ni una llista de serveis, i tanmateix se'n mencionen set. Cada afirmació és verificable, i l'última convida a preguntar en lloc d'amagar.

Tretze diapositives, 10-15 minuts. Aquesta és la versió completa (públic tècnic o mixt); per a direcció es fan servir les diapositives 1, 2, 6, 7 i 12.

Diapositiva 2 — El problema. Necessita una dada concreta. «Gestionaven les reserves per telèfon» és fluix; «gestionaven les reserves per telèfon entre les 18:00 i les 20:00, amb un full de càlcul per refugi, i van tenir set sobrevendes l'any passat» fa que el públic entengui el dolor en cinc segons.

Diapositiva 3 — Abast. La meitat de la diapositiva és allò exclòs. Ensenyar que vas decidir no fer pagaments, ni app mòbil, ni multiidioma demostra gestió d'abast, que és una habilitat d'enginyeria tan valuosa com escriure codi. I desactiva per endavant la pregunta «i per què no vas fer X?».

Diapositiva 5 — Decisions clau. Dos minuts, tres decisions, en format de taula:

Aquesta és la diapositiva que més es recorda. Si només en poguessis ensenyar una, seria aquesta. La columna «vaig descartar» és la que demostra que hi va haver pensament.

Diapositiva 11 — El que no va funcionar. Contraintuïtiva i molt efectiva. Conté els teus incidents reals amb el seu post mortem i el teu deute tècnic prioritzat. La raó per la qual funciona: tothom sap que un sistema real té problemes. Un projecte presentat com a perfecte es llegeix com un projecte poc utilitzat o poc entès. I cap altra diapositiva no genera tantes preguntes bones.

El títol de cada diapositiva ha de ser la conclusió, no el tema. «Cost» és un tema. «10,20 €/mes, un 62 % menys que el disseny inicial» és una conclusió: si el públic només llegeix els títols, ja s'ha endut la teva presentació sencera.

No ensenyis mai els tres alhora, ni cap que barregi nivells. Tria segons el públic:

L'error més comú en presentar una arquitectura és recórrer les caixes: «aquí tenim Cloud Run, que es connecta a Cloud SQL, i també publica a Pub/Sub, que al seu torn…». El públic ja veu les caixes. Està llegint mentre parles, i li estàs competint amb la teva pròpia diapositiva.

En lloc de llegir-lo, explica un recorregut. Un usuari fent alguna cosa:

«Un excursionista entra, busca places per al 15 d'agost. La petició arriba a Cloud Run, que consulta PostgreSQL —aquesta consulta és la que té l'índex parcial, perquè és la que es fa mil vegades—. Reserva. Aquí passen dues coses alhora: s'escriu la reserva a la base de dades dins d'una transacció amb bloqueig, que és el que impedeix la sobrevenda, i es publica un esdeveniment. L'usuari ja té la seva resposta. L'esdeveniment segueix el seu camí per Pub/Sub fins a BigQuery, i trenta segons després la federació veu la reserva al seu tauler de control. Aquesta separació és deliberada: l'usuari no espera l'analítica.»

Un minut i mig, zero enumeracions, i el públic ha entès el sistema i dues decisions de disseny.

1. Què està exposat a internet i què no.
2. Per on entren les dades i on acaben.
3. Què és síncron (l'usuari espera) i què és asíncron (l'usuari no espera).

Si el teu diagrama no deixa això clar sense explicació, refes-lo abans de presentar.

Tres minuts. L'ordre importa perquè l'impacte és acumulatiu:

Cap dels tres no és funcionalitat. Tots tres són operació, que és exactament el que separa un projecte d'una demo:

1. Un desplegament complet, en directe. Canvies una línia, fas git push, i a pantalla es veu el pipeline: proves → construcció → desplegament → prova de fum. Quatre minuts de rellotge, així que es llança al principi de la demostració i s'hi torna al final. L'efecte és difícil d'exagerar: la majoria de projectes de porfolio es despleguen a mà.

2. Una alerta disparant-se. Provoques errors, esperes, i ensenyes el correu arribant amb els primers passos escrits. Demostra que el sistema t'avisa, que és el que separa observabilitat de gràfics bonics.

3. Una reversió. És el més impressionant dels tres i el més ràpid. Despleges una versió trencada expressament, el públic veu l'error, executes ./scripts/revertir.sh, i en 38 segons el sistema està sa. Cronòmetre a pantalla.

Tria'n un. Tots tres no hi caben, i el tercer és el que més diu de tu en menys temps.

Escriu-lo. Literalment, amb els temps:

Les tres regles d'una demostració que no falla:

1. Assaja-la tres vegades, l'última sencera i sense parar. Descobriràs que una pestanya trigava a carregar i que el filtre de Looker Studio es reinicia.
2. Tot obert i precarregat abans de començar. Ningú no vol veure't buscar una pestanya.
3. No teclegis mai una URL en directe. Ni escriguis comandes llargues. Tot preparat, només prémer Enter.

Grava la demostració sencera en vídeo, amb narració, i tingues-lo obert i minimitzat. No és pessimisme: és que el wifi d'una sala de reunions falla, un servei de Google té un incident, i el teu compte de prova caduca justament aquell dia.

I si l'has de fer servir, digues-ho amb naturalitat: «El wifi d'aquí no em deixa; tinc la demostració gravada, és exactament el mateix». Ningú no ho penalitza. El que sí que penalitza és passar tres minuts barallant-te amb una pantalla de càrrega.

Un adjectiu és una opinió teva. Una xifra és un fet verificable, i a més demostra tres coses de cop: que ho vas mesurar, que saps d'on surt, i que entens la restricció.

L'última fila és la que millor funciona, i és contraintuïtiva: admetre una fallada trobada i corregida genera més confiança que afirmar que no n'hi ha cap.

Aquesta diapositiva demostra més criteri d'enginyeria que qualsevol diagrama, perquè ensenya decisions sota restricció, que és en què consisteix la feina real.

• Si no ho vas mesurar, no ho diguis. «No ho he mesurat» és una resposta perfectament acceptable; inventar una xifra que no pots sostenir, no.
• Dona el context. «100 usuaris concurrents» sense dir contra quina configuració no significa res.
• Reconeix el que la xifra no cobreix. «Vaig provar 100 usuaris; no sé què passa amb 1.000, encara que ho puc raonar.»

Cinc documents. Cap de llarg, tots útils.

La regla: dos minuts de lectura i qui hi arriba sap què és, si li serveix i com arrencar-ho.