27. Priorización de requerimientos

27.1 Introducción

La priorización de requerimientos permite decidir qué se construirá primero, qué puede esperar y qué quizá no debe incluirse. Es necesaria porque los proyectos tienen recursos limitados: tiempo, presupuesto, personas, capacidad técnica y atención de los interesados.

No todos los requerimientos tienen el mismo valor, urgencia, riesgo o costo. Algunos son esenciales para que el sistema funcione; otros son mejoras convenientes; otros pueden quedar para versiones futuras.

Priorizar no significa ignorar necesidades, sino tomar decisiones explícitas y justificadas.

27.2 ¿Qué significa priorizar?

Priorizar es ordenar requerimientos según criterios acordados, para decidir el momento o la importancia relativa de su implementación.

Priorizar responde a la pregunta: si no podemos construir todo al mismo tiempo, ¿qué debe hacerse primero y por qué?

La priorización debe considerar valor, urgencia, riesgo, dependencias, costo, restricciones y objetivos del producto.

27.3 Por qué es necesaria

La priorización es necesaria porque:

  • El alcance suele ser mayor que la capacidad disponible.
  • Los interesados tienen expectativas diferentes.
  • Algunas funciones dependen de otras.
  • Hay restricciones de tiempo o presupuesto.
  • Algunos requerimientos reducen riesgos importantes.
  • Es conveniente entregar valor por etapas.
  • El contexto puede cambiar durante el proyecto.

Sin priorización, todo parece igualmente importante y las decisiones se vuelven confusas.

27.4 Criterios de priorización

Existen distintos criterios para priorizar. Lo importante es que sean explícitos y entendidos por los interesados.

Criterio Pregunta principal
Valor de negocio ¿Cuánto contribuye a los objetivos del producto?
Urgencia ¿Debe estar disponible pronto por una fecha, problema o compromiso?
Riesgo ¿Ayuda a reducir incertidumbre técnica, legal u operativa?
Esfuerzo ¿Cuánto trabajo requiere construirlo?
Dependencias ¿Habilita o bloquea otros requerimientos?
Obligatoriedad ¿Es exigido por ley, contrato o condición crítica?
Impacto en usuarios ¿Cuántos usuarios se benefician y cuánto mejora su trabajo?

27.5 Valor de negocio

El valor de negocio indica cuánto aporta un requerimiento a los objetivos del producto u organización.

Un requerimiento puede aportar valor porque:

  • Reduce costos.
  • Aumenta ingresos.
  • Disminuye errores.
  • Mejora experiencia de usuario.
  • Reduce tiempos de trabajo.
  • Evita incumplimientos legales.
  • Habilita una operación crítica.

El valor debe analizarse con interesados del negocio, no solo desde el equipo técnico.

27.6 Urgencia

La urgencia indica qué tan pronto debe resolverse un requerimiento. No siempre lo más valioso es lo más urgente, y no todo lo urgente es lo más valioso.

Puede haber urgencia por:

  • Fechas legales o contractuales.
  • Inicio de temporada comercial.
  • Problemas operativos graves.
  • Compromisos con clientes.
  • Dependencia de otra iniciativa.
  • Riesgo de seguridad o auditoría.

Distinguir valor y urgencia permite tomar decisiones más equilibradas.

27.7 Riesgo

Algunos requerimientos deben priorizarse porque reducen riesgos. Por ejemplo, una integración técnicamente incierta puede abordarse temprano para comprobar factibilidad.

Tipos de riesgo:

  • Riesgo técnico.
  • Riesgo legal.
  • Riesgo de seguridad.
  • Riesgo operativo.
  • Riesgo de aceptación del usuario.
  • Riesgo de dependencia con proveedores.

Priorizar por riesgo ayuda a descubrir problemas antes de que sea tarde.

27.8 Esfuerzo y costo

El esfuerzo indica cuánto trabajo requiere implementar un requerimiento. Puede depender de complejidad técnica, datos, reglas, integraciones, pruebas, diseño y documentación.

Un requerimiento de alto valor y bajo esfuerzo suele ser buen candidato para una entrega temprana. Uno de bajo valor y alto esfuerzo debería revisarse con cuidado.

El esfuerzo no debe ser el único criterio. Algo costoso puede ser indispensable si cumple una obligación legal o habilita una parte crítica del sistema.

27.9 Dependencias

Las dependencias afectan el orden de implementación.

Ejemplos:

  • No se pueden registrar pedidos si no existen clientes y productos.
  • No se pueden enviar notificaciones si no está configurado el servicio de correo.
  • No se puede generar un reporte si los datos necesarios no se registran antes.
  • No se puede aprobar descuentos si no existen roles y permisos.

Un requerimiento puede ser prioritario no por su valor directo, sino porque habilita otros requerimientos importantes.

27.10 Técnica MoSCoW

MoSCoW es una técnica simple que clasifica requerimientos en cuatro grupos:

Categoría Significado Ejemplo
Must have Debe estar. Sin esto, la entrega no es aceptable. Registrar pedidos con cliente y productos.
Should have Debería estar. Importante, pero puede postergarse si es necesario. Enviar notificación automática al confirmar pedido.
Could have Podría estar. Conveniente, pero no crítico. Permitir personalizar colores del tablero.
Won't have No estará en esta entrega. Aplicación móvil nativa para la primera versión.

La categoría "Won't have" no significa nunca, sino no incluido en el alcance actual.

27.11 Matriz valor-esfuerzo

