Cómo priorizar features cuando todo el mundo pide algo distinto
Los frameworks de priorización fallan por el mismo motivo: los números se los inventa quien defiende la idea. Cómo montar un criterio que aguante una reunión con ventas.
Todos los frameworks de priorización que existen funcionan. Ese no es el problema.
El problema es que los números se los inventa la persona que defiende la idea. Le pones un 8 de impacto a lo tuyo y un 3 a lo del otro, y el framework confirma con aritmética lo que ya habías decidido. Es peor que no tener framework, porque le da apariencia de objetividad a una preferencia.
De dónde tienen que salir los números
Las dos únicas variables que importan son cuánto mueve algo y cuánto cuesta. La diferencia entre una priorización que sirve y una que no está en el origen de esas cifras.
Impacto se estima con tres preguntas concretas, no con una nota del 1 al 10:
- ¿A cuánta gente le pasa? Número de cuentas o de usuarios, sacado de tu base de datos.
- ¿Con qué frecuencia? Una vez al año o cada día no es lo mismo aunque afecte a los mismos.
- ¿Qué pasa hoy cuando ocurre? Lo resuelven a mano, abren un ticket, se van. El coste actual del problema es el techo del valor de resolverlo.
Si no puedes contestar las tres con algo verificable, no tienes una estimación, tienes una intuición. Y la intuición puede entrar en la lista, pero etiquetada como lo que es.
Esfuerzo se estima en semanas de equipo y lo estima quien va a hacerlo. No la persona que lo pide. Es obvio y se incumple constantemente.
El paso que casi nadie da
Antes de puntuar nada, agrupa las peticiones por problema, no por solución.
Vas a descubrir que ocho peticiones distintas son la misma cosa vista desde ocho sitios. “Quiero exportar a Excel”, “necesito un informe mensual”, “¿podéis mandarme los datos por correo?” suelen ser la misma persona intentando llevarse información a una reunión donde tu producto no está.
Priorizar las ocho por separado te lleva a construir tres cosas mediocres. Agruparlas te lleva a una que resuelve el problema real y quita las ocho de la lista.
Este paso, hecho bien, reduce un backlog a la mitad antes de puntuar nada.
Cómo ordenar sin discutir
Con los problemas agrupados y las dos cifras encima, el orden sale casi solo. Lo que hace falta después son dos reglas:
Regla del corte por capacidad. Mira cuántas cosas caben de verdad en el trimestre y traza una línea. Lo que queda debajo no es “para más adelante”, es “no”. Un roadmap con seis cosas empezadas y ninguna terminada es peor que uno con dos cerradas.
Regla del intercambio. Cuando llegue una petición nueva a mitad de trimestre, y va a llegar, la pregunta no es si la idea es buena. Todas lo son. Es cuál de las que ya estaban decididas se aparca para que entre. Con la lista delante, nueve de cada diez peticiones se caen solas.
Las tres trampas habituales
El cliente grande. Una cuenta importante pide algo y entra sin pasar por el criterio. A veces es correcto, porque retener esa cuenta vale más que el trimestre entero. Lo que no es correcto es que entre sin que nadie lo diga en voz alta, porque a los seis meses el producto está lleno de funcionalidades que usa un cliente.
El coste hundido. “Ya llevamos tres semanas en esto.” Las tres semanas están gastadas decidas lo que decidas. La única pregunta válida es si lo que queda por hacer vale lo que va a costar desde hoy.
Lo fácil primero. Es tentador porque produce sensación de avance. Y funciona una vez, como táctica para desatascar. Como criterio por defecto significa que lo estructural no empieza nunca, porque la capacidad nunca es cómoda.
Qué hacer cuando faltan datos
La respuesta honesta es que a veces no los tienes, y entonces la prioridad número uno es conseguirlos, no adivinar.
Veinte cuentas miradas una a una en una tarde te dicen más que cualquier estimación. Cinco conversaciones con usuarios sobre lo que hicieron la última vez te dicen más que veinte encuestas sobre lo que harían.
El método completo para conseguir esa evidencia está en qué es un sprint de discovery, y el caso concreto de priorizar funcionalidades con IA, donde el esfuerzo se estima especialmente mal, en cómo priorizar features de IA por impacto y esfuerzo.
El punto de control del trimestre
Al cerrar, la pregunta útil no es cuántas cosas entregasteis. Es cuántos de los problemas que priorizasteis dejaron de serlo.
Si entregasteis seis y ninguna movió el número que decíais querer mover, el criterio estaba mal aunque el equipo cumpliera. Y el sitio donde falló casi siempre es el mismo: algo entró por intuición y se vistió de dato.
Cómo se convierte esa lista en un documento que aguante el trimestre está en cómo hacer un roadmap de producto. Y si lo que necesitas es la lista de problemas reales para empezar, eso es lo que entrega una auditoría de producto.
¿Cuál es el mejor framework para priorizar features?
Cualquiera de los conocidos funciona si los números salen de datos y ninguno funciona si salen de opiniones. RICE, impacto y esfuerzo, o valor y coste dan resultados parecidos con los mismos inputs. La discusión sobre cuál usar suele ser una manera de evitar la discusión sobre de dónde salen las cifras.
¿Quién debe decidir la priorización?
Una persona decide y varias aportan datos. Los backlogs priorizados por consenso acaban con un poco de lo que quiere cada área, que es la manera más fiable de no mover ninguna métrica. Lo que sí conviene acordar en grupo es el criterio, no cada decisión.
¿Cómo se dice que no a una petición de un cliente grande?
No se dice que no, se enseña el intercambio. Con la lista del trimestre delante, la pregunta pasa a ser qué se aparca para que entre lo nuevo. Casi todas las peticiones se caen solas en ese momento, y la que entra lo hace con alguien aceptando el coste por escrito.