Comencemos hoy con un ejercicio. Te presento cuatro criterios usados para priorizar el trabajo. Ordénalos del 1 al 4, donde 1 es el que consideras más importante o usarías normalmente y 4, el menos importante.

• Urgencia del cliente / usuario
• Riesgo potencial y Valor para el cliente / usuario
• Valor para el cliente / usuario
• Estabilidad del requerimiento

¿Ya lo tienes? Lo compararemos con mi lista ordenada más adelante. Antes, te compartiré algunas de las cosas que he observado respecto a los criterios para priorizar el trabajo.

El ideal ágil

Scrum, el marco de trabajo ágil más adoptado en el mundo del desarrollo de software, promueve lo que es llamado “ciclo de desarrollo basado en valor”. En este modelo, el equipo siempre estará trabajando en las actividades y funciones que le brinden mayor valor a los stakeholders, en términos de ROI o conveniencia a los usuarios. La mayoría de los equipos que usan Scrum, siguen este criterio para priorizar el trabajo de sus sprints.

Es probable que tú también tienes “Valor para el cliente / usuario” como el número 1 en tu lista.

Este criterio parece una buena idea: permite que los usuarios obtengan (y paguen) por las funciones que les retornan mayor valor. Además, si se construyen soluciones incrementalmente, permite la evolución de los requerimientos e incrementa la posibilidad de entregar el producto correcto. Sin embargo, su enfoque es solamente en funcionalidad: crear funciones de usuario nuevas, lo cual puede abrir la puerta a circunstancias que, si no se atienden, generan problemas graves.

El sistema basado en decibeles

Es probable que “urgencia del cliente” esté entre tus primeros lugares. También hay quienes lo colocan en último lugar, pues todos los requerimientos son marcados como “urgentes”, y cuando todo es urgente, entonces nada lo es.

Una realidad que hemos observado en desarrollos donde hay varios grupos de stakeholders, con prioridades contrapuestas, es que todos consideran que sus requerimientos o peticiones de soporte deben atenderse primero. La priorización, en estas circunstancias, se hace siguiendo la regla “el stakeholder que grita más fuerte”, lo cual no es saludable.

Cuando atendemos primero al que ha gritado con más intensidad, lo que hacemos es apaciguar a un grupo e incrementar el enojo en otros, que seguirán gritando hasta que los escuchemos, pero no estaremos generando valor uniformemente.

El criterio riesgo-valor

En la parte más alta de mi lista ordenada coloqué el criterio Riesgo-Valor. Éste indica que atendemos primero el trabajo que minimiza o elimina los riesgos, seguido del trabajo que genera mayor valor a los usuarios.

El desarrollo de software implica enfrentar algunos riesgos, los cuales son situaciones probables que pueden incidir positiva o negativamente en el resultado. Cuando no los gestionamos correctamente, nos causan problemas graves o perdemos oportunidades.

Si nos enfocamos únicamente en crear funcionalidad (valor), podríamos postergar o no atender riesgos como los siguientes:

• Elegir la arquitectura incorrecta
• Desviarnos de la visión original y construir el producto incorrecto
• El producto no está listo para producción, porque no es técnicamente viable, no hay suficiente soporte técnico o no se entrenó a los usuarios

Un ejemplo muy común es que el equipo ha seleccionado el lenguaje de programación y el framework de desarrollo antes de tener los requerimientos y la visión inicial. En este caso, es muy frecuente que la arquitectura sea incorrecta, pues no atiende los requerimientos no funcionales adecuadamente y la deuda técnica será alta.

Mi lista final es esta:

1. Riesgo-Valor
2. Valor al cliente
3. Estabilidad del requerimiento
4. Urgencia (que tratamos de eliminar en cada proyecto)

¿Tu lista y la mía se parecen? ¿Cuáles son las diferencias? Con esta nueva información, espero ayudarte a establecer criterios de priorizaciónz efectivos en tus equipos.

¡Nos vemos en la siguiente entrega!