Módulo 7: Saying No And The Roadmap

El costo de demora (cost of delay)

Siguiente →

Descripción

En la lección anterior nombraste el costo de oportunidad de una elección: el valor de la mejor alternativa que sacrificaste. Pero esa lección lo midió en un solo momento — un GMV mensual, una cifra estática—. La realidad del backlog de Mercado es que el tiempo importa: una apuesta que espera dos semanas en el backlog no es lo mismo que la misma apuesta esperando dos trimestres. Esta lección le pone nombre a esa dimensión: el costo de demora (cost of delay, CoD) — cuánto pierde Mercado por cada semana que una apuesta no está viva, no cuánto cuesta construirla.

Conexión con el módulo. Esta es la pieza que la lección 4 va a necesitar para construir WSJF: WSJF = costo de demora ÷ tamaño del trabajo. Antes de dividir por nada, hace falta entender qué es el numerador — y por qué dos apuestas pueden "esperar" el mismo tiempo y perder cantidades de valor completamente distintas. La lección 2 ya estableció que cada sí tiene un costo de oportunidad; esta lección responde una pregunta más afilada: ¿cuánto crece ese costo, semana tras semana, mientras la apuesta sigue en la fila?

Una analogía: la tienda que no abre

Imagina una tienda nueva, ya construida, con el local pagado, el inventario comprado, el letrero colgado — todo listo, excepto que las puertas siguen cerradas porque falta un trámite. Cada día que la tienda no abre no es un día "neutral": es un día de ventas que no ocurrieron y que, en la mayoría de los casos, nunca se recuperan — el cliente que hubiera comprado hoy compró en la tienda de al lado, y no vuelve mañana a comprar el doble. El costo de ese trámite pendiente no se mide en lo que cuesta resolverlo (probablemente una llamada y un formulario); se mide en las ventas perdidas cada día que sigue sin resolverse.

Una apuesta de producto que ya está lista para construirse —o ya construida y esperando en un backlog de lanzamiento— funciona igual. Cada semana que reviews no está viva en Mercado, algunos compradores siguen desconfiando de vendedores sin historial y algunas ventas no ocurren — ventas que, como en la tienda cerrada, en su mayoría no se recuperan después. Ese es el costo de demora: no lo que cuesta construir la apuesta, sino lo que el negocio pierde mientras la apuesta no existe.

Ejemplo trabajado: la misma espera, dos costos distintos

Toma dos apuestas del backlog de Mercado: reviews y improvedSearch. Cada una tiene un costOfDelay — una estimación del equipo, en dólares por semana, de lo que Mercado pierde mientras esa apuesta no está viva. No son la misma cifra: reviews tiene un costOfDelay de $9,000 por semana; improvedSearch, de $6,000 por semana. Si ambas quedan esperando 8 semanas en el backlog antes de empezar a construirse, ¿cuánto le costó a Mercado esa espera, a cada una?

// Dos apuestas del backlog de Mercado, cada una con un costOfDelay -- una
// estimacion en dolares por semana de lo que Mercado PIERDE mientras esa
// apuesta no esta viva (no un costo de construirla; un costo de ESPERAR).
// Son estimaciones del equipo, un modelo pedagogico, no una medicion de
// laboratorio.
const bets = [
  { feature: 'reviews',        costOfDelay: 9000 }, // $/semana que Mercado pierde mientras no hay resenas
  { feature: 'improvedSearch', costOfDelay: 6000 }, // $/semana que Mercado pierde mientras la busqueda no mejora
];

function lostWhileWaiting(costOfDelay, weeks) {
  return costOfDelay * weeks;
}

console.log('=== Cuanto pierde Mercado por cada semana que una apuesta NO esta viva ===\n');
bets.forEach((b) => {
  console.log('  ' + b.feature.padEnd(16) + '$' + b.costOfDelay.toLocaleString('en-US') + ' / semana');
});

