ruta backend / módulo 0

M0 — Producto

Transversal: no se estudia una vez, enmarca todos los demás módulos.

Outcome del módulo: poder abrir cualquier sistema con Necesidad → HU → Usuario → Criterios → Métrica y defender por qué existe cada feature — sin hablar de código.

Por qué está en un curso de backend: el ingeniero que solo ejecuta tickets construye lo que le piden; el senior/dueño pregunta para qué y cómo sabremos que funcionó. Es el mismo instinto del Paso 1 de System Design (clarificar antes de diseñar).

Concepto 1 — Necesidad → HU → producto

Idea núcleo: no se entrega software suelto. Cada cosa que construís nace de una necesidad y se expresa como historia de usuario antes de ser código.

Entender (capa 1)

Texto: la cadena es Necesidad (dolor real) → HU (quién quiere qué y para qué) → Criterios de aceptación → Producto (api/web/app = materialización). Saltarse la necesidad = construir features que nadie pidió.

Visual:

flowchart LR
    N[Necesidad · dolor real] --> HU[HU · como X quiero Y para Z] --> AC[Criterios de aceptación] --> P[Producto · materialización]

Video: How To Write User Stories, Epics & Personas — freeCodeCamp.org

Ejemplo:

Necesidad: el tendero pierde ventas fiadas porque las anota en un cuaderno que se moja/pierde.
HU: como tendero quiero registrar un fiado por voz para no frenar la atención.
Criterio: registrar un fiado en < 5s sin escribir; consultar saldo por cliente.
Producto: endpoint de voz→texto + modelo de cuenta. (el código viene DESPUÉS)

Fijar (capa 2)

Nota atómica:

Feynman: “Nadie quiere un taladro; quiere el agujero. Si arrancás por el taladro (feature) sin pensar el agujero (necesidad), terminás con una caja de herramientas que nadie usa.”

Aplicar (capa 3)

Tomá cualquier proyecto de aplicación de otro módulo y escribí su Necesidad → HU → Criterios en 5 líneas, antes de tocar código.

Límites

Concepto 2 — Descubrimiento y validar demanda

Idea núcleo: validar que el problema existe y le importa a alguien antes de construir. Barato equivocarse en una hipótesis, caro en código.

Entender (compacto):

flowchart LR
    I[idea] --> SG[señales gratis<br/>búsquedas · quejas · pagos] --> E[experimento mínimo<br/>landing · waitlist · tool chica] --> Q{¿señal de demanda?}
    Q -->|sí| B[construir]
    Q -->|no| P[pivotar / descartar]

Video: How to Validate Your Product Idea Without Building a Prototype — Predictable Designs Nota atómica: Front: ¿qué validás antes de construir y cómo, barato? Back: que el problema existe y le importa a un usuario que ya busca/paga. Se valida con señales gratis (búsquedas, reviews, foros) y experimentos mínimos (landing/waitlist/tool chica), no construyendo el producto completo. Feynman: “Descubrimiento es preguntar si hay hambre antes de abrir el restaurante, no cocinar 200 platos y rezar para que venga gente.” Aplicar: para una idea, listá 3 señales de demanda reales (búsquedas/quejas/pagos) antes de escribir una línea. Límites: la validación reduce riesgo, no lo elimina; en algún punto hay que construir para aprender de verdad.

Concepto 3 — Métricas de producto ≠ métricas de sistema

Idea núcleo: que el sistema esté sano (uptime, latencia) no significa que el producto funcione (que la gente lo use y vuelva).

Entender (compacto):

flowchart LR
    SIS[Sistema · uptime/latencia/errores<br/>¿está sano?] --> Q{éxito real}
    PROD[Producto · activación/retención/conversión<br/>¿le sirve a alguien?] --> Q
    Q --> R[ambas se necesitan · miden cosas distintas]

Nota atómica: Front: ¿un servicio con 99.99% uptime es exitoso? Back: técnicamente sano, pero puede ser un fracaso de producto si nadie lo usa/vuelve. El éxito de producto se mide con activación/retención/conversión, no con métricas de sistema. Ambas se necesitan, miden cosas distintas. Feynman: “Uptime perfecto sin usuarios es un local impecable, iluminado y climatizado, con la persiana baja y nadie adentro.” Aplicar: definí 1 métrica de sistema y 1 de producto para un proyecto, y qué acción tomarías si cada una cae. Límites: vanity metrics (registros totales, page views) engañan; medí lo accionable (retención, activación).

Concepto 4 — Priorización y decir no

Idea núcleo: el criterio de producto es tanto elegir qué construir como qué NO. Impacto vs esfuerzo.

Entender (compacto):

