Módulo 8: Project Prioritize Mercados Roadmap

Secuencia el trimestre por costo de demora, y di que no

Siguiente →

Descripción

Tienes, en este punto, todo lo que necesitas para responder la pregunta con la que empezó este módulo: ¿en qué orden construimos las cinco apuestas este trimestre? Esta lección cierra el círculo con wsjf y sequence, del módulo 7: para cada apuesta, calculas su costo de demora —cuánto GMV pierdes cada mes que NO la construyes, tomado directamente de la lección 4— dividido entre su jobSize —el esfuerzo del MVP que la prueba, tomado directamente de la lección 6—. El resultado es el orden final del trimestre. Y, como vas a ver, ese orden no es el que RICE propuso en la lección 3.

Conexión con el módulo. Esta es la Capa 6 de las siete —la última antes de armar la tabla de decisiones completa en el proyecto (lección 8). Aquí es donde las capas de las lecciones 3, 4 y 6 finalmente se encuentran en un solo número: wsjf no reemplaza a RICE, a opportunitySize ni a compareApproaches — los combina, tomando el resultado más preciso de cada uno (el tamaño real en GMV de la lección 4, no el reach aproximado de RICE; el esfuerzo real del MVP de la lección 6, no el effort grueso de RICE) para producir la secuencia final. Tampoco reemplaza al wsjf que ya calculaste en el módulo 7: lo refina. Allá el costOfDelay era una estimación en $/semana y el jobSize era el effort grueso de RICE en person-months; aquí el costOfDelay es el GMV/mes real de la lección 4 y el jobSize es el esfuerzo del MVP en person-days de la lección 6 — inputs más honestos, y por eso el orden vuelve a moverse. Que cambie al mejorar los números no es un error de ningún módulo: es exactamente el punto de refinar la evidencia.

wsjf: el costo de demora, dividido entre el trabajo

function wsjf({ costOfDelay, jobSize }) {
  return costOfDelay / jobSize;
}

costOfDelay responde: si NO construyo esta apuesta este mes, ¿cuánto GMV dejo sobre la mesa? — es, en este módulo, exactamente el extraGMV que calculaste en la lección 4 con opportunitySize. jobSize responde: ¿cuánto trabajo cuesta empezar a obtener esa evidencia? — es el mvp.effort que calculaste en la lección 6 con compareApproaches, en person-days. Dividir uno entre el otro te da algo parecido a una densidad: cuánto valor mensual capturas por cada person-day que inviertes. Una apuesta con wsjf alto es barata de empezar y cara de posponer; una con wsjf bajo, aunque sea grande, no urge tanto porque cuesta más "arrancarla" en relación con lo que se pierde por esperar un mes más.

La fórmula completa de WSJF en SAFe usa un costo de demora más fino (valor de usuario/negocio + criticidad de tiempo + reducción de riesgo, sumados) dividido entre el tamaño del trabajo. Este módulo ejecuta una versión simplificada y pedagógica —costo de demora = GMV extra esperado por mes, tamaño = esfuerzo del MVP en person-days—, pero el mecanismo central, dividir valor entre esfuerzo para encontrar qué conviene hacer primero, es el mismo.

Ejemplo trabajado: sequence sobre las cinco apuestas del trimestre

// L07: secuenciamos el roadmap del trimestre con wsjf/sequence (modulo 7),
// usando costOfDelay = GMV extra esperado por mes (leccion 4, opportunitySize)
// y jobSize = esfuerzo del MVP en person-days (leccion 6, compareApproaches).
function wsjf({ costOfDelay, jobSize }) {
  return Math.round((costOfDelay / jobSize) * 100) / 100;
}

function sequence(backlog) {
  return backlog.map((item) => ({ ...item, wsjfScore: wsjf(item) })).sort((a, b) => b.wsjfScore - a.wsjfScore);
}

// costOfDelay viene de la leccion 4 (opportunitySize -> extraGMV/mes).
// jobSize viene de la leccion 6 (compareApproaches -> mvp.effort en person-days).
const roadmapBacklog = [
  { feature: 'fasterCheckout', costOfDelay: 27000, jobSize: 3 },
  { feature: 'recommendations', costOfDelay: 185625, jobSize: 4 },
  { feature: 'sellerTools', costOfDelay: 86450, jobSize: 3 },
  { feature: 'reviews', costOfDelay: 108000, jobSize: 3 },
  { feature: 'improvedSearch', costOfDelay: 64800, jobSize: 5 },
];

