La Trampa de la Prioridad

¿Es la opción múltiple la mejor opción?

Photo by Filip Mroz on Unsplash

La trampa del menú desplegable Priority

Una historia de startup

Sin fallar, tus administradores de Jira tendrán una solución: ¡miren el menú desplegable del campo Priority! (Consejo profesional para desarrolladores empresariales: posiblemente nombrado Priority2 o P-level.)

Curiosamente, el 100 % de las empresas elige entre P1, P2, P3, P4 o Low, Med, High y Critical — aparentemente no hay otras opciones.

Una lista codificada de cuatro opciones. ¿Está bien? Probémosla durante unas semanas…

Dos días después

En un giro de eventos sorprendente para nadie, la organización descubrió una incidencia con una nueva prioridad más alta, necesitando un pequeño hackeo: agregar P0, ¡o Critical Max+!

Tres días más tarde

Nuestro valiente jefe tuvo algunas reuniones y descubrimientos emocionantes en la conferencia!

Alguien descubrió una prioridad aún más alta que P0!

Desde entonces, el equipo ha estado sumergido investigando cómo etiquetar esta nueva Prioridad.

¿-1? No, no. Eso es demasiado confuso (P-1 vs. P1). ¿Qué tal P0.5? ¿No?

En un momento “inspirado”, el equipo inventó una prioridad más alta: ¡el doble cero!
Ahora conocida como la prioridad P00.

Antes del Diluvio

Antes de que alguien se dé cuenta, tu equipo está de alguna manera ahogándose en tickets P00!

¿Y si la prioridad no fuera una opción múltiple?

¿Cómo podríamos representar mejor un concepto humano en constante cambio y fluido como Prioridad?

• En el mundo real, las prioridades cambian y evolucionan constantemente según nueva información, cambios en el mercado y objetivos organizacionales.
• Existe a menudo una compleja interacción entre urgencia, importancia, disponibilidad de recursos y análisis de costo/riesgo que un simple menú desplegable no puede capturar, especialmente con el tiempo. (Envejecimiento de tickets.)
• Diferentes stakeholders pueden tener visiones contradictorias sobre lo que constituye una alta prioridad, lo que hace que un enfoque único no sea adecuado.

Entonces, ¿qué sigue?

Hay varias alternativas dignas de explorar, desde esfuerzos bajos hasta altos:

• Para proporcionar más espacio y flexibilidad, elige un valor inicial “neutro”, digamos 100 o 1,000. Siempre puedes aumentar o disminuir el número.
  • O comienza con cero, donde los números más altos tienen mayor prioridad.
• Implementa un sistema de priorización multidimensional que considere factores como valor comercial, urgencia y esfuerzo requerido. (Crea un puntaje compuesto para facilitar el ordenamiento y filtrado.)
• Adopta un método de priorización dinámico, como la técnica MoSCoW (Deben tener, Deberían tener, Podrían tener, No tendrán), permitiendo una reevaluación periódica. (También consulta el Modelo Kano.)

Resumen

Se le da tanta importancia a la Prioridad a pesar de su rápida tasa de desgaste. Los tickets CRÍTICOS de ayer probablemente no serán los tickets CRÍTICOS del próximo trimestre.

Con el tiempo, los tickets de alta prioridad antiguos se vuelven resistentes a la limpieza y mantenimiento. Después de todo, ¿quién quiere reducir la Prioridad de algo que se declaró esencial? Olvidémonos de borrar esos tickets irrelevantes… (¡Cielos! Piensa en el backlog).

He visto a múltiples empresas confundir Gravedad y Prioridad. La Gravedad describe la urgencia (o sensibilidad al tiempo).

Prioridad ≠ Gravedad. Puede tener sentido definir 3-5 niveles de gravedad (a menudo utilizados para mantener Acuerdos de Nivel de Servicio).

Los niveles de urgencia ayudan a comunicar impacto cero en el cliente hasta una interrupción parcial/completa del servicio.

Una advertencia

Implementar un campo de Prioridad sin límites requiere un poco de planificación y disciplina.

Si estás familiarizado con el desarrollo frontend, es posible que hayas experimentado una guerra de z-index.

Básicamente, z-index permite a los diseñadores establecer cualquier entero positivo para asegurar que sus widgets se muestren “por encima” del contenido con z-index inferior.

Incluso una actualización menor de un componente podría introducir un cambio en el z-index de su <Dialog />—haciéndolo repentinamente invisible. Estas situaciones se vuelven caóticas cuando nuestros componentes de terceros, trabajo en características y contribuciones de otros equipos intentan superarse mutuamente en z-index.

Z-index solía limitarse a ~32,000. Sin embargo, ¡hace poco vi un fragmento con mil millones de z-index: 1000000000!

La inflación debe estar golpeando duro al z-index.

Discusión

• ¿Es este un experimento mental digno de considerar?
• ¿La idea de una Prioridad en constante aumento es aterradora? ¿Genera ansiedad?
• ¿Es inevitable que este enfoque eventualmente exceda los límites de los enteros de 64 bits?
• ¿Pueden otros campos (más allá de Gravedad o Urgencia) aportar algo a esta conversación?
• ¿Cuánta culpa merece Jira? ¿O crédito?

Podríamos gritar a internet: “¿Quién va a limpiar todos estos tickets P00?”

O, puedes ser real con tu lista de tareas pendientes.

• Acepta que el 90% de tus 1,000 tickets nunca se completará. Está bien.
• Archiva tickets que no hayan sido tocados en meses. Cualquier prioridad o urgencia inicial ya no es aplicable. De todas formas, los problemas archivados suelen recuperarse con frecuencia.
• Cuando un problema vuelve, está bien; simplemente aumentó su prioridad.
• Anecdóticamente, he notado cero daño al descartar tickets más antiguos e incompletos.
• Agregar sin fin a una base de datos de tareas pendientes pierde la oportunidad de enfocar a tu equipo y organización en lo que realmente importa. (Las cosas que están por delante de nosotros. Mientras que las listas de tareas inherentemente miran hacia atrás.)
• Una lista de tareas profunda termina pareciéndose a una Sala de Trofeos de Bizzaro, celebrando la mierda que nunca lanzarás.