Técnica de priorización MoSCoW

Cualquiera de nosotros sabría organizar a las famosas muñecas rusas, ordenándolas por tamaño y luego introduciendo la de menor tamaño en la siguiente mayor. Parece un juego de niños, pero dentro de la gestión de requisitos no lo tenemos tan claro. La técnica de priorización de requisitos MoSCoW nos puede ayudar a organizarlos y a dar un valor añadido a la clasificación, ya que la propia catalogación nos indica el camino correcto para llegar a la solución del puzzle del proyecto.

Cuando leemos como de bien o mal se desarrollan los proyectos, asustan los números sobre proyectos exitosos, sobre todo si nos fijamos en proyectos grandes.

La técnica de priorización de requisitos MoSCoW, ayuda a todo el equipo de desarrollo a entender las consecuencias reales de la asignación de la criticidad.

A la hora de desarrollo de los requisitos de negocio, considero una buena práctica catalogar las necesidades de los usuarios en función de la prioridad, pero en la mayoría de las organizaciones que lo ponen en práctica utilizan valores que no tienen un significado real para el resto del equipo de desarrollo.

• 1 Prioridad alta
• 2 Prioridad media
• 3 Prioridad baja

Me explico, al final no importa el nivel de criticidad que se le asigne a cada requisito, al final todo se tiene que hacer, y lo que se transmite al equipo es que los requisitos muy críticos tienen que probarse muy bien porque si no se queda colgado el sistema y los de criticidad baja, no pasa nada porque fallen “un poco”.

MoSCoW es un acrónimo, cuyas siglas en inglés significan:

Must have, Should have, Could have, and Would like but won’t get

Como se puede observar, la clasificación no se trata simplemente de poner un número a cada uno de los requisitos. Al realizar el análisis de los requisitos nos vamos dando cuenta de que no todo es obligatorio y que hay cosas que no vamos a realizar ahora. Las 4 letras son importantes para el equipo de desarrollo.

• M – MUST Requisitos que debe tener la solución. Son los requisitos mínimos que hacen usable la solución
• S – SHOULD Requisitos que debería incluir la solución. Requisitos importantes pero no obligatoriamente necesarios
• C – COULD Requisitos que podría incluir la solución. La guinda del pastel
• W – WON’T Requisitos que no se van a hacer (por el momento), pero que en un futuro podrían incorporarse

Se me vienen a mi cabeza muchas situaciones en las que no se utilizó la técnica MoSCoW. Pero quiero destacar una situación que denomino: “el aprendizaje”.

En un servicio de métricas software de una gran entidad bancaria, los requisitos sobre nuevos informes tenían desbordado al equipo. Los usuarios eran altos directivos de la entidad y todo era importante y necesario.

Así que decimos poner un control a todos los informes para calcular el uso que se daba a los informes. El resultado fue el esperado, algunos informes no se llegaron a ejecutar nunca, otros dejaban de usarse al poco tiempo de implantarse… No todo era importante y necesario.

Dejamos de publicar muchos informes y nadie protestaba, ni los echaba en falta y así teníamos más tiempo para dedicar a mejoras reales del servicio.

¿Te ha ocurrido en algún proyecto que te acuerdas de MoSCoW? ¿Proyectos que nunca llegaron a implantarse?