32. Priorización de casos de uso

32.1 Introducción

Después de identificar casos de uso, el equipo debe decidir cuáles analizar, construir o entregar primero. Esa decisión se conoce como priorización.

No todos los casos de uso tienen el mismo valor, riesgo, urgencia o esfuerzo. Algunos son esenciales para que el sistema tenga sentido. Otros pueden esperar. Algunos parecen pequeños pero eliminan grandes riesgos técnicos. Otros son deseables, pero no críticos.

Priorizar casos de uso permite planificar entregas, enfocar el análisis y avanzar primero sobre las funcionalidades más importantes.

32.2 Por qué priorizar

La priorización ayuda a responder preguntas prácticas:

• ¿Qué casos de uso deben detallarse primero?
• ¿Qué funcionalidades aportan más valor al negocio?
• ¿Qué riesgos conviene resolver temprano?
• ¿Qué casos dependen de otros?
• ¿Qué puede quedar para una versión posterior?
• ¿Qué debe estar sí o sí en la primera entrega?

Sin priorización, el equipo puede invertir mucho esfuerzo en funcionalidades secundarias mientras quedan pendientes casos críticos.

32.3 Criterios de priorización

Una priorización razonable combina varios criterios. No alcanza con mirar solo el valor de negocio o solo el esfuerzo técnico. También importan riesgo, urgencia, dependencias, frecuencia de uso y aprendizaje esperado.

32.4 Matriz de prioridad

Una matriz simple permite comparar casos de uso según criterios clave. Los casos con alto valor, alta urgencia o alto riesgo suelen requerir atención temprana. El esfuerzo ayuda a decidir el orden y a planificar entregas realistas.

32.5 Valor para el negocio

El valor para el negocio indica cuánto aporta un caso de uso a los objetivos de la organización. Puede estar relacionado con ingresos, reducción de costos, mejora del servicio, cumplimiento legal, eficiencia o satisfacción del usuario.

Por ejemplo, en un sistema de turnos médicos, Solicitar turno tiene alto valor porque permite cumplir el objetivo principal del sistema. Cambiar el color de una preferencia visual puede tener valor menor.

32.6 Valor para el usuario

Un caso de uso también puede priorizarse por el valor que entrega al usuario. Si una funcionalidad resuelve una necesidad frecuente o dolorosa, puede merecer prioridad alta.

Por ejemplo, Cancelar turno puede ser importante para pacientes y para la clínica porque libera disponibilidad y evita ausencias innecesarias.

32.7 Riesgo

El riesgo indica incertidumbre técnica, funcional, legal, operativa o de integración. Un caso de uso riesgoso puede priorizarse temprano para aprender antes y evitar sorpresas al final.

Ejemplos de riesgos:

• Integración con una obra social o pasarela de pago.
• Alta concurrencia al reservar horarios.
• Manejo de datos sensibles.
• Reglas de negocio poco claras.
• Dependencia de servicios externos inestables.

32.8 Urgencia

La urgencia indica cuándo se necesita una funcionalidad. Puede estar determinada por una fecha legal, una campaña, un compromiso con usuarios, una temporada de alta demanda o una necesidad operativa inmediata.

Un caso puede tener valor moderado pero urgencia alta si se necesita para una fecha específica.

32.9 Esfuerzo

El esfuerzo estima cuánto trabajo requiere analizar, diseñar, construir y probar el caso de uso. No debe usarse como único criterio, pero ayuda a ordenar entregas.

A veces conviene entregar primero casos de alto valor y esfuerzo bajo. Otras veces conviene abordar temprano casos de alto riesgo aunque requieran más trabajo.

32.10 Dependencias

Algunos casos de uso dependen de otros. Por ejemplo, Solicitar turno puede depender de que exista Administrar agenda o Configurar horarios de atención.

Ignorar dependencias puede llevar a planificar una funcionalidad antes de tener sus bases. Por eso conviene identificar qué casos habilitan a otros.

32.11 Frecuencia de uso