console.log('=== El roadmap del trimestre, secuenciado por WSJF ===\n');
const sequenced = sequence(roadmapBacklog);
sequenced.forEach((b, i) =>
  console.log((i + 1) + '. ' + b.feature.padEnd(16) + 'costOfDelay=$' + b.costOfDelay.toLocaleString('en-US') +
    '/mes  jobSize=' + b.jobSize + ' person-days  ->  wsjf=' + b.wsjfScore)
);
console.log('\norden WSJF:  ' + sequenced.map((b) => b.feature).join(' > '));

// Contraste con el orden de RICE (leccion 3), calculado sobre reach/impact/confidence/effort.
const riceOrder = ['fasterCheckout', 'reviews', 'improvedSearch', 'sellerTools', 'recommendations'];
console.log('orden RICE:  ' + riceOrder.join(' > '));

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

=== El roadmap del trimestre, secuenciado por WSJF ===

1. recommendations costOfDelay=$185,625/mes  jobSize=4 person-days  ->  wsjf=46406.25
2. reviews         costOfDelay=$108,000/mes  jobSize=3 person-days  ->  wsjf=36000
3. sellerTools     costOfDelay=$86,450/mes  jobSize=3 person-days  ->  wsjf=28816.67
4. improvedSearch  costOfDelay=$64,800/mes  jobSize=5 person-days  ->  wsjf=12960
5. fasterCheckout  costOfDelay=$27,000/mes  jobSize=3 person-days  ->  wsjf=9000

orden WSJF:  recommendations > reviews > sellerTools > improvedSearch > fasterCheckout
orden RICE:  fasterCheckout > reviews > improvedSearch > sellerTools > recommendations

Pon los dos órdenes uno junto al otro, otra vez, ahora con la secuencia completa y final:

RICE (lección 3):   fasterCheckout > reviews > improvedSearch > sellerTools > recommendations
WSJF (hoy):          recommendations > reviews > sellerTools > improvedSearch > fasterCheckout

fasterCheckout y recommendations intercambiaron, literalmente, el primer y el último lugar. RICE, con reach, impact, confidence y effort estimados a ojo calibrado, puso a fasterCheckout primera. WSJF, con el tamaño real en GMV (lección 4) y el esfuerzo real del MVP (lección 6), la manda al último lugar del trimestre — su wsjf: 9000 es el más bajo de las cinco, cinco veces menor que el de recommendations (46406.25). No es que fasterCheckout sea una mala apuesta: es que, comparada con las otras cuatro, cuesta lo mismo probarla (3 person-days, igual que sellerTools y reviews) pero el GMV que se pierde cada mes por no tenerla es, de las cinco, el más chico.

reviews y sellerTools se mantienen en un lugar intermedio en ambos órdenes —el 2 y el 4 en RICE, el 2 y el 3 en WSJF—, lo cual tiene sentido: ninguna de las dos tiene el extremo de "muy alto en una capa, muy bajo en otra" que sí tienen fasterCheckout y recommendations. Y fíjate en algo honesto sobre el jobSize: aunque varía entre 3 y 5 person-days a lo largo del backlog, en este trimestre específico no fue suficiente para invertir ningún otro orden más allá del que ya marcaba el tamaño real en GMV —sellerTools (jobSize 3) y improvedSearch (jobSize 5) mantienen el mismo orden relativo que tenían por costOfDelay solo, porque la diferencia de tamaño entre ambas ($21,650/mes) es mucho mayor que lo que dos person-days extra de esfuerzo podrían compensar—. Eso no es una regla general —el ejercicio 2 de esta lección te muestra un caso donde el jobSize sí decide un empate—, es simplemente lo que pasó con estos cinco números concretos.

El argumento del "esto sí, eso no, eso después"

