Priorización de las funcionalidades de un proyecto con RICE

Uno de los aspectos más importantes –y delicados- a la hora de desarrollar el alcance de un proyecto, es definir qué funcionalidades y características debe contener. Evidentemente, si pudiésemos crear un producto con “todo incluido” desde el principio, sería genial… ¿o no?.

Si estamos planificando la venta de un producto nuevo, existe un riesgo muy elevado de que lo que nos pueda parecer genial a nosotros, no sea lo que realmente se necesite o que no sea del agrado de los usuarios.

Para reducir el riesgo, es una buena idea crear un producto básico, MPV (Mínimo Producto Viable) que contenga la esencia y el valor clave del producto, y ver cómo responde el mercado. De forma que, de su feedback, podamos avanzar y dispongamos, además, de la oportunidad de seguir en la línea correcta implementado mejoras y ajustando el producto a las necesidades reales (ya probadas).

¿Cuáles son las funcionalidades que debe contener?

Sin duda, aquí está el reto; identificar qué características deben priorizarse frente al resto. Existen muchos métodos para ayudar al equipo y al responsable del producto en esta importante tarea y entre ellas, me gustaría describir el método RICE.

RICE no es la traducción de “arroz”

En concreto es un método que sirve para priorizar funcionalidades dentro de un proyecto teniendo en cuenta factores diversos, con el objetivo de conseguir un ratio o valor que permita comparar –objetivamente- dichas características y, por tanto, facilitar su priorización.

1. R = Reach: Con este factor debemos valorar cuántas personas serán afectadas por la funcionalidad en un periodo concreto. Si la estimación la realiza el equipo, se debe tomar en cuenta que “las ganas de que se incluya” puede generar un sesgo importante. La buena práctica es la de identificar datos independientes y lo más objetivos posible.

2. I = Impact: Ahora hay que decidir cómo de alineada está la funcionalidad con la estrategia del producto y su filosofía. Podemos usar valores cualitativos como, por ejemplo: 5 puntos para una gran alineación, 3 para media, 1 para baja y 0,5 para mínima. Evidentemente si no tiene ninguna, la funcionalidad debería ser descartada.

3. C = Confidence: Debemos determinar el nivel de confianza que se tiene en que la funcionalidad será un éxito. De la misma forma que para el cálculo de “R”, conviene evitar el sesgo en lo que sea posible. Una alternativa sería la de buscar la opinión de posibles usuarios o expertos en el tema. Se pueden usar escalas similares a las de “I”.

4. E = Effort: Otro aspecto a tener muy en cuenta es el esfuerzo necesario para que se pueda añadir (y que funcione correctamente) la característica. El valor se puede expresar de diferentes formas, dependiendo de la disponibilidad de información o de cómo se estime el esfuerzo en el proyecto. Podría ser jornadas/hombre, costo, tiempo, etc.

Una vez que se tienen estos datos, se puede aplicar la siguiente fórmula, que representaría el impacto de la implementación de cada funcionalidad según el esfuerzo:

RICE = (R x I x C) / E

En siguiente ejemplo vemos como de las posibles opciones, las tres primeras son las que tienen una combinación de factores más valiosos para el proyecto.

Así, podemos concluir y asegurar, que para priorizar una funcionalidad, en muchos casos, no es útil ni efectivo aplicar un solo factor, ya que en muchos casos, no es suficiente para comprender la complejidad del impacto del mismo en diversos aspectos del producto, por lo que métodos como el RICE, que puede combinarse con otros como el KANO (identificar las funciones básicas, las de rendimiento y las emocionantes), matrices de esfuerzo/impacto, MoSCoW y otros, ayudan a priorizar reduciendo el sesgo.