momomarrero

método MoSCoW de priorización

A la hora de afrontar y priorizar las tareas que nos han sido encomendadas, en ocasiones nos pasa algo parecido al síndrome de la hoja en blanco y el principio para resolverlo no es procrastinar sino aplicar metodología. Establecer las prioridades, cuáles son los criterios para esas prioridades, qué tareas serían más convenientes o aportarían valor extra, cuáles pudiendo hacerlo no aportan valor o lo encarecen y, sobre todo, qué no deben tener o no se debe hacer. Si no logramos organizar el proyecto o zozobra al primer paso, existe un sistema que puede ayudarnos a encauzarlo: el método MoSCoW, acrónimo de las expresiones en inglés Must have (debe tener), Should have (debería tener), Could have (podría tener) y Won’t Have (no tendrá).

Acuñado en 1994 por Daig Clegg, licenciado en Matemáticas por la Universidad de Birmingham y máster en Ciencias de la Computación en Birkbeck, Universidad de Londres, el método MoSCoW fue creado con el objeto de analizar requerimientos, funcionalidades y prioridades, el orden de cada uno de ellos y su impacto en el desarrollo de proyectos de gestión. Si bien fue concebido para el desarrollo de proyectos de software, la realidad es que se puede aplicar en cualquier otro ámbito o sector de actividad.

El método MoSCoW se caracteriza por poner el foco del proyecto en las prioridades reales para conseguir los objetivos fijados en cada etapa. A medida que se avanza en cada una de las etapas, quedan en evidencia las necesidades reales y las supuestas, así como el coste de oportunidad, pues se analizan continuamente los requisitos según las necesidades concretas de los clientes, tal y como es preceptivo en toda metodología ágil.

La aplicación del método MoSCoW se basará por tanto en priorizar el proyecto en función de los criterios ya comentados:

  • Must have (debe tener): en esta fase se determinan los requisitos mínimos para cumplir con los requerimientos básicos que se demandan. Han de coincidir con el Producto Mínimo Viable (PMV) o sea, con la versión del producto con limitadas funcionalidades (determinadas previamente) que permite su lanzamiento controlado y que aporta un valor fijado en el proyecto inicial. Es lo que denomino fase del proyecto de esfuerzo inicial.
  • Should have (debería tener): en esta fase se analizan y establecen los requerimientos que debería tener el proyecto, aun siendo prescindibles en esta fase; aquellos que aportarían valor añadido y diferenciador pero que no son determinantes para su desarrollo. Es lo que denomino fase del proyecto de esfuerzo sin características esenciales.
  • Could have (podría tener): en esta fase se analiza todo aquello que, siendo interesante, no resulta determinante, ni afecta al proyecto, ni aporta ingresos extra para afrontar su desarrollo, ni lo convierte en diferencial o reconocible. Es lo que denomino fase del proyecto de esfuerzo crucial.
  • Won’t Have (no tendrá): en esta fase se descartan, parcial o totalmente, por tiempo o coste, aquellos atributos que no son necesarios, pudiendo llegar a desarrollarlos (o no) en las versiones posteriores. Una buena alternativa es mantenerlos en la reserva por si algún cliente estuviera interesado y dispuesto a asumir el desarrollo ‘a la medida’ para incluirlo en versiones o fases posteriores del proyecto. Es lo que denomino fase del proyecto de no esfuerzo.

Es muy importante tener presente que en ninguno de los casos se acometerán requerimientos que el cliente no esté dispuesto a pagar, pues ello afectaría directamente a la cuenta de resultados. Este axioma solo se replanteará en caso de que los costes no afecten sustancialmente a la eficacia y la eficiencia del proyecto. Todos conocemos ejemplos de productos, proyectos o soluciones que ‘van a cambiar el mundo’ o que ‘marcarán una época’ y que finalmente lo único que consiguen es el quebranto y la inviabilidad de las empresas que los promueven. Como reza el dicho: ‘de héroes anónimos está el cementerio lleno’.

Otro elemento crucial es que los equipos de trabajo cuenten con recursos con la experiencia suficiente, expertise, y el conocimiento del producto y el mercado que permita poner el foco en atender la demanda latente del cliente para afrontar así de forma coherente el proyecto, sin olvidar lo más importante: su rentabilidad.

Como ocurre en la metodología scrum (de hecho es recomendable implantar ambas de forma solapada), los equipos han de ser reducidos, autosuficientes y trabajar en cortos periodos de tiempo, centrados en las exigencias marcadas por el product owner o portavoz del cliente, que es quien representa y establece sus necesidades. Es el responsable de maximizar el valor del producto y de gestionar la pila de producto (product backlog), el listado de tareas que se han de desarrollar en un proyecto, ordenadas en función de su valor dentro del mismo, y asociadas a un sprint).

Imagen: Momo Marrero

Deja una respuesta

HTML está permitido. Su correo no será publicado.

Subscribirse a los comentarios por RSS