Método MoSCoW explicado

Método MoSCoW - Toolshero

Método MoSCoW: este artículo explica el Método MoSCoW de una forma práctica. Después de leer, usted comprenderá los conceptos básicos de esta poderosa herramienta de administración.

¿Qué es el Método MoSCoW?

Priorizar es constantemente un reto. Particularmente cuando se trata de la implementación de nuevas ideas o tecnologías. Todos en una organización siempre quieren que todo se haga de inmediato y es prácticamente imposible. Hay varias herramientas disponibles para facilitar la priorización. El Método MoSCoW es una de ellos.

Dai Clegg de la compañía Software Oracle, creó el Método MoSCoW. Este método etiqueta cada requisito, lo que facilita la priorización.

A pesar del origen de este método de priorización es el desarrollo de software, también es altamente aplicable para lanzamientos de productos, comenzar un nuevo negocio o procesos de cambio. Con el Método MoSCoW, los requisitos se determinan para el resultado del proyecto o producto.

El Método MoSCoW trata de establecer los requisitos por orden de prioridad. Los requisitos más importantes necesitan cumplirse de primero para una mayor probabilidad de éxito.

Significado y acrónimo del Método MoSCoW

El Método MoSCoW es un acrónimo formado por las primeras letras. Los dos Os han sido agregadas para hacer legibles la palabra “moscow”, no tienen ningún significado. La M significa “Debe tener”, la S es “Debería tener”, la C es “Podría tener” y la W es “No tiene” o “No Tendría”.

Método MoSCoW - Toolshero
Figura 1 – el acrónimo del Método MoSCoW

Los requisitos cuando empiezas con el Método MoSCoW

Es buena idea especificar primero los requisitos antes de iniciar el Método MoSCoW. Al determinar los requisitos, debe tener en cuenta lo que es importante para todos los interesados. El intercambio de ideas con todos los involucrados llevará a buenos requisitos cualitativos.

Los requisitos se priorizan para evitar que se vuelvan costosos o poco realistas. El objetivo principal que agrega el mayor valor para la empresa. Los requisitos del proyecto se dividen en una de las siguientes categorías:

M – Must haves (Debe tener)

Se trata de los requisitos mínimos que se determinan de antemano que deben cumplir el resultado final. Sin cumplir con estos requisitos, el proyecto falla y el producto no se podrá usar. Son una necesidad para un producto viable y no hay alternativa. “Must haves- Debe tener” es esencial. MUST también se explica como un acrónimo que significa SubseTs de uso mínimo.

Ejemplo: Como un examen adicional, a los estudiantes de la University of Applied Sciences Automotive se les ha pedido que diseñen un automóvil que al menos pueda conducir (requisitos mínimos). Está bien si el coche solo tiene un chasis, sin ningún tipo de carrocería. Se trata de la construcción de las piezas individuales y del tren de transmisión al motor de combustión. En este caso, lo que debe tener es que tienen un automóvil manejable al final del año académico.

S – Should haves- (Deberia tener)

Estos son requisitos adicionales y muy deseados que tienen una alta prioridad, pero no son esenciales para un producto final utilizable. El producto será utilizable incluso si estos requisitos no se cumplen. Cuando se cumplan, solo aumentarán el valor del producto. Dependiendo del tiempo disponible, siempre puede volver a estos requisitos en un momento posterior.

Ejemplo: El estudiante de la University of Applied Sciences Automotive podría agregar una barra de remolque al automóvil (debería tener), pero siempre que el coche pueda conducir sin la barra de remolque, su proyecto tendrá éxito. Siempre pueden agregar la barra de remolque en una etapa posterior.

C – Could haves (Podría tener)

Estos requisitos pueden ser considerados si queda tiempo. Si no es así, no hay problema y no tendrá un efecto negativo en el resultado final. Los “Podría tener” tiene una prioridad más baja que “Debería tener”. Esta opción solo se incluirá si realmente hay tiempo más que suficiente para que funcione. Esta categoría también se conoce como “bueno tener”; son más un deseo que un requisito absoluto.

