Has construido un sistema completo. Funciona, está probado, está medido y cuesta lo que dijiste que costaría.

Y ahora viene la parte que casi nadie prepara y que decide la mitad del resultado: contarlo.

Esto no es un adorno ni un trámite académico. Es una observación repetida en cualquier proceso de selección técnico: de dos candidatos con proyectos equivalentes, el que puede explicar en tres minutos por qué eligió Cloud Run en lugar de GKE, cuánto le cuesta al mes y qué pasa cuando se cae la base de datos consigue el puesto; el que enseña una URL y dice "está hecho con Google Cloud", no. El trabajo técnico es el mismo. La diferencia es que uno de los dos hizo el trabajo de comunicarlo.

Hay una razón estructural para esto. En cualquier organización, las decisiones técnicas las toma gente que no ha construido el sistema: un responsable que decide el presupuesto, un compañero que va a mantenerlo, un entrevistador que tiene cuarenta minutos. Si tu trabajo solo existe en tu cabeza y en el repositorio, para todos ellos no existe. Comunicar no es vender: es hacer que el trabajo sea utilizable por otros.

Esta lección cubre las siete piezas: los tres públicos y cómo cambia el mensaje para cada uno, la estructura de la presentación diapositiva a diapositiva, cómo enseñar una arquitectura sin perder a nadie, la demostración con su guion y su plan B, cómo hablar de números, la documentación entregable con plantillas listas para copiar, la autoevaluación honesta con la rúbrica de 08-01, las preguntas que te van a hacer con respuestas modelo, la revisión entre iguales y la limpieza final.

1. Por qué comunicar el trabajo es parte del trabajo
2. Los tres públicos
3. La estructura de la presentación, diapositiva a diapositiva
4. Cómo enseñar la arquitectura
5. La demostración
6. Hablar de números
7. La documentación entregable
8. La autoevaluación con la rúbrica
9. Las preguntas que te van a hacer
10. La revisión entre iguales
11. La limpieza final
12. El guion de presentación de RefugioReserva

Antes de lo que hay que hacer, lo que hay que evitar. Los cuatro son extraordinariamente comunes:

El antídoto de los cuatro es el mismo: decisiones y números. "Elegí Cloud Run en lugar de GKE porque el clúster costaba 100 € al mes desde el minuto uno y no necesitaba nada de Kubernetes; el sistema me cuesta 10,20 € y aguanta 100 usuarios concurrentes con un p95 de 634 ms" no es un catálogo, no es un tutorial, no se disculpa y no exagera. Es verificable.

No estás demostrando que sabes usar Google Cloud. Estás demostrando cinco cosas, y solo una de ellas es técnica:

1. Que tomas decisiones y las justificas. La habilidad más valorada y la más rara.
2. Que conoces las restricciones. Coste, tiempo, complejidad. Un ingeniero sin restricciones no es un ingeniero.
3. Que terminas las cosas. Un proyecto completo, aunque pequeño, vale más que tres a medias.
4. Que sabes lo que no sabes. La deuda técnica reconocida es señal de madurez.
5. Que puedes trabajar con otros. Documentación, ADR, runbook: todo eso es para los demás.

La misma arquitectura, tres presentaciones distintas. No es maquillaje: es que las tres audiencias necesitan responder preguntas diferentes.

Cinco frases, cero jerga:

"La federación gestionaba 12 refugios por teléfono y con hojas de cálculo. Tenían siete sobreventas al año y ningún dato para decidir dónde invertir. Ahora las reservas se hacen solas, la sobreventa es imposible por diseño, y hay un cuadro de mando con la ocupación de cada refugio. Cuesta 10 € al mes y se puede apagar entero en cinco minutos si dejara de interesar."

Fíjate en lo que no aparece: ni Cloud Run, ni Terraform, ni PostgreSQL. Y en lo que sí: el problema en sus términos, el resultado en sus términos, el coste, y la reversibilidad —que a un directivo le importa más de lo que parece, porque su miedo no es que no funcione, es quedarse atrapado.

La traducción de términos técnicos a términos de negocio:

Aquí sí entras en detalle, pero el eje sigue siendo por qué, no qué. Lo que un compañero quiere saber: qué compromisos aceptaste, qué se rompe primero cuando algo falla, dónde está la deuda y cómo se opera esto un martes a las ocho de la tarde.

