MoSCoW: Qué es y cómo utilizarlo para priorizar
El diseño es importante. En esto creo que estaremos de acuerdo: hay que respetar los estándares de usabilidad, accesibilidad y también asegurar, en la medida de lo posible, que aquello que estamos diseñando es correcto a nivel estético.
Pero de nada sirve todo esto si no estás diseñando la funcionalidad adecuada.
Ya puedes estar trabajando en una pantalla que quedará preciosa, pero si esa pantalla está desconectada del resto o no aporta ningún tipo de valor para el usuario o para el negocio, no servirá para nada.
El trabajo de priorización suele correr de la mano de product owners, product managers y puestos similares, pero como product designers también tenemos algo que decir al respecto.
En este artículo te explico de qué va el método MoSCoW con ejemplos y con una propuesta para hacerlo en Notion.
¡Vamos allá!
¿Qué es el método de priorización MoSCoW?
No nos engañemos: priorizar es siempre una tarea difícil, porque cada persona implicada en el proyecto tendrá su opinión: al equipo de desarrollo quizás le sería más fácil hacer primero A, a algún stakeholder le interesaría poder tener primero B, quien diseña puede decantarse por C porque ayudaría a dar consistencia al user journey… y así hasta el infinito.
Este método de priorización siempre me ha llamado la atención por su nombre, que lo hace fácil de recordar, pero hasta las últimas semanas no había podido aplicarlo a un proyecto real.
En pocas palabras el método MoSCoW sirve para priorizar iniciativas (ya sean tareas, funcionalidades o lo que aplique en tu contexto) basando la decisión en la importancia que tienen. Idealmente se realiza junto con los stakeholders, de manera que todas las personas implicadas están tomando la decisión de forma conjunta, ya sea de forma síncrona o asíncrona.
Otra de las ventajas es que puedes utilizar MoSCoW para priorizar un sprint, una iniciativa mucho más grande y extensa en el tiempo, una pequeña funcionalidad… lo que necesites.
El nombre es, en sí mismo, un acrónimo construido con la primera palabra de las cuatro categorías de priorización.
Las 4 categorías de priorización de MoSCoW
Must-have
Son aquellas funcionalidades que el producto debe tener sí o sí. No son negociables y hay que hacerlas obligatoriamente. Podría ser por cuestiones legales, de seguridad o del negocio.
Una buena forma de saber si algo cae o no en esta categoría es hacerse la siguiente pregunta: ¿el proyecto funcionará/tendrá sentido sin esta funcionalidad?
Por poner un ejemplo sencillo: si estás trabajando en una aplicación cuyo foco es que los usuarios puedan compartir su ubicación con sus amigos, no tiene sentido que no se desarrolle o diseñe la pantalla que te permite seleccionar y compartir tu localización.
Should-have
Se trata de funcionalidades que sería bueno tener, pero que no tenerlas no implica el desastre del proyecto entero.
Suelen priorizarse para siguientes sprints que no impacten el actual. En este cajón caerían todas aquellas tareas que hacen referencia a optimizaciones de la performance, bugs menores u otras funcionalidades que estaría bien tener, aunque sin ellas el producto funciona adecuadamente.
Could-have
Me costó un poco diferenciar esta categoría de la anterior, pero me ayudó identificarlas como los «nice to have«: funcionalidades que estaría bien tener, pero cuyo impacto sería mejor que las que están en should-have y para las que no se tienen actualmente los recursos.
Son las típicas tareas y funcionalidades que quedan en el backlog y que a veces no llegan a pasar. Pueden ser varios los motivos que creen esta situación, pero a la práctica suelen ser algunos de estos tres:
- Las hay en el must-have o should-have van creciendo
- Se alarga su diseño e implementación
- Hay un cambio en los objetivos y es necesario priorizar con otro foco
Won’t have (for now)
Son las funcionalidades en las que no se trabajará. Ya sea por tiempo, recursos económicos, impacto en las métricas y/o en los objetivos…
Complementos del método MoSCoW
Ten en cuenta que no es un método infalible y que tiene que combinarse con un sistema de scoring que permita tener visión del tamaño de la funcionalidad: es importante priorizar en base a la importancia, pero también tienen que tenerse en cuenta los recursos actuales del equipo y los requisitos de tiempo y económicos que existan.
En este sentido, puedes utilizar diferentes maneras para estimar el tamaño (entre muchas otras):
- Tallaje de camisetas
- Eje cartesiano con un eje que representa el valor que aporta y otro la complejidad
- Método Opportunity scoring
MoSCoW en Notion
Seguramente podrías utilizar FigJam, Figma, Miro o cualquier herramienta similar, pero he utilizado Notion porque es donde tengo el resto de documentación sobre el proyecto y me resulta más fácil así.
Lo único que tienes que hacer es escribir /board para crear un tablero con tarjetas (en esa misma página o en otra) y poner nombre a las cuatro columnas del siguiente modo:
Priorización MoSCoW en Notion
Por último puedes asignar más propiedades a las tarjetas para poder mostrar «la talla de camiseta» o cualquier otro método que utilices para tener claro el tamaño de la funcionalidad, tarea o iniciativa 🙂
Apuntes finales
El método MoSCoW tiene sus ventajas y desventajas, como cualquier método: lo más importante es encontrar el que encaje mejor en tus circunstancias.
Como te decía al principio, a mí me ha sido útil esta semana, pero es posible que no me funcione cuando necesite priorizar una iniciativa mayor que la que tengo estos días entre manos.
El objetivo de este artículo es iniciar una serie de artículos en los que iré escribiendo sobre técnicas de priorización. Si te gustaría que continuase, déjamelo en los comentarios ^^