Una funcionalidad usada muchas veces por día puede merecer más atención que una usada ocasionalmente. La frecuencia influye en prioridad, usabilidad, rendimiento y calidad de pruebas.

En un sistema de turnos, Solicitar turno y Consultar agenda diaria probablemente tengan mayor frecuencia que Generar reporte anual.

32.12 Aprendizaje

Algunos casos de uso permiten aprender sobre el dominio, la tecnología o una integración clave. Priorizarlos temprano puede reducir incertidumbre.

Por ejemplo, si el sistema debe integrarse con una obra social, conviene probar esa integración antes de que el proyecto esté demasiado avanzado.

32.13 Clasificación simple

Una forma sencilla de priorizar es clasificar cada caso de uso como:

• Alta prioridad: necesario para la primera entrega o para reducir riesgo crítico.
• Media prioridad: importante, pero puede esperar una entrega posterior.
• Baja prioridad: útil o deseable, pero no esencial inicialmente.

Esta clasificación puede ser suficiente en proyectos pequeños o medianos.

32.14 Ejemplo aplicado a turnos médicos

Una priorización inicial podría ser:

32.15 Priorización y versiones

La priorización ayuda a definir qué casos de uso entran en cada versión. Una primera versión puede incluir el conjunto mínimo de funcionalidades necesarias para entregar valor.

Ejemplo:

• Versión 1: Administrar agenda, Solicitar turno, Consultar turnos.
• Versión 2: Cancelar turno, Modificar turno, Enviar recordatorio.
• Versión 3: Reportes, estadísticas e integraciones avanzadas.

32.16 Priorización y detalle de documentación

Los casos de uso de alta prioridad suelen necesitar más detalle antes. Pueden requerir especificaciones completamente vestidas, revisión con usuarios, prototipos y pruebas más completas.

Los casos de baja prioridad pueden permanecer en formato breve hasta que se acerque su implementación.

32.17 Cambios de prioridad

La prioridad no es fija para siempre. Puede cambiar si aparecen nuevas reglas, riesgos, fechas, necesidades de usuarios o restricciones técnicas.

Por eso conviene revisar periódicamente la priorización y no tratarla como una decisión definitiva e inmutable.

32.18 Errores frecuentes

Al priorizar casos de uso, suelen aparecer estos errores:

• Priorizar solo por preferencia personal.
• Ignorar riesgos técnicos o de integración.
• Priorizar funcionalidades vistosas pero poco importantes.
• No considerar dependencias entre casos de uso.
• No revisar prioridades cuando cambia el contexto.
• Documentar en detalle casos de baja prioridad antes que casos críticos.
• No acordar criterios de prioridad con el equipo y los interesados.

32.19 Lista de revisión

Antes de cerrar la priorización, conviene revisar:

• ¿Se consideró valor para el negocio?
• ¿Se consideró valor para el usuario?
• ¿Se identificaron riesgos importantes?
• ¿Se analizaron dependencias?
• ¿Se estimó esfuerzo de manera razonable?
• ¿La prioridad ayuda a planificar versiones?
• ¿Los interesados conocen y aceptan los criterios usados?

32.20 Qué debes recordar de este tema

• Priorizar casos de uso permite ordenar análisis, desarrollo y entregas.
• La prioridad debe considerar valor, riesgo, urgencia, esfuerzo y dependencias.
• Los casos críticos suelen requerir más detalle temprano.
• Las prioridades pueden cambiar durante el proyecto.
• Una primera versión debe enfocarse en entregar valor esencial.
• La priorización debe ser visible y acordada.
• No conviene priorizar solo por intuición o preferencia personal.

32.21 Conclusión

La priorización de casos de uso conecta el análisis con la planificación. Permite decidir qué funcionalidades estudiar, construir y probar primero, considerando valor y riesgo.

Una buena priorización ayuda a entregar antes lo más importante y a reducir incertidumbre. En el próximo tema estudiaremos la trazabilidad entre casos de uso, requisitos y pruebas.