El síntoma más claro de un proyecto inmaduro es que todos los requisitos en el Backlog están marcados como «Prioridad Alta». Si todo es urgente, nada es urgente. Como Jefe de Proyectos, tu trabajo no es decir que sí a todo, es gestionar la escasez. Y para eso, el método MoSCoW (Must, Should, Could, Won’t) es el estándar de oro.
El Factor Emocional de los Requisitos
El problema de MoSCoW es humano. Al cliente le duele emocionalmente admitir que su funcionalidad favorita es un «Could have» (Podría tener) y no un «Must have» (Debe tener). Las reuniones de priorización se convierten en batallas de egos.
La IA como Árbitro Imparcial
Aquí es donde entra nuestro Agente de IA. En lugar de discutir tú con el cliente, dejas que el modelo clasifique los requisitos basándose en la definición objetiva del MVP (Producto Mínimo Viable). La máquina no tiene ego.
El Prompt «Clasificador MoSCoW»
ROL: Eres un Product Manager experto en Lean Startup y maximización de valor.
ENTRADA:
- Objetivo del MVP: [Ej: Validar si los usuarios compran el producto].
- Lista de Requisitos: [Lista de 20 funcionalidades].
TAREA: Aplica la matriz MoSCoW implacable.
REGLAS:
1. MUST HAVE: Solo lo que si falta, el producto es ilegal o inusable (Máximo 20% del total).
2. SHOULD HAVE: Importante pero doloroso de omitir.
3. COULD HAVE: "Nice to have" (Deseable).
4. WON'T HAVE: Fuera de alcance para esta fase.
JUSTIFICACIÓN: Para cada item movido a "Could" o "Won't", explica por qué no aporta al objetivo central del MVP.
Llevar esta lista pre-clasificada a la reunión cambia la dinámica. Ya no dices «Yo creo que esto no es importante». Dices «El análisis de viabilidad sugiere que esto es un ‘Could’. ¿Tenéis datos para rebatirlo?».
Preguntas que te podrías estar haciendo
Significa: Must have (Debe tener – Crítico), Should have (Debería tener – Importante pero no vital), Could have (Podría tener – Deseable si sobra tiempo), y Won’t have (No tendrá – Descartado por ahora).
Falla por el miedo a perder. Los stakeholders marcan todo como «Must» porque temen que si lo marcan como «Should», nunca se desarrolle. Esto satura al equipo y garantiza el retraso.
Según las mejores prácticas de DSDM y Agile, los requisitos «Must Have» no deberían superar el 60% del esfuerzo total del equipo. Esto deja un 40% de margen de contingencia para imprevistos (que pueden usarse para los «Should» si todo va bien).
La IA actúa como una tercera parte neutral. Al clasificar los requisitos basándose en la lógica del MVP y no en la política de la oficina, ofrece un punto de partida objetivo para la negociación, despersonalizando el conflicto.
Referencias Técnicas y Bibliografía
- Clegg, D. & Barker, R. (1994): «Case Method Fast-Track: A Rad Method». (Origen del método MoSCoW).
- Ries, E. (2011): «The Lean Startup». (Concepto de MVP y desperdicio en funcionalidades no validadas).
- Agile Business Consortium: «Prioritisation and MoSCoW». (Guía oficial DSDM).
Autor
Antonio Gutiérrez es un Jefe de Proyectos IT con una amplia trayectoria en la dirección de equipos técnicos y el desarrollo de negocios online. Especialista en optimización de procesos y gestión de proyectos con tecnología IA, destaca por su capacidad para integrar soluciones innovadoras en entornos digitales complejos. Con una fuerte vocación por la formación y la responsabilidad profesional, Antonio se dedica a transmitir su experiencia en jefatura de proyectos para ayudar a otros a evolucionar en el sector tecnológico. Actualmente, ofrece consultoría estratégica y recursos especializados para profesionales que buscan liderar con éxito la transformación digital.