La sección que más valoran, y casi nadie prepara: "lo que haría distinto".

En una entrevista, el proyecto es un pretexto para hablar de cómo piensas. El entrevistador no va a auditar tu Terraform: va a preguntarte por qué, qué descartaste, qué pasa si, y cuánto cuesta.

La estructura de 90 segundos que debes tener memorizada (te la van a pedir literalmente: "cuéntame un proyecto tuyo"):

"[Problema, 15 s] Construí una plataforma de reservas para una federación ficticia de refugios de montaña, que gestionaba 12 refugios por teléfono y tenía sobreventas.

[Arquitectura, 20 s] Es una aplicación en Cloud Run contra PostgreSQL gestionado con IP privada, con las fotos en Cloud Storage, los eventos por Pub/Sub hacia BigQuery y un cuadro de mando en Looker Studio. Todo en Terraform, desplegado por CI/CD sin claves.

[La decisión interesante, 30 s] La decisión que más me hizo pensar fue la base de datos. Firestore era gratis y Cloud SQL me costaba 8 € al mes de un presupuesto de 12. Elegí Cloud SQL porque el corazón del problema es el control de aforo, y necesitaba una transacción con bloqueo de fila: escribí una prueba de concurrencia con veinte hilos peleando por la última plaza, y con la implementación ingenua siete conseguían reservarla. Compensé el coste apagando la base por la noche.

[Los números, 15 s] Me cuesta 10,20 € al mes, aguanta 100 usuarios concurrentes con un p95 de 634 ms, se reconstruye entero desde cero en 14 minutos y he ensayado la reversión: 38 segundos.

[La honestidad, 10 s] Lo que dejé fuera a propósito: no hay WAF, porque el balanceador costaba más que todo el proyecto junto. Está documentado como deuda con su condición de revisión."

Noventa segundos. Cinco bloques. Ni una lista de servicios, y sin embargo se mencionan siete. Cada afirmación es verificable, y la última invita a preguntar en vez de esconder.

Trece diapositivas, 10-15 minutos. Esta es la versión completa (público técnico o mixto); para dirección se usan las diapositivas 1, 2, 6, 7 y 12.

Diapositiva 2 — El problema. Necesita un dato concreto. "Gestionaban las reservas por teléfono" es flojo; "gestionaban las reservas por teléfono entre las 18:00 y las 20:00, con una hoja de cálculo por refugio, y tuvieron siete sobreventas el año pasado" hace que la audiencia entienda el dolor en cinco segundos.

Diapositiva 3 — Alcance. La mitad de la diapositiva es lo excluido. Enseñar que decidiste no hacer pagos, ni app móvil, ni multiidioma demuestra gestión de alcance, que es una habilidad de ingeniería tan valiosa como escribir código. Y desactiva de antemano la pregunta "¿y por qué no hiciste X?".

Diapositiva 5 — Decisiones clave. Dos minutos, tres decisiones, en formato de tabla:

Esta es la diapositiva que más se recuerda. Si solo pudieras enseñar una, sería esta. La columna "descarté" es la que demuestra que hubo pensamiento.

Diapositiva 11 — Lo que no funcionó. Contraintuitiva y muy efectiva. Contiene tus incidentes reales con su post-mortem y tu deuda técnica priorizada. La razón por la que funciona: todo el mundo sabe que un sistema real tiene problemas. Un proyecto presentado como perfecto se lee como un proyecto poco usado o poco entendido. Y ninguna otra diapositiva genera tantas preguntas buenas.

El título de cada diapositiva debe ser la conclusión, no el tema. "Coste" es un tema. "10,20 €/mes, un 62 % menos que el diseño inicial" es una conclusión: si la audiencia solo lee los títulos, ya se ha llevado tu presentación entera.

Nunca enseñes los tres a la vez, y nunca uno que mezcle niveles. Elige según el público:

El error más común al presentar una arquitectura es recorrer las cajas: "aquí tenemos Cloud Run, que se conecta a Cloud SQL, y también publica en Pub/Sub, que a su vez…". La audiencia ya ve las cajas. Está leyendo mientras hablas, y le estás compitiendo con tu propia diapositiva.

