Los límites del scoring

Descripción

Las lecciones 3 a 6 te dieron dos herramientas reales: RICE e ICE convierten un debate subjetivo en un número calculado, comparable y repetible. Esta lección hace algo distinto: te enseña dónde ese número deja de ser confiable, no para que dejes de usarlo, sino para que sepas exactamente cuándo confiar en él y cuándo no.

El problema tiene un nombre de la computación clásica que aplica perfecto aquí: garbage in, garbage out. La fórmula de riceScore no tiene forma de saber si un reach de 9000 viene de un dato real de analytics o de una corazonada optimista; no tiene forma de saber si un confidence de 1.0 está respaldado por un experimento o por el deseo de que tu apuesta gane. La aritmética es perfecta —reach x impact x confidence / effort se calcula exactamente igual sea cual sea el origen de esos números—, y esa perfección es justo el problema: un cálculo impecable sobre datos inventados produce un resultado inventado con apariencia de precisión.

Conexión con el módulo. Las lecciones 3 a 6 construyeron el instrumento; esta lección te enseña sus límites, para que lo uses con los ojos abiertos. El proyecto (lección 8) va a mostrar el mismo fenómeno con el backlog completo de Mercado: cuando un solo input cambia, el ranking entero puede cambiar, y esa misma sensibilidad que hace útil al modelo (te permite ver el efecto de nueva evidencia) es la que lo hace vulnerable a la manipulación (te permite "ganar" moviendo un número sin evidencia real).

Una analogía: la báscula de cocina no elige la receta

Vuelve a la balanza de la presentación del módulo. Una báscula de cocina pesa con precisión los ingredientes que le pones: 200 gramos de harina son 200 gramos, sin importar nada más. Pero la báscula no decide qué cocinar, no sabe si la harina que le pusiste es la correcta para la receta, y no tiene forma de detectar si, en vez de harina, le pusiste azúcar disfrazada de harina para que la receta "salga mejor" en el papel. Pesa lo que le des, con exactitud absoluta, y esa exactitud no dice nada sobre si lo que le diste era honesto o correcto.

riceScore es esa báscula. Calcula con exactitud absoluta lo que le des —reach x impact x confidence / effort, sin errores de redondeo, sin favoritismos—, pero no tiene forma de verificar si el confidence que le diste es un dato real o un deseo disfrazado de dato. El chef —el equipo, tu criterio— es quien decide qué pesar y qué hacer con el resultado. La báscula ayuda; no cocina.

Ejemplo trabajado: la función no distingue un confidence honesto de uno inflado

Aislemos el problema con dos apuestas hipotéticas —no las de Mercado, para que veas el fenómeno sin la complejidad del backlog completo—. boringFix es "el arreglo aburrido pero necesario", con un confidence medido con datos reales: 0.8. favoriteProject es "tu proyecto favorito", con el mismo reach, impact y effort en el mismo orden de magnitud —la única variable que cambia entre las tres corridas es el confidence que tú decides declarar para él—:

// riceScore no distingue un confidence HONESTO de uno INFLADO: solo multiplica el numero
// que le des. Dos apuestas hipoteticas, mismo reach/impact/effort en orden de magnitud,
// para aislar UNA sola variable: el confidence que declaras para tu propio proyecto.
function riceScore({ reach, impact, confidence, effort }) {
  return (reach * impact * confidence) / effort;
}

// "El arreglo aburrido pero necesario" - confidence real y medido: 0.8 (datos solidos).
const boringFix = { reach: 4000, impact: 1, confidence: 0.8, effort: 1 };
const boringScore = riceScore(boringFix);

// "Tu proyecto favorito" - el reach/impact/effort son iguales de solidos; lo unico que
// cambia entre las tres corridas es el confidence que TU decides declarar.
function favoriteProject(confidence) {
  return { reach: 3500, impact: 1, confidence, effort: 1 };
}

console.log('=== boringFix (confidence medido: 0.8) ===');
console.log('  score = ' + boringScore + '\n');

console.log('=== favoriteProject, variando SOLO el confidence declarado ===\n');
for (const c of [0.5, 0.8, 1.0]) {
  const score = riceScore(favoriteProject(c));
  const winner = score > boringScore ? 'favoriteProject' : 'boringFix';
  const label = c === 0.8 ? '(mismo nivel que boringFix, honesto)' : c === 1.0 ? '(inflado a "estoy seguro")' : '(honesto, bajo)';
  console.log('  confidence=' + c + '  ' + label);
  console.log('  score=' + score + '  ->  gana: ' + winner + '\n');
}

console.log('La funcion no sabe si 1.0 es un dato real o un deseo. Solo multiplica.');

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

=== boringFix (confidence medido: 0.8) ===
  score = 3200

