Lección 51 — Entender el negocio

Stack: Habilidades · Proyecto: TicketFlow Estado: Publicada — cierre del módulo de habilidades no técnicas Prerrequisito: Lección 50 — Revisión de código

Objetivos

1. Explicar el modelo de negocio de TicketFlow: quién paga, por qué valor, y qué métrica mueve cada decisión técnica.
2. Traducir entre negocio y técnica en las dos direcciones: el requerimiento → el problema real, y la limitación técnica → la decisión de producto.
3. Priorizar con el negocio: el valor/esfuerzo/riesgo que decide el backlog y el "no" técnico que protege al negocio de sí mismo.

1. El modelo de negocio de TicketFlow (el mapa que la técnica sirve)

TicketFlow no vende "una API de reservas": vende la VENTA de entradas. El mapa del dinero: los organizadores pagan comisión por venta (el ledger del 08 — por eso es append-only: es la FACTURACIÓN); los compradores pagan entradas (la pasarela del 32); el inventario (los asientos del 10) es el ACTIVO que se corrompe si la técnica falla (un asiento vendido dos veces = devolución + reputación + comisión perdida). Cada pieza técnica del curso sirve a UNA línea del modelo:

El test del mapa: si no sabes qué línea de negocio protege tu pieza, la pieza es sospechosa de sobre-ingeniería (el 43: K8s sin trigger) — o es infraestructura común que merece ser aburrida. Ambas respuestas son legítimas; la INCONSCIENTE no.

2. Traducir: el requerimiento y el problema real

La traducción dirección 1: el requerimiento ("queremos push de notificaciones") → el problema real (¿el organizador quiere saber la venta? ¿el comprador su entrada? ¿la marketing su campaña?). El método: las 5 whys con el stakeholder ("¿por qué push? → porque el organizador no ve las ventas → ¿cuándo las necesita? → al cierre del día → un email diario del 31 lo resuelve, sin app móvil") — el requerimiento pide push; el problema pide visibilidad; la solución más barata es distinta. La técnica es responsable de preguntar: el "sí" al requerimiento mal entendido es el feature que nadie usa (y que pagaste).

Dirección 2: la limitación técnica → la decisión de producto: "el inventario no admite 10k reservas simultáneas sobre el mismo evento" → el producto elige: turnos de preventa (23/36: gratis), partición (55: 2 semanas), o rechazar picos (la cola de espera). La regla: la técnica NO decide el trade-off (el 49: presentas opciones con costo), pero DEBE explicar las consecuencias EN LENGUAJE DE NEGOCIO: "sin turnos, el 40% de los compradores del pico verá errores" — el % de conversión, no el p95.

3. Las métricas que el negocio lee (y la técnica mueve)

El dashboard del negocio (distinto del técnico del 46): ventas/día, conversión del checkout (visitas→compra), abandono en el paso del pago, NPS/reclamos, comisión facturada. La técnica mueve cada una: el p95 del checkout (46) mueve la conversión (cada 100 ms extra: abandono medible); el email fallido (29) mueve los reclamos; el asiento vendido dos veces (10) mueve el NPS y la devolución. El hábito del backend que entiende el negocio: cada proyecto técnico lleva su línea de impacto ("el turnstile del 36: protege el pico de la preventa del sábado, la venta que paga el trimestre") — el trabajo sin línea de impacto es sospechoso de TIC (Technical Impression Competition).

Y la métrica que la técnica PROTEGE sin pedirla: el error budget del 46 es la CUOTA de fiabilidad del negocio: el negocio que exige "cero errores Y tres features esta semana" está gastando un budget que no tiene — la técnica lo explica con el número (el burn del 46), el negocio decide (¿features o fiabilidad este sprint?).

4. Priorizar con el negocio: el backlog que vale

La priorización del negocio: valor (¿qué mueve: ingresos, retención, riesgo?), esfuerzo (la 49), riesgo (¿qué pasa si falla? — el 22/32). La matriz que el backlog real usa: el ROI del esfuerzo: el turnstile del pico (2 semanas de esfuerzo, protege la venta del año) vence al app móvil (2 meses, hipótesis de retención sin validar). La técnica aporta: el costo honesto (la 49: con su incertidumbre) y el costo de NO hacerlo (el riesgo). El error del técnico-priorizador: priorizar por INTERÉS técnico ("quiero migrar a K8s", el 43) sin línea de negocio — el ADR del 43 existe porque el trigger real llegó: la decisión la dispara el negocio, la ejecuta la técnica.

Y el "no" técnico que protege: "el negocio" a veces pide lo que rompe el negocio (el reporte en tiempo real sobre el ledger de 2M filas por cada request del admin: el 09 lo mata en el p95; la vista cacheada del 38 o el batch del 31 lo resuelven). El no con alternativa es servicio; el no seco es obstrucción; el sí mudo es el 500 en prod.

5. El oficio completo: por qué este módulo cierra el curso

El backend senior no es el que conoce más frameworks: es el que convierte el problema del negocio en el sistema más simple que lo resuelve — y defiende esa simplicidad. El curso construyó TicketFlow entero (el inventario, el dinero, los eventos, la observabilidad) y este módulo explicó PARA QUÉ: cada lock (10) protege la venta; cada outbox (25) protege la confianza; cada ADR (48) protege la memoria; cada SLO (46) protege la conversión. La pregunta final del oficio — la que el 57 (el proyecto final) examina: "¿puedes explicar el sistema sin tecnicismos al dueño del negocio, y el negocio sin jerga al equipo técnico?" — la traducción bidireccional ES la habilidad senior.

Autoevaluación

1. ¿Qué línea del modelo de negocio protege cada pieza técnica del curso (el lock, el outbox, el ledger, el SLO)?
2. Las 5 whys del requerimiento: ¿cuándo "push de notificaciones" era "un email diario" y qué método lo revela?
3. ¿Qué métricas del negocio mueve la técnica y cómo se explica el p95 a quien factura?
4. ¿Qué aporta la técnica a la priorización y cuándo es legítimo priorizar por interés técnico?
5. ¿Cuál es la traducción bidireccional que define al senior y qué examen (57) la prueba?

Continúa con los ejercicios. Las solutions.md solo tras intentarlo.