Lección 51 — Soluciones: entender el negocio

Ejercicio 1 — El mapa del dinero

El modelo (10 líneas): "Los organizadores publican eventos y pagan comisión del 5% por entrada vendida. Los compradores pagan entradas con tarjeta/tarjeta regalo. El ingreso = comisión (el ledger del 08); el riesgo = vender dos veces el asiento (devolución + reembolso + reputación) y el pico de preventa (la venta del año en 2 h). La confianza del comprador ('pagué y llega') es el activo más barato de perder".
La tabla con las piezas sin línea: el leaderboard del 12 (INCR) no encontró línea → decisión: es infraestructura aburrida para el dashboard interno (se queda, documentada como tal) o se muere (si nadie lo mira: el hunting del 42). Ambas respuestas legítimas; la inconsciente no.
La query de facturación: el ledger del 08 con SELECT org_id, SUM(amount) WHERE kind='comision' AND mes='2027-09' GROUP BY org_id — la única query que el negocio pide del ledger: si el schema no la responde (¿el kind existe? ¿el mes?), la facturación es un Excel a mano: el hallazgo del ejercicio es el gap del modelo.

Los tres: (push) ¿por qué? el organizador no ve las ventas → ¿cuándo? al cierre → email diario del 31 (0.5 d vs 2 semanas de app); (Excel) ¿por qué? el finance cruza con el suyo → ¿qué campos? comisión por org/mes → el CSV del ledger con la query del ejercicio 1 (0.5 d); (30 min de reserva) ¿por qué? el comprador "pierde" asientos si piensa → ¿cuánto piensa? la conversión cae a los 10 min → 10 min con Retry-After explícito (26) ya que el dato dice 10.
El diálogo: "¿Qué necesita el organizador?" → "Ver las ventas" → "¿Para qué?" → "Saber si promociono" → "¿Cuándo decide?" → "Al cierre del día" → "¿Qué le sirve: verlas en vivo o el resumen del día?" → "El resumen, si llega antes de las 9" → el problema real: el resumen diario a las 8; la solución: el job del 31 + email; el push (2 semanas) muere.
La salvadora: "¿quién lo usa y para decidir QUÉ?" — la feature de "dashboard en tiempo real" que nadie abría: la pregunta habría revelado que el uso real era mensual (el CSV del finance).

Las traducciones: (a) "1.2 s" → "el checkout tarda tanto que ~8% de los compradores abandona: son X €/mes" (la conversión); (b) "outbox 800 pendientes" → "los correos de confirmación están retrasados hasta 20 min: los compradores llaman a soporte" (los reclamos); (c) "saga UNKNOWN 1 h" → "hay pagos de los que no sabemos si entraron: el dinero en limbo; a la hora, alguien lo revisa a mano" (el riesgo); (d) "budget 80%" → "ya gastamos el 80% del margen de error del mes: una incidencia más y dejamos de lanzar features" (la decisión features-vs-fiabilidad).
Las opciones con costo: (turnos: 0 €, la conversión del pico baja 5% pero cero errores), (partición: 2 semanas ≈ 6k € de trabajo, el pico se absorbe completo), (rechazar: 0 €, el 40% del pico ve error y ~10% no vuelve). Recomendación: turnos ya, partición si el pico ×2 se confirma — informa, no decide (el dueño elige la conversión que pierde).
El budget explicado: "El sistema admite ~6,500 requests lentos/mes como margen. Las 3 features propuestas consumen ~4,000 en pruebas y risk. Propuesta que cabe: 2 features (4,000 de margen restante) o las 3 con aceptación explícita de apuntar el margen a 0 (si algo falla, la congelación es inmediata)". El número decide la conversación.

La matriz: runbook del 47 (valor alto/riesgo alto mitigado/esfuerzo bajo), turnstile del pico (alto/alto/medio), migración K8s (TIC: valor no demostrado), app móvil (hipótesis), export CSV (alto/bajo/0), partición (condicional al trigger), email diario (alto/bajo), dashboard tiempo real (bajo: el CSV basta).
El ROI del top: (1) export CSV del ledger (1 día: la facturación deja de ser Excel), (2) runbook (el MTTR del 47), (3) turnstile (la venta del año). La sorpresa honesta: NINGUNA feature nueva de producto en el top 3: el negocio compra FIABILIDAD y facturación antes que features — la lección del módulo entero.
El no-con-alternativa: "El reporte en tiempo real por request sobre 2M de filas mata el p95 del admin (el 09) y del público (la misma BD). Alternativas: (a) el reporte cada 15 min cacheado (38) cubre el 95% de las preguntas; (b) si alguien necesita el sub-minuto, el stream del 30 alimenta el dashboard dedicado SIN tocar la BD de venta. Recomiendo (a) ahora y (b) cuando alguien lo pida con datos."

El pitch sin tecnicismos: "Vendemos la taquilla digital de conciertos y teatro. El organizador publica su evento y nosotros vendemos las entradas y le pasamos su dinero con una comisión. El comprador elige su asiento, paga y recibe su entrada al momento. Lo difícil —y lo que hacemos bien— es que NUNCA se vende el mismo asiento dos veces, ni siquiera cuando 5,000 personas compran a la vez. Y si algo falla, sabemos qué pasó y arreglamos antes de que nadie llame."
El pitch inverso: "Vendemos conversión: cada segundo del checkout vale un % de carritos abandonados. El ingreso es la comisión del 5% sobre la venta facturada en el ledger. El pico de preventa es la venta del trimestre: protege el pico antes que añadir features. Y la confianza ('pagué y llega') es la que evita el churn del organizador."
El ensayo del 57 (10 frases, extracto): "Los asientos nunca se venden dos veces porque la reserva es una transacción con bloqueo (10). Cada confirmación emite un registro que no se puede perder (25). El pago es una conversación con la pasarela que sabe qué hacer si no responde (32). Si algo falla, suena una alerta y el runbook guía (46/47). Cada decisión importante está escrita y tiene fecha de revisión (48)."

Cada pieza técnica protege una línea del modelo de dinero; la pieza sin línea es sobre-ingeniería o infraestructura aburrida — nunca inconsciente.
Las 5 whys convierten requerimientos en problemas; la traducción al negocio habla de conversión y euros, no de p95.
El backlog se ordena por valor/esfuerzo/riesgo con el costo honesto de la 49; el "no" con alternativa es servicio. La traducción bidireccional es el examen del oficio.