=== favoriteProject, variando SOLO el confidence declarado ===

  confidence=0.5  (honesto, bajo)
  score=1750  ->  gana: boringFix

  confidence=0.8  (mismo nivel que boringFix, honesto)
  score=2800  ->  gana: boringFix

  confidence=1  (inflado a "estoy seguro")
  score=3500  ->  gana: favoriteProject

La funcion no sabe si 1.0 es un dato real o un deseo. Solo multiplica.

Lee las tres corridas con atención. Con un confidence honesto y bajo (0.5), favoriteProject pierde claramente. Con un confidence honesto e igual al de boringFix (0.8), favoriteProject sigue perdiendo —su reach (3500) es un poco menor que el de boringFix (4000), y a igual confidence, eso basta para que pierda—. Pero con confidence: 1 —inflado, sin ningún dato nuevo que lo justifique, solo la convicción de quien defiende el proyecto— favoriteProject gana. La función hizo exactamente lo que se le pidió: multiplicar. No hizo nada incorrecto. El problema no está en la aritmética; está en el input, y la aritmética no tiene forma de detectarlo.

Esto es "garbage in, garbage out" en su forma más pura: el mismo código, corriendo perfectamente, produjo un resultado defendible en dos corridas y uno manipulado en la tercera, y la salida por sí sola no te dice cuál es cuál. Solo lo sabes si, para cada número, puedes responder "¿de dónde salió esto?" con una fuente real —exactamente la disciplina de calibración que armaste en la lección 5—.

El score informa; no reemplaza el criterio

Hay una segunda forma en que el scoring falla, más sutil que inflar un número: usarlo después de haber decidido, para justificar una decisión que ya tomaste por otras razones. Si el equipo ya decidió, políticamente, que van a construir X este trimestre, y luego calculan su riceScore ajustando los inputs hasta que el número "confirme" la decisión, el cálculo no está informando nada —está actuando de coartada—. La señal de que esto está pasando: los números cambian después de conocer el resultado que alguien quería, no antes.

La forma correcta de usar el score, en cambio, es exactamente al revés: estimas los cuatro inputs de cada apuesta antes de saber cuál "debería" ganar, con la mejor fuente disponible para cada uno, calculas, y entonces discutes el resultado —incluyendo la posibilidad de que el número sorprenda a todos, como pasó con fasterCheckout contra improvedSearch en la presentación—. Si el ranking nunca te sorprende, sospecha: puede ser que tu criterio ya era excelente, o puede ser que estés ajustando los inputs para que confirmen lo que ya creías.

Errores comunes

Inflar el Confidence para que tu apuesta favorita gane. Qué pasa: como viste en el ejemplo de hoy, alguien sube el confidence de su proyecto preferido a 1.0 sin un dato nuevo que lo justifique, específicamente para superar a otra apuesta en el ranking. Por qué pasa: confidence es el input más subjetivo de los cuatro y el más fácil de mover sin que nadie lo note de inmediato. Cómo detectarlo: pregunta, apuesta por apuesta, "¿qué cambió para que este número suba?" —si la respuesta es "nada, pero quiero que gane", ahí está el problema—. Cómo corregirlo: exige la fuente de cada confidence de 0.8 o más, siguiendo la tabla de calibración de la lección 5, antes de aceptar cualquier cambio al alza.

Ignorar el Reach y priorizar lo que te gusta técnicamente. Qué pasa: alguien argumenta a favor de una apuesta citando lo interesante que sería construirla, sin mencionar cuánta gente la usaría ni cuánto la movería —esencialmente, saltándose la fórmula por completo y usando el score solo cuando conviene—. Por qué pasa: el entusiasmo técnico es genuino y se siente como una razón suficiente. Cómo detectarlo: la defensa de una apuesta no incluye ninguno de los cuatro números de RICE, o los incluye solo después de que alguien los pide. Cómo corregirlo: como viste en la lección 4, un reach grande no es opcional en el argumento; si tu apuesta favorita no tiene buenos números, el criterio honesto es aceptar que no es la prioridad —no dejar de calcular para no tener que verlo—.

Tratar el score como verdad absoluta y apagar el criterio. Qué pasa: el equipo calcula el ranking una vez y lo trata como una decisión final e indiscutible, sin revisar los inputs cuando aparece nueva información, ni cuestionar un resultado que se ve raro. Por qué pasa: un número final se siente más objetivo —y más cómodo de defender— que seguir discutiendo criterio. Cómo detectarlo: nadie vuelve a mirar el riceScore de una apuesta después de calcularlo una vez, aunque hayan pasado semanas y haya nueva evidencia disponible. Cómo corregirlo: el score es una fotografía de tu mejor estimación hoy; cuando cambie la evidencia —un experimento nuevo, un dato de analytics que no tenías—, recalcula. El proyecto de la lección 8 practica exactamente esto: recalcular el ranking cuando un input cambia.

Ejercicios

