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.

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.