System Design
Priorización y alcance de entrega
Explica cómo priorizar requisitos, riesgos e incertidumbres y construir entregas verticales que produzcan valor sin perder garantías esenciales.
- Última actualización
- Actualizada
- Nivel
- Fundamentos
System Design
Explica cómo priorizar requisitos, riesgos e incertidumbres y construir entregas verticales que produzcan valor sin perder garantías esenciales.
Priorizar no significa ordenar una lista por intuición. Significa decidir qué valor, riesgo o aprendizaje se atiende primero bajo capacidad limitada, dejando explícito qué se posterga y por qué.
Todo sistema tiene más necesidades que tiempo y presupuesto disponibles. La priorización conecta objetivos con decisiones de entrega:
objetivos + valor + riesgo + coste + dependencias
→ orden de aprendizaje y entregaLa prioridad de negocio no siempre coincide con el orden técnico. Una capacidad puede ser muy importante, pero depender de trabajo previo, datos, contratos o reducción de incertidumbre.
Sin un criterio explícito, el backlog suele ordenarse por:
Eso produce entregas amplias pero poco útiles, deuda de riesgos críticos y sistemas que tardan meses en validar su hipótesis principal.
qué valor produce
qué riesgo reduce
qué aprendizaje habilita
qué cuesta
qué depende de qué
qué pasa si se postergaLa decisión debe comparar consecuencias, no solo etiquetas como alta o baja.
Alta prioridad: confirmar pedidos
Trabajo previo: definir stock vendible y coordinación de inventarioLa capacidad final es prioritaria, pero la secuencia comienza por una dependencia. El roadmap debe distinguir importancia, orden y fecha comprometida.
Impacto esperado para usuario, negocio u operación. Debe relacionarse con objetivos y evidencia.
Seguridad, regulación, pérdida de datos, reputación o incertidumbre técnica.
Existe una ventana temporal real: contrato, regulación, evento o coste creciente.
No es el único criterio, pero permite comparar retorno y capacidad.
Una pieza puede desbloquear varias capacidades o quedar bloqueada por terceros.
Un spike, prototipo o entrega pequeña puede validar una hipótesis y evitar una inversión mayor.
Una mejora diaria para miles de usuarios puede superar una función anual para pocos.
Cuánto valor o riesgo se acumula por cada periodo de espera.
Si todo se etiqueta Must, la técnica dejó de priorizar. Cada Must debe responder qué falla si se omite.
Reach × Impact × Confidence / EffortPuede ordenar hipótesis de producto, pero sus números son estimaciones. No mezcles escalas inconsistentes ni uses el resultado como verdad automática.
WSJF compara coste de demora con tamaño del trabajo. Aporta cuando el tiempo cambia significativamente el valor, pero requiere consenso sobre urgencia, criticidad y reducción de riesgo.
Distingue cualidades básicas, de desempeño y atractivas. Ayuda a evitar invertir en “sorpresas” mientras faltan garantías básicas como integridad o recuperación.
En System Design, algunas tareas deben adelantarse porque pueden invalidar el diseño:
Un spike no entrega funcionalidad, pero puede proteger semanas de trabajo.
Un MVP es la menor entrega que completa un resultado útil o valida una hipótesis.
mal corte
→ frontend completo sin persistencia
→ backend completo sin usuario
corte vertical
→ crear un pedido simple
→ guardarlo
→ verlo en operaciones
→ actualizar estadoEl corte vertical atraviesa las capas necesarias para observar valor. No necesita cubrir todos los productos, reglas y automatizaciones.
“Mínimo” no elimina garantías esenciales:
Puede reducir amplitud, automatización o sofisticación, no aceptar corrupción silenciosa.
Objetivo: reducir pedidos confirmados sin disponibilidad.
Candidatos:
Un orden razonable podría ser:
modelo de stock y movimientos
→ reserva atómica
→ confirmación de pedido
→ auditoría y reconciliación
→ catálogo y operación ampliada
→ optimización de rutas despuésLa optimización puede ser atractiva, pero no resuelve el riesgo principal.
No todos los atributos pueden maximizarse. Determina escenarios críticos:
Esto permite arquitectura diferenciada por flujo.
Un grafo simple ayuda:
identidad ─┐
├→ operación administrativa
roles ─────┘
modelo de inventario
→ reserva
→ confirmación de pedidoEl camino crítico determina secuencia. Las tareas paralelas deben evitar bloquear integración tarde.
Toda incorporación debe responder:
“No debería tomar mucho” no es análisis de impacto.
Puede ser Must aunque pocos usuarios la utilicen.
Prioriza experimento antes de construir completa.
Adelanta validación o diseña alternativa.
Priorízala por riesgo, coste futuro y capacidad bloqueada, no por pureza.
Puede desplazar roadmap si el coste operativo supera valor de nuevas features.
Busca reducción de alcance, feature flags o entregas internas verificables.
La frecuencia de opinión no equivale a impacto.
Una fecha cercana puede tener poco valor; un riesgo silencioso puede ser crítico.
Entregar sin soporte, observabilidad o migración traslada coste a producción.
Los decimales no eliminan incertidumbre. Registra confidence y supuestos.
Debe cambiar con evidencia, pero conservar razones y compromisos.
La amplitud visible puede crecer sobre una base inconsistente.
Cuando aparece evidencia nueva, una dependencia cambia, un riesgo se materializa o una hipótesis queda invalidada. Repriorizar no es fracaso; hacerlo sin registrar consecuencias sí lo es.
Historias de usuario convierte capacidades priorizadas en unidades conversables de valor y aprendizaje.