Dilema: ¿Cómo priorizar aquello que viene “de arriba”?

Tiempo aproximado: 4 min.

Seguro que también te ha pasado alguna vez: alguien que tiene mucha influencia se acerca y te pide que hagas algo, saltándote todas las prioridades, protocolos, políticas y demás acuerdos de trabajo. ¿Cómo actúas ante estas situaciones?

Al final de esta entrada te voy a pedir que hagas una elección, sin embargo, antes me gustaría repasar algunas técnicas de priorización del trabajo.

Lo urgente y lo importante

Las peticiones pueden ser urgentes-e-importantes, urgentes-pero-no-importantes, importantes-pero-no-urgentes o ni-importantes-ni-urgentes. Sobre la primera y última categorías no debería haber dudas, sin embargo, hay mucho conflicto entre las otras dos. Solemos atender antes a algo urgente-pero-no-importante que a algo importante-pero-no-urgente. El sentido común nos dice que deberíamos actuar al revés, pero somos débiles… o no está tan claro todas las veces qué significa importante y ni siquiera qué significa urgente.

MoSCoW

Una de las primeras cosas que aprendí cuando comencé a introducirme en el mundo del agilismo fue este criterio, según el cual cualquier petición puede ser clasificada (priorizada) en las siguientes categorías:

  • MUST (Debe hacerse, “sí o sí”)
  • SHOULD (Debería hacerse: es importante)
  • COULD (Podría hacerse, si hubiera tiempo y/o dinero)
  • WON’T (Olvídalo, no se hará)

En la práctica he observado que este criterio se termina simplificando en HAY QUE HACERLO (YA) y NO HAY QUE HACERLO (AÚN). En cualquier caso, este criterio brilla cuando lo usamos en grupo, por ejemplo en una Agile Inception o alguna otra dinámica en la que participan los diferentes actores implicados en el desarrollo: los que pagan por el desarrollo y los que hacen el desarrollo. Sin embargo, también puede quedar bastante deslucido si lo combinamos con el siguiente criterio.

HiPPO

Highest Paid Person’s Opinion. Está claro, ¿no? Lo más importante será aquello que diga “el que manda”. En un equipo muy inmaduro o de juniors es posible que sea un criterio que funcione, pero no parece muy adecuado para equipos ágiles, en los que promovemos la autonomía en sus decisiones y la colaboración con el cliente.

Clases de servicio

Si empleas el método Kanban para gestionar el flujo de tus tareas, seguro que conoces este concepto.

Anderson y Carmichael, en “Essential Kanban Condensed”, definen las Clases de Servicio como:

“Categories of work items that may warrant different policies for selection and processing based on different customer expectations, relative value, risk, or cost of delay. Four archetypes of class of service are widely recognized: “standard” (the baseline class), “fixed date” (date-driven—the point at which there is a rapid or steep change in CoD), “expedite” (very high urgency), and “intangible” (low current urgency but likely to change significantly at an indeterminate point in the future)”

He dejado la definición en inglés porque no he sido capaz de traducirla respetando la estructura original y que aún se entienda. Beck o Fowler escriben mejor. 🙂

En cualquier caso, creo que podemos simplificar la definición diciendo que una clase de servicio no es más que “un conjunto de reglas acordadas entre los usuarios de un servicio y los que lo ofrecen para ordenar las tareas una vez se ha comprometido el inicio de las mismas”. Igual no haces Kanban pero tienes algún acuerdo de trabajo al que llamas “acuerdo de nivel de servicio” o algo por el estilo. En este artículo sobre cómo gestionar el trabajo no planificable puedes ver algunos ejemplos más.

El objetivo de las clases de servicio es clasificar el trabajo en función de criterios que hagan más predecible el tiempo en el que se acabarán las diferentes unidades de trabajo, de manera que podamos gestionar mejor las expectativas.

Si te interesa que escriba más sobre Kanban, dímelo. Usa los comentarios o cualquiera de los canales para contactar conmigo.

CD3

Hoy va de anagramas. CD3 significa Cost of Delay Divided by Duration.

Don Reinertsen resume los principios de decisión con estas tres simples reglas:

  1. Cuando los costes de retraso son homogéneos, haz primero el trabajo más corto, porque cuanto más corto es el trabajo, más rápidamente podremos liberar el valor que representa.
  2. Cuando las duraciones de los trabajos son homogéneas, haz primero el trabajo con el mayor coste de retraso (incluso si el trabajo es el de menor valor).
  3. Cuando las duraciones de los trabajos y los costes de retraso no son homogéneos, usa el criterio del trabajo más corto ponderado (WSJF). CD3 es un cálculo simple: el coste de retraso dividido por la duración que toma hacer el trabajo.

El dilema

Todos estos criterios (y seguramente otros que puedas añadir tú), salvo el HiPPO, son objetivos (o lo pretenden al menos). Pero qué pasa cuando nos llega una petición que solicita ser tratada con el criterio HiPPO (u otro similar) en contra de nuestros acuerdos de trabajo. ¿Cómo actúas?

¿Cómo actúas cuando llega alguien con una petición de alguien jerárquicamente superior para saltarse los criterios de priorización establecidos?