He usado el modelo MoSCoW (pero no soy gerente de proyecto, soy desarrollador) y creo que es bueno. Pero también creo que puedes decirme más y quizás encontrar un inconveniente en el que no pensé mientras les digo a mis amigos y colegas que el modelo MoSCoW es un buen modelo de gestión de proyectos. ¿Puede decirme acerca de los peligros potenciales al utilizar este método? Identifico las tareas e identifico si la tarea es obligatoria ("M"), lo que deberíamos ("S"), lo que podríamos ("C") y lo que no haríamos ("W") en este momento. Tal vez una trampa potencial es que casi siempre termino trabajando solo con lo que el proyecto debe hacer y los deberes y los posibles solo se enumeran y casi nunca se implementan.
Aquí hay algunas trampas que he visto con el modelo MoSCoW.
Los gerentes están preocupados de que sus requisitos caigan en "debería" o "podría" y no se cumplirán, por lo que inventan razones por las que su requisito es un "debe". Esto termina retrasando la funcionalidad crítica para el negocio. (Esto generalmente es causado o exacerbado por malos KPI a nivel organizacional. No estoy seguro de que haya buenos KPI cuando están vinculados al pago. De hecho, estoy bastante seguro de que no los hay).
Se dedica tiempo a discutir cosas que "deberían", "podrían" o "deberían" suceder, retrasando el progreso de las cosas que son absolutamente esenciales. Esto se ve exacerbado por los gerentes preocupados por los elementos del proyecto que los ayudarían a lograr sus objetivos, pero que no son inmediatamente esenciales (KPI, nuevamente).
Los gerentes utilizan los requisitos "debería", "podría" y "debería" como formas de obtener un presupuesto adicional, que luego gastan como amortiguadores para el "debe". (También me encanta Beyond Budgeting ).
Los arquitectos y los responsables de otras dependencias compartidas dedican tiempo a crear soporte para todas las posibilidades, en lugar de centrarse en lo que "debe" hacerse. Debido a que lleva más tiempo crear realmente todos los "podría", "debería" y "sería", lleva más tiempo probar la arquitectura, por lo que la retroalimentación sobre si la arquitectura es apropiada también lleva mucho tiempo. Esta es una de las cosas que hace que los arquitectos actúen como guardianes tan estrictos y pasen siglos diseñando arquitecturas en primer lugar.
Con frecuencia, las cosas que "deben" hacerse son ideas que no han sido probadas, que nadie usa y que eventualmente se desechan de todos modos. Si se publicaron antes, también se descartarían antes, pero cuando se publican junto con el "debería" y el "podría", están entretejidos en la estructura de la aplicación o el sistema, y el retiro es mucho más difícil. . Pivotar (a la Lean Start-Up) se vuelve imposible.
Por eso tiendo a animar a las personas a diferenciar entre "debe, ahora mismo", centrarse en desarrollar y obtener comentarios sobre un MVP que sea lo más pequeño posible, y luego preocuparse por cuál es el próximo "debe, ahora mismo". Hecho deliberadamente y con previsión, esto conduce al desarrollo de arquitecturas, patrones de comunicación, relaciones organizacionales, etc. que son fáciles de cambiar, en lugar de correctos (ver también Opciones reales ).
La mayor ventaja es cuando trae una variedad de partes interesadas y habla sobre sus diferentes opiniones sobre lo que se debe hacer. Trate a Moscú como una herramienta para ayudar a facilitar la discusión y documentar el consenso. Esto ayudará a obtener una amplia aceptación de lo que debe estar compuesto el producto, con la esperanza de evitar la repetición del trabajo posterior.
Al contrario de @Jonathan Miles, cuestionaría la afirmación de que es simple. Me he encontrado con problemas cuando las partes interesadas comienzan a preocuparse demasiado por la semántica de "Debería haber" y "Podría haber". Esto puede ser mala suerte de mi parte, pero por lo general he reducido a MoSCoW a un paradigma MustHave-NiceToHave, donde el primero está en el alcance del proyecto y el segundo se pone en el estante.
Francamente, no veo que trabajar solo en los "Imprescindibles" sea necesariamente un escollo, ya que la entrega de la funcionalidad "Debería tener" y "Podría tener" generalmente sigue las leyes de rendimientos decrecientes.
Una ventaja definitiva es su simplicidad, no debería necesitar conocimientos previos o capacitación para comprender el concepto. Utiliza lenguaje humano para priorizar y definir requisitos en lugar de una escala o medida específica.
Aunque el contraargumento obvio es que puede ser demasiado simplista y no proporciona suficiente información sobre lo que se debe actuar primero. Es posible que haya llegado a un consenso sobre lo que DEBE entregar y tenga una lista de media docena de tareas, pero ¿cuál va a hacer primero? ¿Qué tareas dependen de otras tareas? ¿Dónde está tu camino crítico? Desde la perspectiva de la gestión de proyectos, habrá muchas preguntas sin respuesta.
En mi opinión, es una herramienta simple pero poderosa para la priorización inicial de requisitos de alto nivel. Es un excelente punto de partida para un proyecto, saber qué se debe entregar y qué se puede aplazar inicialmente ayuda mucho a la hora de tomar decisiones.
Aunque como un lado no, y me doy cuenta de que esto no es específicamente una desventaja del método en sí, sino más bien su implementación. Confiar demasiado en la lista de requisitos de una sola persona/equipo puede ser desastroso. Digamos que reunió a todos sus desarrolladores y elaboró una lista de prioridades de MoSCoW, ¿qué le dice eso? Aquí hay una lista de lo que el desarrollo cree que deberíamos estar haciendo. Pero, ¿qué pasa con el negocio, los clientes, otras partes interesadas, etc. están siendo representados? Una buena gestión de proyectos significa comprender los requisitos de todas las partes interesadas del proyecto, por lo que si decide utilizar el sistema MoSCoW, asegúrese de tener representación (y consenso cuando sea posible) de todas las partes interesadas.