Cuando un grupo está comprometido, clasificar las cosas en orden de importancia es una tarea difícil. Si alguna vez has organizado una fiesta de cumpleaños con un grupo de amigos, sabes cómo una persona está interesada en gastar todo el dinero en decoración, mientras que otra cree que el pastel debería tener prioridad, y otra más cree que tu dinero debería destinarse a encontrar el lugar adecuado.
Considera lo difícil que es lograr que un equipo esté de acuerdo en la prioridad adecuada para los esfuerzos en un lanzamiento. Aquí es donde entra en juego el sistema de priorización MoSCoW.
¿Qué es MoSCoW?
Debe tener, debería tener, podría tener y no tendrá, no tendrá ahora mismo, son los cuatro tipos de proyectos representados por la abreviatura MoSCoW. El método MoSCoW, también reconocido como priorización MoSCoW o análisis MoSCoW, es una técnica de priorización utilizada en gestión, consultoría de gestión, desarrollo de productos e ingeniería de software para comprender el valor que las partes relevantes otorgan a la entrega de cada requisito.
Al proporcionar definiciones claras para cada nivel de prioridad, la priorización MoSCoW aborda uno de los principales inconvenientes de las tecnologías de priorización menos robustas. Cuando algo se marca como una característica "debe tener" en MoSCoW, todos en el equipo entienden que no puede ser ignorado durante el desarrollo del proyecto. Los miembros del equipo de producto y las partes interesadas deben trabajar juntos para completar los niveles del modelo MoSCoW. No solo se deben asignar características y conceptos a cada nivel del modelo MoSCoW, sino que cada nivel también debe tener una cierta cantidad de recursos asignados. Al proporcionar definiciones claras para cada nivel de prioridad, la priorización MoSCoW aborda uno de los principales inconvenientes de las tecnologías de priorización menos robustas. Cuando algo se marca como una característica "debe tener" en MoSCoW, todos en el equipo entienden que no puede ser ignorado durante el desarrollo del proyecto. Los miembros del equipo de producto y las partes interesadas deben trabajar juntos para completar los niveles del modelo MoSCoW. No solo se deben asignar características y conceptos a cada nivel del modelo MoSCoW, sino que cada nivel también debe tener una cierta cantidad de recursos asignados.
¿Por qué es Importante MoSCoW?
El enfoque MoSCoW es beneficioso para desarrollar un producto sólido por varias razones. Primero, ayuda a crear un cronograma del proyecto al decidir qué tareas deben realizarse primero. Todos entienden los elementos más críticos, lo que le da al proyecto una sensación de orden.
Segundo, el método MoSCoW es bueno para establecer objetivos del proyecto tanto para el equipo como para las partes interesadas. Les da a los inversores una comprensión decente de qué esperar del proyecto, así como una estimación de cuánto costará cada componente.
Tercero, incluir MoSCoW en tu enfoque de trabajo ayudará a mantener la visión del proyecto en el camino correcto. Es normal que tu personal se desvíe más allá de las necesidades y restricciones del proyecto mientras realizan lluvia de ideas con colegas, encendiendo tu imaginación y esforzándose por empujar los límites.
Aunque esto es excelente para la etapa de concepto, no es ideal cuando se trabaja en un producto. Todos tienen una lista de verificación clara de lo que están haciendo gracias a MoSCoW, en contraste con una visión vaga y multidimensional.
Categorías de Priorización MoSCoW
Para identificar la relevancia de los proyectos, las categorías de priorización MoSCoW utilizan un conjunto simple de criterios. Los criterios MoSCoW ayudan a los equipos a priorizar de manera planificada y lógica. Esta técnica reduce el tiempo desperdiciado, las disputas y la desinformación. También elimina tanto prejuicio como sea posible del proceso, permitiendo que todos vean las necesidades objetivamente.
Las cuatro categorías de necesidades prioritarias son las siguientes.
1. Debe Tener
Estas definen el DEBE de los criterios que el proyecto debe cumplir. Algunos de los siguientes pueden usarse para definirlos. No tiene sentido entregar a tiempo si esto no se hace; si no se hace, no hay valor en implementar la solución a tiempo.
- Sin ello, no es legal.
- Sin ello, estás en peligro.
- Sin ello, no podremos proporcionar una solución viable.
Considera el siguiente escenario: '¿Qué sucede si esta condición no se cumple?' Si la respuesta es 'cancelar el proyecto - no tiene sentido construir una solución que no cumpla esta demanda', entonces el requisito es un Debe Tener.
2. Debería Tener
Los siguientes son algunos ejemplos de requisitos:
- Importante, pero no necesario.
- Aunque puede ser difícil dejarlo fuera, la respuesta sigue siendo práctica.
- Puede ser necesaria alguna forma de solución alternativa, como gestión de expectativas, ineficiencia, una solución existente, documentación, etc. La solución alternativa puede ser solo temporal.
- La solución alternativa puede ser solo temporal.
Examinar el grado de sufrimiento causado por el requisito que no se satisface, evaluado en términos de valor comercial o número de personas afectadas, es un enfoque para distinguir una demanda Debería Tener de un requisito Podría Tener.
3. Podría Tener
Los criterios se definen de la siguiente manera:
- Preferido o deseado, pero no crítico.
- Si lo dejas fuera, tendrá un impacto menor.
Porque solo se proporcionarían en su totalidad en el mejor de los casos, son los requisitos que ofrecen el mayor grupo de contingencia. Cuando surge un problema y la fecha límite está en peligro, uno o ambos de los Podría tener ofrecen la opción inicial de lo que debería eliminarse del cronograma.
4. No Tendrá Esta Vez
Esta es una lista de requisitos que el equipo del proyecto ha decidido que no se cumplirán (como parte de este marco de tiempo). Están listados en la Lista de Requisitos Priorizados, que ayuda a definir el plan del proyecto. Esto evita que sean reintroducidos extraoficialmente en un período posterior.
Los No Tendrá pueden ser muy efectivos para mantener la atención en los Podría Tener, Debería Tener y especialmente Debe Tener más cruciales en este momento.
Plantillas de Matriz MoSCoW
Ejemplo 1
El siguiente ejemplo es la plantilla MoSCoW para las cuatro categorías principales de priorización MoSCoW. Todas estas categorías están definidas de manera concisa y resumida para que los estudiantes las comprendan fácilmente. Estas 4 categorías son los requisitos principales de la plantilla MoSCoW antes de que comience cualquier proyecto. Esta es una excelente manera de priorizar lo que debes comenzar primero en el proyecto.