const waitWeeks = 8; // ambas quedaron 8 semanas en el backlog antes de construirse
console.log('\n=== Si ambas esperan ' + waitWeeks + ' semanas en el backlog antes de empezar ===\n');
bets.forEach((b) => {
  const lost = lostWhileWaiting(b.costOfDelay, waitWeeks);
  console.log('  ' + b.feature.padEnd(16) + '$' + b.costOfDelay.toLocaleString('en-US') + '/semana x ' + waitWeeks + ' semanas = $' + lost.toLocaleString('en-US') + ' perdidos');
});

console.log(
  '\nLa misma espera (8 semanas) le cuesta a Mercado montos distintos segun la apuesta:\n' +
  '$72,000 de reviews contra $48,000 de improvedSearch. El costo de demora no es\n' +
  'el esfuerzo de construir -- es lo que se pierde cada semana que la apuesta NO esta viva,\n' +
  'y ese numero es distinto para cada apuesta.'
);

Qué esperar. Al correr el archivo con Node, la salida es exactamente esta:

=== Cuanto pierde Mercado por cada semana que una apuesta NO esta viva ===

  reviews         $9,000 / semana
  improvedSearch  $6,000 / semana

=== Si ambas esperan 8 semanas en el backlog antes de empezar ===

  reviews         $9,000/semana x 8 semanas = $72,000 perdidos
  improvedSearch  $6,000/semana x 8 semanas = $48,000 perdidos

La misma espera (8 semanas) le cuesta a Mercado montos distintos segun la apuesta:
$72,000 de reviews contra $48,000 de improvedSearch. El costo de demora no es
el esfuerzo de construir -- es lo que se pierde cada semana que la apuesta NO esta viva,
y ese numero es distinto para cada apuesta.

Ocho semanas es ocho semanas para las dos apuestas — el calendario no distingue—, y aun así una le costó a Mercado $24,000 más que la otra. La diferencia no viene del tiempo de espera (es idéntico), viene de cuánto vale por semana cada apuesta específica: reviews resuelve un problema de confianza que frena ventas activamente ahora mismo; improvedSearch mejora algo que, sin estar resuelto, sigue generando algo de valor mientras tanto. Esa tasa —dólares por semana— es el número que necesitas conocer, apuesta por apuesta, antes de poder decidir en qué orden construirlas.

De dónde sale el costOfDelay — y por qué no es una medición exacta

Igual que reach, impact y confidence en RICE (módulo 3) y expectedLift en opportunity sizing (módulo 4), el costOfDelay es una estimación del equipo, no una cifra medida en un laboratorio. En la práctica, un equipo la construye combinando tres preguntas —las mismas que usa SAFe para descomponer el costo de demora—: ¿cuánto vale esto para el usuario y para el negocio?, ¿qué tan urgente es en el tiempo (se pierde una ventana, o se puede esperar sin penalidad)?, y ¿reduce algún riesgo importante o habilita algo más adelante? En este módulo simplificamos esas tres preguntas en un solo número que el equipo estima directamente —igual que el módulo 3 simplificó impact a una escala de 0.25 a 3 en vez de descomponerlo en sub-factores—. Lo que no cambia es la disciplina: cada costOfDelay debe poder explicarse con una razón concreta, no inventarse para que el ranking salga como a alguien le conviene — exactamente la misma advertencia que el módulo 3 hizo sobre confidence.

   costOfDelay (aproximacion pedagogica de este modulo)
   ┌─────────────────────────────────────────────────┐
   │  valor de negocio/usuario + urgencia en el tiempo │
   │  + riesgo que reduce o que habilita               │
   │  = UN numero: $ perdidos por cada semana que      │
   │    la apuesta NO esta viva                        │
   └─────────────────────────────────────────────────┘

Errores comunes

