¿Qué es el método MoSCoW?

Alba Usar
15/03/2023

Cuando te embarcas en un proceso de mejora es posible que te sientas abrumado por todas las áreas o aspectos que podrías cambiar o mejorar: un nuevo software, una mejora en los procesos, etc. Por ello, priorizar es la única solución para poner el foco en lo verdaderamente importante. Una herramienta muy común es el Método MoSCow, un sistema de priorización generalmente utilizado en Project Management. Si has oído hablar de la metodología agile seguro que te suena este concepto. Sigue leyendo y descubre qué es el método MoSCoW y qué valor puede aportarte a ti y a tu empresa.

Método MoSCoW

El Método MoSCoW es una herramienta que se utiliza habitualmente en la gestión de proyectos y en el desarrollo de productos o servicios como softwares. En TAKTIC lo utilizamos para el análisis de soluciones en materia de digitalización de las empresas, una fase previa a la búsqueda de soluciones y partners para encontrar las herramientas que necesitan nuestros clientes.

¿Por qué utilizar el Método MoSCoW?

Priorizar puede que sea una de las tareas más difíciles cuando empiezas un proyecto de transformación digital, de selección de software o de reingeniería de procesos ya que intervienen varios agentes y cada uno tiene su visión y sus prioridades.

Por ejemplo, tomando como referencia un proyecto de selección de software donde tenemos tres requisitos A, B y C. Podemos encontrarnos en la situación de que, para el equipo de desarrollo, el requisito más fácil de conseguir sea el B porque ya lo tiene implementado su solución. Sin embargo, para la empresa que va a utilizar la herramienta, el que más se adapta a sus necesidades es A. En este caso se produce un conflicto de prioridades donde el método MoSCow es de gran utilidad. ¿Por qué? La respuesta es sencilla, aporta una visión mucho más objetiva y externa de lo que es realmente necesario además de servir para la toma de decisiones.

Las cuatro categorías MoSCoW para la priorización

El acrónimo que da nombre a este método proviene de las cuatro categorías de priorización que Dani Clegg consideró y utilizó para crear este sistema en 1994 que son:

Método MoSCoW TAKTIC

Must Have (M)

Esta categoría la podemos llamar “la imprescindible”. Son aquellas tareas o funcionalidades que deben estar sí o sí. No hay cabida para la ambigüedad ni son negociables, hay que hacerlas de manera obligatoria.

Para verlo más claro podemos hacernos las siguientes preguntas:

  • En un análisis de requerimientos funcionales: ¿Conseguiremos nuestro objetivo del proyecto sin esta funcionalidad en la herramienta?
  • En una reingeniería de procesos: ¿El proceso funcionará correctamente y tendrá sentido sin este paso?

Los puntos Must Have son los requisitos mínimos o críticos, es decir, el producto mínimo viable o MVP. Por lo tanto, son los aspectos que hay que tener primero resueltos y, si prescindimos de ellos, el proyecto dejará de tener sentido y será un fracaso.

Ejemplo:

El cliente necesita que el nuevo sistema gestione hasta 5 descuentos de compra diferentes mientras que el software, de manera estándar, gestiona únicamente 2. Esto es una necesidad del negocio del cliente y tiene que estar contemplada en el sistema obligatoriamente.

Should Have (S)

Aunque también son críticos, no son imprescindibles. Son tareas de gran importancia que aportan valor al proyecto y contribuyen de manera importante a alcanzar los objetivos y el éxito de este en cuestión. La ausencia de estas tareas (o funcionalidades), a diferencia de las primeras, no constituye un fracaso del proyecto. Es por esto por lo que, aunque en una fase inicial del proyecto no se puedan llevar a cabo, hay que tenerlas en cuenta para las siguientes fases o sprints ya que no podemos incurrir en el error de no hacer ninguna de estas.

Ejemplo:

Un requisito Should Have podría ser que el sistema informe al usuario del importe mínimo de un pedido de compra para llegar a un tramo de descuento determinado. Por ejemplo, si se está realizando un pedido de 900€, el sistema envía una notificación al usuario informando de que añadiendo 100€ al pedido se obtiene un 3% de descuento. Esto puede ser un Should porque aporta valor al cliente y al usuario, pero no es imprescindible.

Could Have (C)

Como ya puedes imaginar, en esta categoría situaremos aquellas características que son menos importantes que las Should have pero más importantes que las Won´t have. También son conocidas como nice-to-have y se refieren a aquellas que estaría bien tener si disponemos de los recursos y el tiempo necesario dentro del proyecto. Si no es el caso, no deberían llevarse a cabo en ese momento.

Ejemplo:

Un Could podría ser que el sistema, mediante inteligencia artificial (IA), realice una propuesta de copras para obtener las necesidades que hay que cubrir en los siguientes días teniendo en cuenta los mejores precios, promociones, etc. Sin duda, es un requerimiento interesante y que puede aportar mucho valor, pero en el momento del proyecto, debido al coste de este desarrollo, se decide categorizarlo como Could para realizarlo en fases posteriores.

Won´t Have (W)

Por último, tenemos las características Won´t have, aquellas en las que todavía no merece la pena invertir. No se trabajarán y no afectarán de manera relevante al proyecto, aunque es posible que en un futuro sí sea algo en lo que merezca la pena invertir.

Ejemplo:

Un requisito Won´t podría ser que el sistema coloree en rojo aquellos productos cuyo precio de compra en el momento sea un 20% superior a la última compra. 

Aunque esta herramienta sirve de gran ayuda para disminuir la incertidumbre y tomar decisiones, no nos podemos olvidar de que la situación empresarial es muy variable por lo que deberemos tener en cuenta que las necesidades de la empresa pueden cambiar obligándonos a ajustar nuestras prioridades.

Si necesitas una visión experta y externa que te ayude a priorizar y/o a realizar la gestión de tus proyectos, nuestros Project Managers te ayudarán. ¡Contacta con nosotros!

Artículos relacionados

Comienza tu
transformación
digital integral

    Scroll al inicio