Ejercicio 1 — Identifica la señal de alerta. En una reunión de priorización, alguien dice: "cambiemos el confidence de recommendations de 0.5 a 0.9, así queda mejor posicionada". ¿Qué es lo que falta en esa frase para que el cambio sea legítimo, según lo que viste en esta lección y en la lección 5?

Ver solución

Falta la fuente: la frase justifica el cambio por su efecto en el ranking ("así queda mejor posicionada"), no por evidencia nueva sobre recommendations misma. Un cambio legítimo de confidence se justifica con algo como "subimos el confidence de 0.5 a 0.8 porque corrimos un experimento piloto con recomendaciones simples y vimos una mejora clara en clics" —una razón que existiría independientemente de dónde quede la apuesta en el ranking—. Si la única razón dada es la posición final, es exactamente el patrón de "usar el score para justificar lo que ya decidiste" de esta lección.

Ejercicio 2 — Recalcula con el confidence honesto. Usando los datos de favoriteProject del ejemplo trabajado (reach: 3500, impact: 1, effort: 1), ¿qué confidence mínimo necesitaría para empatar exactamente con boringFix (score 3200)? Muestra el cálculo.

Ver solución

Se necesita resolver 3500 x 1 x confidence / 1 = 3200, es decir, confidence = 3200 / 3500 ≈ 0.914. Como confidence en RICE no tiene una escala fija de cinco valores como impact —es una fracción libre entre 0 y 1—, ese 0.914 (91.4%) sería el punto exacto de empate. Pero fíjate en el problema práctico: 0.914 no es un nivel de confianza que la tabla de calibración de la lección 5 reconozca fácilmente (los niveles de referencia son 1.0, 0.8, 0.5); un confidence "ajustado a mano" hasta un número tan específico, justo para empatar o superar a otra apuesta, es en sí mismo una señal de alerta de manipulación, sin importar si el número final "suena" razonable.

Ejercicio 3 — Diseña una regla anti-manipulación. Basado en lo que viste en esta lección, propón una regla simple que un equipo podría adoptar para reducir el riesgo de que alguien infle un confidence sin evidencia. (No hay una única respuesta correcta; evalúa tu propuesta contra el ejemplo trabajado.)

Ver solución

Una regla razonable, común en equipos que usan RICE en serio: cualquier confidence de 0.8 o más debe venir acompañado, por escrito, de la fuente específica que lo respalda —un enlace al experimento, al dato de analytics, o a la investigación que lo sostiene—. Sin esa fuente escrita, el confidence por defecto es 0.5 o menos. Aplicada al ejemplo trabajado: si alguien propone confidence: 1.0 para favoriteProject sin poder señalar una fuente concreta, la regla automáticamente lo devuelve a 0.5, y con 0.5 el score es 1750, muy por debajo de boringFix (3200) —el ranking honesto se restablece sin necesidad de que nadie "descubra" la manipulación en la reunión; la regla la previene antes de que ocurra—.

Resumen y siguiente paso

En esta lección le pusiste un límite honesto a la herramienta que construiste en las lecciones 3 a 6: RICE e ICE calculan con exactitud absoluta, pero no pueden distinguir una estimación real de una inflada —viste, con favoriteProject, que el mismo reach/impact/effort y solo un confidence manipulado bastan para voltear el ranking, sin que la función haga nada "mal"—. Esto es garbage in, garbage out, y la defensa no es dejar de usar el score: es exigir una fuente para cada input, especialmente para confidence, y usar el score antes de decidir, no después para justificar lo que ya se decidió.

Antes de avanzar deberías poder: explicar "garbage in, garbage out" con tus propias palabras aplicado a RICE; identificar la señal de que alguien está ajustando un input para ganar el ranking en vez de para reflejar evidencia; y distinguir "el score informa la decisión" de "el score reemplaza el criterio".

El proyecto de la lección 8 cierra el módulo llevando todo esto junto al backlog completo de Mercado: vas a puntuar y ordenar las cinco apuestas con prioritize, y luego vas a correr un análisis de sensibilidad —cambiar un solo input y ver cuánto se mueve el ranking— para comprobar, con números reales, exactamente cuán frágil o cuán robusta es una decisión de priorización según la calidad de sus estimaciones.

Recursos

• ProductPlan, "How to Choose the Right Feature Prioritization Framework" — productplan.com/learn/how-to-choose-the-right-feature-prioritization-framework. Panorama honesto de las limitaciones de los frameworks de scoring, incluida la subjetividad de estimar impact y confidence. En inglés.
• Melissa Perri, Escaping the Build Trap — sobre cómo hasta las herramientas más rigurosas de priorización fallan si se usan para justificar decisiones ya tomadas en vez de para informarlas; la misma tesis del módulo 1 aplicada al scoring. En inglés.
• Marty Cagan / SVPG, blog de Silicon Valley Product Group — svpg.com/articles — sobre por qué ningún framework reemplaza el juicio de un equipo de producto con buen criterio; los frameworks estructuran la conversación, no la sustituyen. En inglés.