En lugar de leerlo, cuenta un recorrido. Un usuario haciendo algo:

"Un excursionista entra, busca plazas para el 15 de agosto. La petición llega a Cloud Run, que consulta PostgreSQL —esa consulta es la que tiene el índice parcial, porque es la que se hace mil veces—. Reserva. Ahí pasan dos cosas a la vez: se escribe la reserva en la base de datos dentro de una transacción con bloqueo, que es lo que impide la sobreventa, y se publica un evento. El usuario ya tiene su respuesta. El evento sigue su camino por Pub/Sub hasta BigQuery, y treinta segundos después la federación ve la reserva en su cuadro de mando. Esa separación es deliberada: el usuario no espera a la analítica."

Un minuto y medio, cero enumeraciones, y la audiencia ha entendido el sistema y dos decisiones de diseño.

1. Qué está expuesto a internet y qué no.
2. Por dónde entran los datos y dónde acaban.
3. Qué es síncrono (el usuario espera) y qué es asíncrono (el usuario no espera).

Si tu diagrama no deja eso claro sin explicación, rehazlo antes de presentar.

Tres minutos. El orden importa porque el impacto es acumulativo:

Ninguno de los tres es funcionalidad. Los tres son operación, que es exactamente lo que separa un proyecto de una demo:

1. Un despliegue completo, en vivo. Cambias una línea, haces git push, y en pantalla se ve el pipeline: pruebas → construcción → despliegue → prueba de humo. Cuatro minutos de reloj, así que se lanza al principio de la demostración y se vuelve a él al final. El efecto es difícil de exagerar: la mayoría de proyectos de portafolio se despliegan a mano.

2. Una alerta disparándose. Provocas errores, esperas, y enseñas el correo llegando con los primeros pasos escritos. Demuestra que el sistema te avisa, que es lo que separa observabilidad de gráficos bonitos.

3. Una reversión. Es el más impresionante de los tres y el más rápido. Despliegas una versión rota a propósito, la audiencia ve el error, ejecutas ./scripts/revertir.sh, y en 38 segundos el sistema está sano. Cronómetro en pantalla.

Elige uno. Los tres no caben, y el tercero es el que más dice de ti en menos tiempo.

Escríbelo. Literalmente, con los tiempos:

Las tres reglas de una demostración que no falla:

1. Ensáyala tres veces, la última entera y sin parar. Descubrirás que una pestaña tardaba en cargar y que el filtro de Looker Studio se resetea.
2. Todo abierto y precargado antes de empezar. Nadie quiere verte buscar una pestaña.
3. Nunca teclees una URL en vivo. Ni escribas comandos largos. Todo preparado, solo pulsar Enter.

Graba la demostración entera en vídeo, con narración, y tenlo abierto y minimizado. No es pesimismo: es que el wifi de una sala de reuniones falla, un servicio de Google tiene un incidente, y tu cuenta de prueba caduca justo ese día.

Y si tienes que usarlo, dilo con naturalidad: "El wifi de aquí no me deja; tengo la demostración grabada, es exactamente lo mismo". Nadie lo penaliza. Lo que sí penaliza es pasar tres minutos peleándote con una pantalla de carga.

Un adjetivo es una opinión tuya. Un número es un hecho verificable, y además demuestra tres cosas de golpe: que lo mediste, que sabes de dónde sale, y que entiendes la restricción.

La última fila es la que mejor funciona, y es contraintuitiva: admitir un fallo encontrado y corregido genera más confianza que afirmar que no hay ninguno.

Esa diapositiva demuestra más criterio de ingeniería que cualquier diagrama, porque enseña decisiones bajo restricción, que es en lo que consiste el trabajo real.

• Si no lo mediste, no lo digas. "No lo he medido" es una respuesta perfectamente aceptable; inventar una cifra que no puedes sostener, no.
• Da el contexto. "100 usuarios concurrentes" sin decir contra qué configuración no significa nada.
• Reconoce lo que el número no cubre. "Probé 100 usuarios; no sé qué pasa con 1.000, aunque puedo razonarlo."

Cinco documentos. Ninguno largo, todos útiles.

La regla: dos minutos de lectura y quien llega sabe qué es, si le sirve y cómo arrancarlo.