Ejemplo: A los estudiantes de University of Applied Sciences Automotive tal vez les gustaría instalar un tacómetro en el automóvil. No es un requisito importante (de examen), pero sería genial si se las arreglan para hacerlo.

W – Won’t haves (and would haves)- (No tiene- require)

Se trata de deseos para el futuro que a menudo son imposibles de realizar o que cuestan mucho tiempo. Si simplemente no es posible, es mejor no desperdiciar energía. Si se puede lograr, entonces se tendrá que invertir mucho tiempo (y dinero) y se etiquetará como “tendría”. “Los que tienen” son seguidos a menudo en una etapa posterior después de que se termina el proyecto inicial.

Ejemplo: los estudiantes de la University of Applied Sciences Automotive no tienen que fabricar un automóvil que conduzca en las carreteras públicas. Está destinado para el estudio. Si quieren tomarlo en las vías públicas, necesitará carrocería y cumplir con las normas de seguridad. También implica obtener la aprobación de la Agencia de Estándares de Vehículos en un proceso elaborado.

Fecha límite

La aplicación y el cumplimiento correctos del Método MoSCoW llevarán a una forma clara de liderar un proyecto. Todos los involucrados en el proyecto sabrán qué se debe hacer primero, cuándo se debe finalizar y por qué es importante. Al asignar prioridades a los requisitos, un proyecto se vuelve más manejable y será más fácil cumplir el plazo.

El desarrollo y soporte de un proyecto también se facilita al ignorar inicialmente los requisitos menos importantes. Al centrarse en los requisitos clave, usted termina con un producto vendible que cumple con los requisitos mínimos. De esa manera, deben haberse convertido en puntos de venta únicos, lo que beneficiará al comprador.

Ahora es tu turno

¿Qué piensas?, ¿cómo aplicas el Método MoSCoW en su proyecto u organización?, ¿reconoces la explicación práctica o tiene más para agregar?, ¿cuáles son sus factores de éxito para aplicar el Método MoSCoW?

Comparte tu experiencia y conocimiento en la caja de comentarios a continuación.

Si te ha gustado este artículo, suscríbete a nuestro boletín gratuito para obtener las últimas publicaciones sobre modelos y métodos de administración.

Más información

  1. Baxter, R. (2004). Software engineering is software engineering. In 26th International Conference on Software Engineering, W36 Workshop Software Engineering for High Performance System (HPCS) Applications (pp. 4-18).
  2. Stephens, R. (2015). Beginning Software Engineering. Wrox Publishing.
  3. Hatton, S. (2008). Choosing the right prioritisation method. In Software Engineering, 2008. ASWEC 2008. 19th Australian Conference on (pp. 517-526). IEEE.
  4. Robson, W.A., Simon, Shena. (2014). Moscow in the making. Taylor & Francis Ltd.

Cómo citar este artículo:
Mulder, P. (2017). Método MoSCoW. Recuperado [insertar la fecha] de Toolshero: https://www.toolshero.es/gestion-de-proyectos/metodo-moscow/

Fecha de publicación original: 06/06/2017 | Última actualización: 31/05/2023

Agrega un enlace a tu sitio web:
<a href=”https://www.toolshero.es/gestion-de-proyectos/metodo-moscow/”> Toolshero: Método MoSCoW</a>

¿Encontraste este artículo interesante?
¡Su calificación es más que bienvenida o comparta este artículo a través de las redes sociales!

¿Qué tan útil fue esta publicación?

¡Su calificación es más que bienvenida o comparta este artículo a través de las redes sociales!

Puntuación media 4 / 5. Recuento de votos: 4

¡Hasta ahora no hay votos! Sea el primero en calificar esta publicación.

¡Lamentamos que este post no te haya resultado útil!

¡Mejoremos este post!

Cuéntanos ¿cómo podemos mejorar este post?