Con la secuencia final en la mano, la parte que ningún código hace por ti es defenderla. El roadmap del trimestre de Mercado, ordenado por WSJF, se lee así:

  • recommendations va primero. No porque "se ve" más importante —de hecho, RICE la había puesto última—, sino porque dimensiona el GMV más grande del backlog ($185,625/mes) y su MVP —la tabla fija "comprados juntos"— cuesta apenas 4 person-days. El costo de esperar un mes más a construirla es, con diferencia, el más alto de las cinco.
  • reviews y sellerTools van segunda y tercera. Ambas dimensionan un tamaño considerable ($108,000 y $86,450/mes) con un MVP igual de barato (3 person-days cada una) — la diferencia entre ellas es, sobre todo, el tamaño real de la oportunidad.
  • improvedSearch va cuarta, no porque su apuesta sea mala, sino porque su MVP —etiquetar a mano una muestra de búsquedas fallidas— cuesta más (5 person-days) que las anteriores, y su tamaño ($64,800/mes) es menor.
  • fasterCheckout se pospone. Esta es la conversación incómoda que el módulo 7 preparó: no es que nunca se vaya a construir —su cadena de valor (lección 2) sigue completa, y su suposición riesgosa (lección 5) sigue siendo válida—, es que, este trimestre específico, con este backlog específico, hay cuatro apuestas que capturan más valor por cada person-day invertido. Decir que no —o, más precisamente, decir "todavía no"— con este argumento numérico es exactamente lo que separa a un roadmap defendible de una lista de features ordenada por quién convenció más fuerte en la reunión.

Errores comunes

Presentar la secuencia final sin explicar por qué fasterCheckout cayó del primero al último. Qué pasa: se comunica el orden del trimestre (recommendations, reviews, sellerTools, improvedSearch, fasterCheckout) sin mencionar que RICE había dicho algo distinto, dejando al equipo que vio el ranking de RICE confundido o desconfiado del nuevo orden. Por qué pasa: parece más simple presentar solo el resultado final que reconstruir todo el argumento. Cómo detectarlo: si alguien en la reunión pregunta "¿no habíamos dicho que fasterCheckout iba primero?" y no tienes una respuesta inmediata con números, perdiste la narrativa completa del módulo. Cómo corregirlo: como en el ejemplo de hoy, presenta los dos órdenes juntos, y explica el giro con las dos capas intermedias (tamaño real, lección 4; esfuerzo real del MVP, lección 6) — el giro es el argumento más convincente que tienes, no algo que ocultar.

Tratar "se pospone" como "se cancela". Qué pasa: el equipo que propuso fasterCheckout escucha "quedó última" y lo interpreta como "nunca se va a construir", perdiendo la motivación o abandonando la idea por completo. Por qué pasa: en un roadmap de una sola lista, el último lugar se siente como un rechazo definitivo. Cómo detectarlo: si la conversación sobre fasterCheckout se cierra sin mencionar cuándo se reevalúa (el próximo trimestre, o si cambia algún supuesto de tamaño). Cómo corregirlo: sé explícito sobre qué significa "última" — la apuesta sigue siendo válida (cadena completa, suposición nombrada), solo que otras capturan más valor por esfuerzo este trimestre. Si el tráfico de checkout mobile crece, o si el equipo encuentra una forma más barata de probarla, su wsjf puede cambiar y merecer una nueva secuencia.

Recalcular el WSJF con el effort de RICE en vez del jobSize del MVP. Qué pasa: alguien, apurado, usa el effort de RICE (person-months, lección 3) como jobSize en la fórmula de WSJF, en vez del esfuerzo del MVP (person-days, lección 6). Por qué pasa: ambos se llaman "esfuerzo" y es fácil confundirlos si no se presta atención a la unidad. Cómo detectarlo: si tu jobSize para fasterCheckout es 2 (el effort de RICE) en vez de 3 (el mvp.effort de la lección 6), estás mezclando dos escalas distintas con dos propósitos distintos. Cómo corregirlo: el WSJF de este módulo secuencia el MVP de cada apuesta —la evidencia barata, no la apuesta entera—, así que el jobSize correcto es siempre el esfuerzo del MVP (lección 6), nunca el effort grueso de RICE (lección 3).

Ejercicios

Ejercicio 1 — Verifica un WSJF a mano. Calcula a mano el wsjf de reviews (costOfDelay: 108000, jobSize: 3) y de improvedSearch (costOfDelay: 64800, jobSize: 5). Confirma que el orden entre ambas coincide con el resultado del ejemplo.

Ver solución

reviews: 108000 / 3 = 36000. improvedSearch: 64800 / 5 = 12960. 36000 > 12960, así que reviews queda por encima de improvedSearch en la secuencia — coincide exactamente con el orden del ejemplo (reviews en el puesto 2, improvedSearch en el puesto 4, con sellerTools entre ambas).