Confundir el costo de demora con el costo de construir. Qué pasa: alguien dice "el costo de demora de reviews es alto porque cuesta mucho construirla", mezclando dos números que son independientes. Por qué pasa: los dos son "costos" y suenan parecidos, pero miden cosas opuestas: uno es lo que gastas para tener la apuesta (jobSize, en person-months); el otro es lo que pierdes mientras no la tienes (costOfDelay, en dólares por semana). Cómo detectarlo: si tu respuesta a "¿cuál es el costo de demora de esto?" menciona person-months o esfuerzo de ingeniería, confundiste los dos números. Cómo corregirlo: el costo de demora se mide siempre en valor perdido por unidad de tiempo — nunca en esfuerzo de construcción; los dos números son necesarios, pero son ejes distintos (y la lección 4 los combina, no los confunde).

Tratar el costo de demora como si fuera constante mientras el mundo cambia. Qué pasa: el equipo calcula un costOfDelay una vez, al principio del trimestre, y lo trata como verdad fija durante meses, aunque las condiciones del mercado hayan cambiado (un competidor lanzó algo parecido, o la temporada de mayor tráfico ya pasó). Por qué pasa: recalcular se siente como trabajo extra cuando ya "existe un número". Cómo detectarlo: si el costOfDelay de una apuesta no se ha revisado en varios meses a pesar de cambios visibles en el contexto, probablemente ya no refleja la realidad. Cómo corregirlo: como con confidence en RICE, el costOfDelay merece revisión cuando aparece evidencia nueva y legítima — no cada semana por capricho, pero tampoco nunca.

Asumir que todo cuesta lo mismo esperar. Qué pasa: el equipo trata a todas las apuestas del backlog como si "esperar" tuviera el mismo costo para todas, y por lo tanto ordena solo por valor total o por esfuerzo, sin diferenciar la urgencia. Por qué pasa: calcular un costOfDelay distinto para cada apuesta exige una pregunta más que simplemente copiar el impact que ya se estimó para RICE. Cómo detectarlo: si todas las apuestas de tu backlog tienen la misma urgencia declarada (o ninguna urgencia declarada), es señal de que nadie se hizo la pregunta específica. Cómo corregirlo: como viste en el ejemplo, dos apuestas con esfuerzos parecidos pueden tener costos de demora muy distintos — la única forma de saberlo es preguntarlo apuesta por apuesta, no asumirlo.

Ejercicios

Ejercicio 1 — Calcula el costo de una demora más larga. Usando los mismos costOfDelay del ejemplo (reviews: $9,000/semana, improvedSearch: $6,000/semana), calcula cuánto pierde Mercado si, en vez de 8 semanas, la espera se extiende a 16 semanas (un trimestre completo) para cada una. ¿La diferencia entre ambas crece, se mantiene igual, o se reduce en proporción?

Ver solución

reviews: $9,000 × 16 = $144,000. improvedSearch: $6,000 × 16 = $96,000. La diferencia absoluta pasa de $24,000 (a las 8 semanas) a $48,000 (a las 16 semanas) — se duplica, porque el tiempo se duplicó y ambos costos son lineales en el tiempo. Pero la diferencia proporcional se mantiene igual: reviews siempre pierde un 50% más que improvedSearch por cada semana de espera ($9,000 es 1.5 veces $6,000), sin importar cuántas semanas pasen. La lección práctica: mientras más tiempo pasa sin decidir, más dinero absoluto se pierde por la brecha entre apuestas — el costo de no secuenciar bien crece con cada semana que el equipo tarda en ordenar el backlog.

Ejercicio 2 — Estima un costOfDelay con una razón concreta. El equipo de Mercado quiere estimar el costOfDelay de sellerTools (herramientas para vendedores). Con estos datos: cada semana sin la herramienta, unos 15 vendedores activos consideran mudarse a un competidor, y el valor promedio de las ventas mensuales de un vendedor activo es de $2,400 (de los cuales Mercado retiene una comisión del 10%). Propón un costOfDelay semanal razonable para sellerTools, mostrando de dónde sale cada número (no hace falta que sea exacto; el objetivo es la trazabilidad, como en el módulo 4).

Ver solución