La matriz valor-esfuerzo compara cuánto valor aporta un requerimiento con el esfuerzo estimado para implementarlo.

Situación Interpretación
Alto valor, bajo esfuerzo Buen candidato para priorizar temprano.
Alto valor, alto esfuerzo Importante, pero requiere planificación y análisis.
Bajo valor, bajo esfuerzo Puede incluirse si no distrae de objetivos principales.
Bajo valor, alto esfuerzo Candidato a descartar o postergar.

27.12 Priorización por versiones

Una forma práctica de priorizar es asignar requerimientos a versiones o incrementos.

Ejemplo:

  • Versión 1: funciones mínimas para operar el proceso principal.
  • Versión 2: automatizaciones y reportes importantes.
  • Versión 3: integraciones avanzadas y mejoras de experiencia.

Esto permite entregar valor temprano y aprender con el uso real del sistema.

27.13 Priorización y alcance mínimo

La priorización ayuda a definir un alcance mínimo viable para una primera entrega. Este alcance debe incluir lo necesario para que el producto aporte valor real, aunque no tenga todas las mejoras deseadas.

Un alcance mínimo no debe confundirse con una versión incompleta o descuidada. Debe ser pequeño, pero útil y aceptable.

Para definirlo conviene preguntar: ¿cuál es el conjunto mínimo de requerimientos que permite resolver el problema principal de manera usable y verificable?

27.14 Participantes en la priorización

La priorización debe involucrar a las personas adecuadas.

  • Patrocinador o responsable de negocio.
  • Usuarios o representantes de usuarios.
  • Product owner o responsable del producto.
  • Equipo técnico.
  • Equipo de pruebas o calidad.
  • Áreas de seguridad, legal o auditoría cuando corresponda.

El negocio aporta valor y urgencia; el equipo técnico aporta esfuerzo, riesgo y dependencias.

27.15 Ejemplo de priorización

Para un sistema de reclamos, podrían priorizarse así:

Requerimiento Prioridad Justificación
Registrar reclamos con cliente, motivo y descripción. Alta Función central del sistema.
Asignar reclamos a responsables. Alta Necesario para seguimiento operativo.
Enviar notificaciones automáticas. Media Aporta valor, pero puede implementarse después del registro básico.
Tablero avanzado con gráficos predictivos. Baja No es necesario para la primera versión.

27.16 Repriorización

La prioridad puede cambiar. Aparecen nuevas restricciones, cambian objetivos, se descubren riesgos o se obtiene retroalimentación de usuarios.

Conviene repriorizar cuando:

  • Cambia el contexto del negocio.
  • Se descubre un riesgo técnico importante.
  • Aparece una obligación legal.
  • Se recibe retroalimentación de una entrega anterior.
  • Un requerimiento resulta más costoso de lo esperado.
  • Una dependencia bloquea el avance.

La repriorización debe comunicarse para evitar expectativas desactualizadas.

27.17 Decisiones y trazabilidad

Las decisiones de prioridad deben registrarse. Esto ayuda a explicar por qué algo fue incluido, postergado o descartado.

Conviene registrar:

  • Prioridad asignada.
  • Criterio usado.
  • Responsables de la decisión.
  • Fecha de decisión.
  • Justificación.
  • Dependencias o riesgos asociados.
  • Versión o entrega prevista.

La trazabilidad evita discusiones basadas solo en memoria.

27.18 Errores frecuentes

Al priorizar requerimientos, suelen aparecer estos errores:

  • Marcar todo como alta prioridad.
  • Priorizar por la persona que habla más fuerte.
  • No considerar esfuerzo ni dependencias.
  • Confundir urgencia con valor.
  • Ignorar riesgos técnicos o legales.
  • No registrar justificación.
  • Priorizar requerimientos ambiguos.
  • No revisar prioridades cuando cambia el contexto.

27.19 Buenas prácticas

Algunas buenas prácticas son:

  • Definir criterios antes de priorizar.
  • Involucrar negocio y equipo técnico.
  • Separar valor, urgencia, esfuerzo y riesgo.
  • Identificar dependencias.
  • No priorizar requerimientos críticos sin refinamiento suficiente.
  • Usar técnicas simples como MoSCoW o valor-esfuerzo cuando aporten claridad.
  • Registrar decisiones y justificación.
  • Revisar prioridades periódicamente.
Priorizar bien no es elegir lo que gusta más, sino decidir qué aporta más valor dentro de las restricciones reales.

27.20 Qué debes recordar de este tema

  • Priorizar permite decidir qué se construye primero y por qué.
  • Los criterios pueden incluir valor, urgencia, riesgo, esfuerzo, dependencias y obligatoriedad.
  • No todo puede ser prioridad alta.
  • MoSCoW y valor-esfuerzo son técnicas simples y útiles.
  • Las dependencias pueden alterar el orden de implementación.
  • La prioridad puede cambiar y debe revisarse.
  • Las decisiones de prioridad deben registrarse con justificación.

27.21 Conclusión

La priorización de requerimientos permite tomar decisiones conscientes en un contexto de recursos limitados. Ayuda a enfocar el proyecto en lo que aporta más valor, reduce riesgos y permite planificar entregas realistas.

Una buena priorización combina mirada de negocio y análisis técnico. También requiere comunicación clara, porque toda prioridad implica postergar o descartar algo.

En el próximo tema estudiaremos negociación de requerimientos y resolución de conflictos, una actividad necesaria cuando los interesados tienen necesidades, prioridades o restricciones incompatibles.