Frameworks de priorización: RICE, MoSCoW, Kano e ICE
RICE, MoSCoW, Kano e ICE son frameworks para decidir qué construir primero. Qué mide cada uno, cómo se aplica, sus límites y cuál elegir según el caso.
¿Para qué sirve priorizar con un framework?
Porque casi nunca hay tiempo para todo. Sin criterios explícitos, las prioridades las decide quien habla más fuerte, o la última reunión. Un framework no elimina la discusión, pero la obliga a hacerse con criterios visibles: qué asumimos, qué pesa más y por qué.
Para un diseñador, la priorización es parte del trabajo. Decidir qué flujo rediseñar primero, qué problema de accesibilidad atacar o qué estado de error faltante completar es, en el fondo, una decisión de prioridad. Si esa decisión no se justifica, el equipo termina haciendo lo más visible, no lo más importante.
Si la discusión gira en torno a qué medir, revisa outcomes frente a outputs antes de puntuar. Y si necesitas ordenar las prioridades en el tiempo, el roadmap de diseño es el lugar donde viven.
¿Qué mide cada framework?
| Framework | Criterios | Escala | Mejor para |
|---|---|---|---|
| RICE | Alcance, impacto, confianza, esfuerzo | Números; impacto de 3 a 0.25 | Comparar muchas iniciativas con datos |
| MoSCoW | Obligatorio, importante, deseable, fuera | Categorías, sin números | Alcance de una entrega o sprint |
| Kano | Cómo se siente el usuario ante la función | Cinco categorías (must-be, one-dimensional, attractive, indifferent, reverse) | Entender qué valora el usuario |
| ICE | Impacto, confianza, facilidad | 1 a 10 por factor | Decisiones rápidas, experimentos |
¿Cómo funciona cada framework?
RICE
RICE combina cuatro factores en un solo puntaje. Intercom lo describe como un modelo para decidir qué construir.
- Alcance (Reach): cuántas personas o eventos afecta en un periodo, por ejemplo “clientes por trimestre”.
- Impacto (Impact): cuánto afecta a cada persona alcanzada; cada equipo puede medirlo con su propio objetivo, como la conversión. Intercom usa 3 (masivo), 2 (alto), 1 (medio), 0.5 (bajo) y 0.25 (mínimo).
- Confianza (Confidence): qué tan seguros estamos de los números. Intercom usa 100 %, 80 % y 50 %, y advierte que por debajo de eso la iniciativa es una “moonshot”.
- Esfuerzo (Effort): en meses-persona, sumando el tiempo de producto, diseño e ingeniería.
La fórmula es (Alcance × Impacto × Confianza) / Esfuerzo. Intercom admite que puntuar el impacto es subjetivo, y que RICE no es una regla rígida: las dependencias o las funciones básicas (“table stakes”) pueden justificar trabajar antes en algo con menor puntaje. Recomienda revisar el resultado y ajustar las estimaciones si el orden no cuadra. El valor de RICE está en obligar a escribir los números, no en el número final.
MoSCoW
Dai Clegg lo propuso en 1994 para el desarrollo rápido de aplicaciones, y hoy se usa mucho en entregas con alcance fijo. Sus cuatro categorías, según la definición de Wikipedia:
- Must have: crítico para la entrega actual.
- Should have: importante, pero no necesario para esta entrega.
- Could have: deseable, pero no necesario.
- Won’t have: acordado con los stakeholders como lo menos crítico, por ahora.
Su límite principal es que no ayuda a ordenar elementos dentro de la misma categoría. Además, “Won’t have” es ambiguo: puede significar “no en esta versión” o “nunca”.
Kano
Noriaki Kano lo desarrolló en los años ochenta. En lugar de puntuar, clasifica cada función según cómo afecta la satisfacción. Wikipedia lista cinco categorías (must-be, one-dimensional, attractive, indifferent y reverse); las tres más útiles para diseño son:
- Must-be: requisitos que el usuario da por sentados. Si faltan, generan insatisfacción fuerte; si están, casi no suman. Un freno que funcione en un coche es un ejemplo de Wikipedia.
- One-dimensional: la satisfacción sube con el rendimiento. Más velocidad, más precisión, más opciones (dentro de lo razonable).
- Attractive: funciones que el usuario no espera y que generan satisfacción cuando están. Son las que se recuerdan.
Kano sirve para decidir en qué invertir más allá de lo que el usuario pide. La página de Wikipedia advierte que varias secciones de su texto no citan fuentes, así que conviene verificar la clasificación con investigación propia.
ICE
ICE se atribuye a Sean Ellis y califica tres factores, de 1 a 10: impacto (cuánto mueve la aguja), confianza (qué tan seguros estamos de ese impacto) y facilidad (cuánto esfuerzo cuesta). El puntaje es el producto de los tres.
Es rápido, pero casi todo es subjetivo: dos personas pueden dar notas distintas. ProductPlan indica que probablemente no es el mejor método para priorizar un roadmap completo. Funciona mejor para experimentos cortos, donde la discusión es lo valioso.
¿Cuándo NO conviene un framework?
- Cuando ya sabes que algo es urgente, por ejemplo un error crítico en producción.
- Cuando no tienes datos ni hipótesis. Un framework con números inventados da una falsa precisión.
- Cuando la prioridad depende de estrategia, no de puntajes. Para eso sirve revisar primero la estrategia y visión y la métrica norte del producto. Una vez claros los objetivos, el framework ordena lo demás.
- Cuando el equipo usa el puntaje para no discutir. El framework es el inicio de la conversación, no el final.
Ejemplo
Ejemplo ilustrativo: un equipo de diseño tiene siete mejoras candidatas para el próximo trimestre. Aplica RICE a tres de ellas. Una mejora de formularios afecta a 4.000 personas por trimestre, con impacto alto (2), confianza media (80 %) y esfuerzo de 1 mes-persona. El puntaje es 4.000 × 2 × 0,8 / 1 = 6.400. Otra mejora afecta a 800 personas, con impacto masivo (3), confianza baja (50 %) y 3 meses de esfuerzo: 800 × 3 × 0,5 / 3 = 400. La primera gana. El equipo discute la confianza de la segunda y decide hacer una prueba antes de comprometer tres meses.
Para tu próxima priorización: elige cinco iniciativas, escribe cada criterio con un número aunque sea aproximado, y revisa si el orden te sorprende. La sorpresa es una pista de que algún supuesto está mal.
Errores comunes
- Aplicar un framework sin acordar la escala. Un “impacto alto” para una persona no es lo mismo que para otra.
- Usar números sin datos y tratar el resultado como verdad.
- Usar MoSCoW para roadmaps largos, donde no distingue prioridades dentro de cada categoría.
- Clasificar con Kano sin preguntar a usuarios. Las categorías describen cómo reaccionan las personas, no lo que opina el equipo.
- Ignorar la estrategia y priorizar solo por puntaje.
- No revisar el resultado: si el orden no tiene sentido, el framework está mal configurado.