Un cálculo razonable: si Mercado pierde esos 15 vendedores, pierde su comisión mensual ($2,400 × 10% = $240 por vendedor al mes, o $60 por semana aproximadamente). 15 vendedores × $60/semana ≈ $900/semana de comisión perdida. Es un número bastante más bajo que el costOfDelay de reviews o improvedSearch de este módulo — lo cual, por sí solo, ya es información útil: sugiere que sellerTools, aunque defendible, no es la apuesta más urgente del backlog en términos de costo de demora, más allá de lo que diga su RICE score. Lo importante del ejercicio no es el número exacto sino la trazabilidad: cualquiera puede seguir el razonamiento desde "vendedores en riesgo" hasta el dólar por semana, exactamente como exige la disciplina de estimación de todo el módulo.

Ejercicio 3 — Distingue urgencia real de urgencia percibida. Un stakeholder insiste en que improvedSearch es "súper urgente" porque recibió una queja de un usuario esta semana. Usando el costOfDelay de esta lección ($6,000/semana, el más bajo de las dos apuestas del ejemplo), escribe en 2-3 frases cómo responderías a esa insistencia sin descartar la queja del usuario, pero sin dejar que determine el orden del trimestre por sí sola.

Ver solución

Una respuesta posible: "La queja es una señal real y vale la pena registrarla, pero el costo de demora que estimamos para improvedSearch ($6,000/semana) es el más bajo de las apuestas que estamos comparando — más bajo que reviews ($9,000/semana), que espera exactamente el mismo tiempo en el backlog. Si improvedSearch fuera tan urgente como se siente por esta queja, esperaríamos ver ese costo de demora más alto, no más bajo. Vamos a revisar el costOfDelay si aparecen más señales concretas (más quejas, una caída medible en el uso de la búsqueda), pero por ahora el número, no el volumen de la queja, es lo que ordena el trimestre." Esto retoma directamente el error común de la presentación del módulo: la urgencia percibida no sustituye al costo de demora calculado.

Resumen y siguiente paso

En esta lección le pusiste número al costo de esperar: el costOfDelay, en dólares por semana, que mide lo que Mercado pierde mientras una apuesta no está viva — no lo que cuesta construirla. Viste, con reviews e improvedSearch, que la misma espera de 8 semanas le cuesta a Mercado cantidades distintas según la apuesta ($72,000 contra $48,000), y que ese número se construye con la misma disciplina de trazabilidad que ya usaste en RICE y en opportunity sizing: una estimación del equipo, con su razón declarada, no una medición exacta.

Antes de avanzar deberías poder: explicar la diferencia entre el costo de construir algo y el costo de demorarlo; calcular cuánto se pierde dado un costOfDelay y un número de semanas de espera; y reconocer cuándo una "urgencia" es en realidad solo ruido, sin un costOfDelay que la respalde.

Ya tienes las dos piezas que WSJF necesita: el jobSize (el mismo effort de RICE, cuánto cuesta construir) y el costOfDelay (cuánto cuesta esperar). La lección 4 las combina en una sola fórmula — la de SAFe — y la corre sobre el backlog completo de Mercado, para ver el orden que resulta cuando el tiempo entra en la balanza.

Recursos

  • Donald G. Reinertsen, The Principles of Product Development Flow — goodreads.com/book/show/6278270. La fuente original del concepto de costo de demora, y de la observación de que la mayoría de los equipos de producto nunca lo calculan explícitamente. En inglés.
  • Scaled Agile Framework, "WSJF" — framework.scaledagile.com/wsjf. Describe los tres factores que SAFe combina en el costo de demora (valor de negocio/usuario, urgencia en el tiempo, reducción de riesgo/habilitación de oportunidad) — la versión completa de la simplificación de esta lección. En inglés.
  • Melissa Perri, Escaping the Build Trap — sobre por qué los equipos que se miden por outputs rara vez calculan el costo de demora: si no te mides por outcomes, "esperar" no se siente como que cueste nada. Conecta directo con el módulo 1 de esta guía. En inglés.
← AnteriorCosto de oportunidad: cada sí es un no a otra cosaSiguiente →WSJF: Weighted Shortest Job First