Ejercicio 2 — Encuentra un caso donde el jobSize sí decide. Si el equipo descubriera una forma más barata de probar fasterCheckout —un jobSize de 1 person-day en vez de 3, manteniendo el mismo costOfDelay: 27000—, recalcula su wsjf y di si cambiaría su posición en la secuencia del ejemplo.

Ver solución

Nuevo wsjf de fasterCheckout: 27000 / 1 = 27000. Comparado con la secuencia del ejemplo (recommendations 46406.25, reviews 36000, sellerTools 28816.67, improvedSearch 12960), este nuevo 27000 queda justo por debajo de sellerTools (28816.67) pero muy por encima de improvedSearch (12960) — fasterCheckout subiría del puesto 5 al puesto 4, empujando a improvedSearch un lugar hacia abajo. A diferencia del ejemplo original, donde el jobSize no alcanzaba a invertir ningún orden, aquí un MVP mucho más barato (1 día en vez de 3) sí es suficiente para mover a fasterCheckout — la lección práctica: cuando el costOfDelay de dos apuestas no está tan lejos (27000 contra 64800, no una diferencia de 5x), el jobSize empieza a pesar en el resultado.

Ejercicio 3 — Escribe el argumento de "esto sí, eso no, eso después" para improvedSearch. Usando los números reales de esta lección, escribe en 3-4 frases cómo defenderías, frente al equipo, que improvedSearch va cuarta —ni primera ni última— en la secuencia del trimestre.

Ver solución

Una respuesta posible: "improvedSearch dimensiona un tamaño real —$64,800 de GMV extra al mes—, así que no es una apuesta que estemos descartando. Pero su MVP, a diferencia de las otras cuatro, no es barato de la misma forma: etiquetar a mano una muestra de búsquedas fallidas para confirmar si el problema es realmente de typos y sinónimos cuesta 5 person-days, el más caro de los cinco MVP de este trimestre. Con un costo de demora menor que recommendations, reviews y sellerTools, y un costo de arranque mayor, su WSJF queda por debajo de las tres — la construimos este trimestre, en cuarto lugar, después de confirmar las tres apuestas que capturan más valor por cada día de trabajo invertido." El argumento funciona porque no dice "no" —dice "cuarta, con esta razón numérica específica", que es exactamente lo que un roadmap defendible necesita poder decir de cada apuesta, no solo de la primera y la última.

Resumen y siguiente paso

En esta lección secuenciaste el trimestre completo de Mercado con wsjf y sequence, combinando el tamaño real en GMV (lección 4) y el esfuerzo real del MVP (lección 6) en un solo número por apuesta. El resultado —recommendations > reviews > sellerTools > improvedSearch > fasterCheckout— invierte casi por completo el orden que RICE había propuesto en la lección 3, y viste que ese giro no es un error de ningún modelo: es la diferencia entre decidir con estimaciones gruesas de orden de magnitud y decidir con el tamaño real y el costo real de cada apuesta, una vez que los calculaste.

Con las siete capas completas —cadena de valor, RICE, tamaño, suposición riesgosa, MVP, y ahora la secuencia final—, ya tienes todo lo que necesitas para el proyecto final de esta guía: la lección 8 junta las siete en una sola tabla de decisiones, con la corrida de Node de principio a fin sobre el backlog completo, y cierra con el argumento final del trimestre y hacia dónde sigue tu camino en el ecosistema Product Engineering.

Recursos

  • SAFe, "Weighted Shortest Job First (WSJF)" — scaledagileframework.com/wsjf. La referencia formal completa del costo de demora, con su fórmula de tres componentes (valor, criticidad de tiempo, reducción de riesgo) que este módulo simplifica. En inglés.
  • Don Reinertsen, The Principles of Product Development Flow — reinertsenassociates.com. El libro que originó el concepto de costo de demora como herramienta de secuenciación económica, la base teórica de WSJF. En inglés.
  • Melissa Perri, Escaping the Build Trap — el argumento de cierre de toda la guía: un roadmap de apuestas ordenadas por evidencia y valor, no una lista de features ordenada por quién grita más fuerte. En inglés.
← AnteriorRecorta cada apuesta al MVP que prueba su suposición riesgosaSiguiente →Proyecto final: el roadmap del trimestre de Mercado, de punta a punta