Establecer las prioridades para alcanzar el éxito en un nuevo proyecto no siempre es fácil, requiere un orden claro en el desarrollo de las funcionalidades que lo componen, conocer el impacto de cada uno o saber ponderar la importancia de cada uno de ellos en relación a los otros.

Técnica de priorización MOSCOW

Daig Clegg en 1994 ideó el método MoSCoW como técnica para priorizar requerimientos, se aplica en diversos ámbitos como pueden ser análisis de un negocio, la gestión de proyectos o el desarrollo de un nuevo software.

El termino MoSCoW es un acrónimo formado por las primeras letras de cada tipo de prioridad, se resume en las siguientes cuatro categorías: MUST have (debe tener); SHOULD have (debería tener); COULD have (podría tener); WON’T have (no tendrá).

En contraste con la forma típica de priorizar (alta, media, baja) donde al final da igual el nivel y todo se debe hacer (además esta forma de priorizar no ofrece una promesa clara sobre que esperar del producto final), con el método MoSCoW a medida que analizamos los requisitos nos damos cuenta que no todo es obligatorio ni hay que hacerlo en este momento, la escala que usamos tiene un significado intrínseco frente a otras técnicas tradicionales, las elecciones realizadas tendrán un impacto real sobre el producto final.

Categorías “Must, Should, Could, Won’t”

  • MUST have (debe tener): Se pueden considerar como atributos que determinan el MVP (minimum viable product), son requerimientos indispensables o mínimos y normálmente no son negociables, sino se logra el conjunto de requerimientos de este tipo se considera que el proyecto no ha tenido éxito.
  • SHOULD have (debería tener): Este tipo de requisitos suelen ser altamente deseables pero no cruciales. Puede tratarse de funcionalidades que no son tan urgentes en este momento (pero puede que lo sean en un periodo corto de tiempo). Este tipo de atributos se centran en obtener un mayor retorno de la inversión ROI, se pueden evaluar midiendo la cantidad de usuarios afectados por este requisito. El producto final aún sigue siendo plenamente funcional sin estos requerimientos.
  • COULD have (podría tendría): También se les conoce como nice-to-have. A pesar de que pueden ser interesantes no suelen ser importantes, no llevarlos a cabo no reduce la viabilidad del proyecto, no tienen gran impacto en el resultado final. Pueden ser funcionalidades extra que se acometan siempre y cuando quede tiempo y dinero una vez realizadas las anteriores o no exijan excesivo esfuerzo.
  • Won’t have/ Would-have (no tendría): Requisitos o deseos que no merecen aún la pena invertir en ellos. También se conocen como would have porque una empresa podría implementarlos bajo ciertas condiciones en el futuro.

Conclusiones, pros y contras del modelo MoSCoW

Está técnica se implementa de forma rápida y es sencilla de aplicar. Si se realiza en equipo todas las personas integrantes forman parte de la decisión de la prioridad de cada trabajo a realizar y cual debe ser el resultado final del conjunto.

Permite redirigir los recursos (materiales, de personas o tiempo) de los que disponemos a las categorías más importantes, si en algún momento te quedas sin recursos para seguir trabajando, te aseguras que lo más importante siempre está hecho.

Los deseos y requisitos nunca son estáticos, dependen de la situación y el momento, pueden cambiar de categoría a través del tiempo.

Este método se suele aplicar cuando existen plazos límite de entrega y debemos poner el foco en los requisitos más importantes.

Esta técnica está muy dirigida a aspectos funcionales o atributos que proporcionan un valor añadido sobre un producto final, puede casar muy bien para definir MVP de un nuevo proyecto.

Enlaces internos

Enlaces externos