quadrantChart
    title Impacto vs Esfuerzo
    x-axis Bajo esfuerzo --> Alto esfuerzo
    y-axis Bajo impacto --> Alto impacto
    quadrant-1 Big bets — planear
    quadrant-2 Quick wins — primero
    quadrant-3 Fill-ins — si sobra
    quadrant-4 Time sinks — evitar

Nota atómica: Front: ¿cómo priorizás features? Back: por impacto vs esfuerzo — alto impacto/bajo esfuerzo primero; y sabiendo decir no a lo de bajo impacto aunque sea fácil o pedido. Cortar scope al dolor central es habilidad senior, no falta de ambición. Feynman: “Priorizar es empacar para un viaje con una sola valija: no entra todo, y meter lo inútil deja afuera lo esencial.” Aplicar: listá 5 features candidatas de un proyecto, ubicalas en la matriz impacto/esfuerzo, y justificá cuál cortás. Límites: priorizar sin datos es adivinar; cruzá con descubrimiento (C2) y métricas (C3).

Concepto 5 — Traducir dolor de no-tech → solución técnica

Idea núcleo: el usuario no-tech no pide una solución técnica; describe un dolor. El valor senior/FDE está en traducir ese dolor a la solución correcta.

Entender (compacto):

flowchart LR
    P["cliente pide una solución<br/>('un Excel más grande')"] --> L["escuchar el DOLOR real<br/>('pierdo / no encuentro mis datos')"] --> S[elegir la solución técnica<br/>por el dolor, no la moda] --> V[validar con el cliente]

Nota atómica: Front: ¿por qué no construir la solución que el cliente no-tech pide literal? Back: porque describe un dolor con la solución que se imagina, que suele ser subóptima (“un Excel más grande” cuando el dolor es “pierdo/no encuentro mis datos”). El trabajo es traducir el dolor real a la solución correcta, no ejecutar el pedido literal. Feynman: “El paciente dice ‘deme un antibiótico’; el buen médico diagnostica primero. A veces era una alergia y el antibiótico empeora todo.” Aplicar: tomá un pedido literal de un usuario (“quiero un botón que exporte todo”) y reformulalo como el dolor real + la solución correcta. Límites: traducir no es ignorar al cliente; es entenderlo mejor que su propio pedido y validarlo con él.

Concepto 6 — Comunicación técnica-ejecutiva: defender trade-offs, estimar, escalar bloqueos

Idea núcleo: el nivel senior real no se mide solo en código — se mide en si podés defender una decisión de arquitectura ante alguien no-técnico en términos de impacto de negocio, sin perder precisión técnica.

Entender (capa 1)

Texto:

Visual:

flowchart TD
    D[decisión técnica] --> T{¿a quién se lo explico?}
    T -->|peer técnico| DEEP[detalle de implementación]
    T -->|negocio/no-técnico| BIZ["traducir a riesgo/costo/tiempo<br/>'esto evita perder pagos', no 'ACID'"]

    B[me trabé] --> M{¿cuánto tiempo llevo?}
    M -->|menos de 30min| SOLO[seguir intentando solo]
    M -->|30min+| ESC["escalar con estructura:<br/>qué probé / qué esperaba / qué descarté"]

Ejemplo (defender un trade-off, mal vs bien):

❌ "Usé Redis para el cache porque es lo estándar."

✅ "Agregué cache con Redis porque el endpoint de catálogo se
    consultaba 50 veces por segundo pegándole directo a Postgres —
    eso nos costaba latencia y presupuesto de DB. El trade-off es que
    los datos pueden estar hasta 5 minutos desactualizados (TTL);
    para catálogo eso es aceptable, para saldo de cuenta no lo sería."

Fijar (capa 2)

Nota atómica:

Feynman: “Explicarle una decisión técnica al negocio es como explicarle a alguien por qué el avión pesa lo que pesa: no le hablás de aerodinámica, le hablás de por qué no se cae. Un bloqueo bien escalado es como avisar que el puente está roto ANTES de que el auto esté a mitad de camino, no después.”

Aplicar (capa 3)

Tomá una decisión técnica real que tomaste (elegir una librería, una arquitectura, un patrón) y escribila dos veces: una para un peer técnico (con detalle) y otra para un stakeholder no-técnico (en términos de riesgo/costo/tiempo, sin perder la verdad de la decisión). Por separado, la próxima vez que te trabes 30+ minutos en algo, escribí el bloqueo con la estructura completa (qué probaste, qué esperabas, qué descartaste) antes de pedir ayuda.

Límites

Checklist de dominio M0

Marcás cuando podés explicar (Feynman) + aplicar:

Salida verificable del módulo: para cualquier proyecto de aplicación del curso, un doc corto Necesidad → HU → Usuario → Criterios → 1 métrica de producto, y poder defender en 2 min por qué existe y cómo sabrás que funcionó — sin hablar de código.