8.1 - Priorizar sus Listas de Tareas

Ahí está usted, en su mesa, enfrentándose a la lista de tareas diarias de hoy. Docenas de elementos. ¿Cómo decide qué hacer primero?

Esta sección trata de priorizar estos elementos. Diferentes situaciones requieren diferentes esquemas. En los capítulos anteriores, utilizamos un esquema muy sencillo: si hay que hacerlo hoy, es una prioridad A; si hay que hacerlo pronto (pero no hoy), es una prioridad B; y todo lo demás es una prioridad C.

“Entonces, ¿qué haces si todos tus elementos son prioridades A?”

Lea este capítulo.

Los administradores de sistemas me dicen con frecuencia que pasan mucho tiempo cada día preocupados por lo que tienen que hacer a continuación. Sé que cuando miro fijamente mi lista de tareas, puedo pasar cinco o más minutos sólo leyendo la lista, obsesionándome con cuál debería ser el siguiente elemento en el que trabajar. Suma todo el tiempo perdido de esa manera, y es mucho tiempo.

Si pierdes tiempo preocupándote por lo que debes hacer a continuación, deja de hacerlo. Toma una decisión sencilla y empieza por la parte superior de la lista y ve bajando, haciendo cada cosa en orden. En el tiempo que podrías dedicar a inquietarte, completarías un par de elementos más pequeños. Además, debido a la forma en que trasladas los elementos que no has podido completar al día siguiente, es habitual que los elementos más antiguos se sitúen en la parte superior de la lista. Terminar estas tareas más antiguas es una buena manera de empezar el día.

Hacer las cosas que tienes que hacer en el orden en que aparecen es una buena manera de evitar la procrastinación. Citando el eslogan de Nike, “Simplemente hazlo”.

Si tu lista es lo suficientemente corta como para que puedas hacer todos los elementos en un solo día, este esquema tiene aún más sentido. Si no importa si una tarea se hace a primera o a última hora del día, ¿a quién le importa en qué orden se realiza?

Esto es muy parecido a la congestión de la red. Si una red está poco cargada es fácil hacer audio, vídeo, telefonía u otros servicios de tiempo crítico. Sin embargo, con una red congestionada, estos servicios funcionan mucho mejor con algún tipo de esquema de priorización sofisticado, o sistema de calidad de servicio (quality of service, QoS). Cuando la carga de la red es ligera, cualquier esquema funcionará. Cuando la carga de la red es pesada, necesitamos algo más estructurado. Cuando nuestra lista de tareas es simple, cualquier esquema de priorización funcionará. Cuando estamos inundados de peticiones, necesitamos algo más sofisticado.

Para ampliar mi analogía un poco más, ¿sabías que la QoS a menudo no consiste en tratar mejor algunos paquetes? En realidad se trata de tratar algunos paquetes peor. Técnicamente, lo que ocurre dentro de un conmutador de QoS es muy interesante. Cuando no hay congestión, funciona igual que un conmutador sin QoS. Los paquetes entran, los paquetes salen. Sin embargo, cuando se produce una congestión, un conmutador sin QoS simplemente deja caer el último paquete que ha llegado. En otras palabras, no queda espacio en el búfer para un nuevo paquete, por lo que lo ignora. Un conmutador con QoS maneja la congestión de forma diferente. Cuando el búfer está lleno, no deja caer el paquete recién llegado, sino que elige un paquete de menor prioridad en el “medio” del búfer para dejarlo caer. En otras palabras, cuando pagas a un ISP por una mejor QoS en cierto tráfico, en realidad estás pagando para que no te dejen caer durante la congestión. Literalmente, estás sobornando al ISP para que deje caer el paquete de otro cuando la red esté congestionada.

La priorización de tareas es similar. Tenemos una cantidad finita de tiempo y recursos. Cuando estamos sobrecargados, tenemos la tendencia a gruñir ante la siguiente nueva petición que recibimos. En realidad, necesitamos una forma de mirar nuestra lista de tareas actual y decidir si hay elementos de menor prioridad que deban ser retrasados o posiblemente abandonados. (Lamentablemente, no podemos aceptar sobornos).

He aquí un pequeño secreto que aprendí de Ralph Loura cuando era mi jefe en los Laboratorios Bell. Si tienes una lista de tareas, hacerlas en cualquier orden lleva (aproximadamente) la misma cantidad de tiempo. Sin embargo, si las haces en un orden que se basa en las expectativas de los clientes, éstos percibirán que trabajas más rápido. La misma cantidad de trabajo para usted, mejor percepción de sus clientes. Muy bonito, ¿no?

¿Cuáles son las expectativas de sus clientes? Seguro que a todos los clientes les gustaría que todas las solicitudes se completaran inmediatamente, pero, en realidad, tienen cierto concepto de que las cosas llevan su tiempo. Puede que sea una expectativa poco realista, y ciertamente a menudo se basa en un malentendido de la tecnología, pero podemos situar las expectativas de los usuarios en unas cuantas categorías generales:

• Algunas solicitudes deberían ser rápidas. Algunos ejemplos son el restablecimiento de una contraseña, las solicitudes de asignación de una dirección IP y la eliminación de un archivo protegido. Una cosa que tienen en común estas peticiones es que suelen ser tareas menores que retrasan una tarea mayor. Imagine la frustración que experimenta un usuario cuando no puede hacer nada hasta que se restablece una contraseña, pero usted tarda horas en hacerlo.

• Las tareas “hurry up and wait” comenzarán pronto. Se espera que las tareas que son precursoras de otras se realicen pronto. Por ejemplo, pedir un pequeño artículo de hardware suele implicar mucho trabajo para impulsar el pedido a través de compras, y luego una larga espera para que llegue. Después, se puede instalar el artículo. Si la espera va a ser de dos semanas, se espera que el pedido se haga rápidamente para que la espera de dos semanas no se alargue a tres.

• Algunos pedidos llevan mucho tiempo. Algunos ejemplos son la instalación de un nuevo PC, la creación de un servicio desde cero o cualquier cosa que requiera un proceso de compra. Aunque el proveedor ofrezca el envío de un día para otro, la gente acepta que de un día para otro no está bien ahora.

• Todo el resto del trabajo se detiene para solucionar una interrupción. La última categoría son las interrupciones. No sólo se espera que durante una interrupción se detenga todo el trabajo para poder resolver el problema, sino que también se espera que todo el equipo trabaje en el proyecto. Los clientes no suelen saber que existe una división del trabajo dentro de un equipo de SA.

Ahora que entiende mejor las expectativas de sus clientes, ¿cómo puede poner esto en práctica? Supongamos que tiene las tareas de la Figura 8-1 en su lista de tareas.

Figura 8-1. Tareas que no están priorizadas por las expectativas del cliente

Si hiciste las tareas en el orden indicado, podrías estar bastante satisfecho con tu rendimiento. Hiciste todo el día que se te pidió 6.5 horas de trabajo sólido (más una hora para comer). Bien por ti.

Sin embargo, no has hecho un buen trabajo a la hora de cumplir con la percepción de tu cliente sobre el tiempo que deberían haber tardado las cosas. La persona que hizo la solicitud T7 tuvo que esperar todo el día por algo que percibió que debía tardar dos minutos. Si yo fuera ese cliente, estaría bastante molesto. Por falta de una dirección IP, la instalación de un nuevo equipo de laboratorio se retrasó todo el día.

(En realidad, lo más probable es que el cliente frustrado e impaciente no espere todo el día. Hará ping a las direcciones IP hasta encontrar una que no esté en uso en ese momento y tomará prestada temporalmente esa dirección. Si ese es tu día de mala suerte, la dirección seleccionada entrará en conflicto con algo y provocará un apagón, que podría arruinar todo tu día. Pero no me enrollo: ….)

Reordenemos las tareas en función de la percepción del cliente sobre el tiempo que deberían llevar las cosas. Las tareas que se perciben como poco tiempo se agruparán y se harán al principio del día. Las demás tareas se harán más tarde. Sin embargo, se hará una excepción a la regla, como pronto se verá. La Figura 8-2 muestra las tareas reordenadas.

Figura 8-2. Tareas ordenadas en función de las expectativas del cliente

Empiezas el día realizando las dos tareas (T1 y T7) que los clientes esperan que se realicen rápidamente y que, con toda seguridad, retrasarán otros proyectos de mayor envergadura. Consigues cumplir con la cantidad de tiempo percibida de estas tareas.

La siguiente tarea (T5) implica una situación de “prisa y espera”. No importa lo rápido que pidas el artículo, va a tardar uno o dos días en llegar. Hacer el pedido lo antes posible puede evitar muchas insatisfacciones en el otro extremo.

Tu siguiente tarea (T4) se hace en 30 minutos. Compruébalo.

La tarea T2 no lleva mucho tiempo, pero la expectativa de creación de una nueva cuenta de usuario no suele medirse en minutos y horas, sino en plazos. Si el primer día de trabajo de la persona es mañana, se espera que sus cuentas estén creadas antes de que llegue, tanto si se tarda un minuto como si se tarda un día, tanto si se hace a primera como a última hora del día. Sin embargo, dado que la tarea está sujeta a un plazo, es importante que se realice.

Si se produjera una interrupción (causada, posiblemente, por dos hosts configurados para la misma dirección IP), y todo el trabajo se detuviera para arreglar una interrupción, el calendario previamente trazado se vería interrumpido. Sin embargo, seguiría trabajando para cumplir con la expectativa de que la nueva cuenta se creara antes de que llegara la persona. Otras tareas podrían retrasarse un día, lo cual es comprensible dado el gran apagón. Pero para una tarea como la creación de una cuenta, me quedaría hasta tarde antes que perder el plazo.

Instalar un nuevo servidor (T3) es una de esas “tareas de agujero negro”. Debería tardar unos minutos en montar el servidor en el rack, quizá una hora en cargar el sistema operativo, un poco más en configurar el sistema. Al menos los vendedores parecen pensar que eso es cierto. Los administradores de sistemas sabemos que nunca es tan fácil. La primera vez que montas en rack ese producto en particular, siempre te lleva horas entender el extraño sistema de montaje que ha creado el vendedor. Los sistemas operativos de los servidores a menudo se cargan, se borran, se cargan y se borran, mientras ajustas cuidadosamente la configuración cada vez para que las cosas queden bien. (Esta caja va a estar durante años, así que más vale invertir algo de tiempo en hacer las cosas bien). Por último, la configuración nunca va tan rápido como esperamos. Por lo tanto, dejamos estas tareas de agujero negro hasta después de haber completado las tareas que se espera que ocurran rápidamente.

Doblamos las reglas de priorización para la última tarea (T6). Teniendo en cuenta el tiempo previsto para su realización, se podría pensar que la habría hecho antes, quizás antes o después de la T3. Sin embargo, en todos los sitios en los que he trabajado, Usenet NetNews se considera una actividad recreativa de baja prioridad que se ofrece como una bonificación a los empleados. (Nunca he trabajado en un ISP, donde la situación puede ser diferente.) Por lo tanto, arreglar un problema menor con él es una prioridad baja y va al final de la lista. La regla general es: cuando todas las partes están de acuerdo en que una tarea es de baja prioridad (o hay un edicto de la dirección), se mueve la tarea al final de la lista. Piénsalo así: si alguien se queja de que una de las otras tareas no se ha completado, ¿querrías ponerte delante de tu jefe y explicarle que la petición del cliente se ha retrasado porque estabas arreglando un problema menor con Usenet? No, en absoluto.

¿Simple? Claro. Puede llevar un poco de práctica, pero sus clientes notarán la diferencia.

Cuando explico este sistema a la gente, la principal objeción que escucho es que su lista de tareas no es estática. No empiezan el día con una lista fija de cosas que hay que hacer. A lo largo del día se añaden nuevos elementos a la lista.

Por eso utilizamos la técnica de delegar, registrar y hacer del capítulo 2 para hacer frente a las interrupciones. Podemos utilizar las expectativas de nuestros clientes para influir en cuál de estas tres acciones realizamos.

Una solicitud para restablecer una contraseña debe realizarse rápidamente porque está retrasando otro trabajo. Por lo tanto, puede ser más rápido hacerlo que delegarlo en otra persona. Y, desde luego, no hay que registrar la tarea para más tarde cuando supone retrasar toda la agenda de una persona.

Esta técnica no sólo funciona para priorizar tu lista personal de tareas, sino que puedes utilizarla para planificar a mayor escala. Utilízala para organizar todo tu departamento de soporte informático.

¿Recuerdas la técnica del escudo de interrupción mutua del capítulo 1? Básicamente, implementas este sistema para asegurarte de que las expectativas de las personas coinciden. Tu compañero de trabajo atrapa todas las interrupciones durante la mitad del día para que tú puedas realizar los proyectos, y tú inviertes los papeles durante la otra mitad del día. Lo que realmente estás haciendo es asegurarte de que haya alguien que haga las tareas que los clientes esperan que se realicen rápidamente.

La mayoría de los servicios de asistencia tienen miembros de nivel 1 que responden al teléfono y sólo remiten un problema al personal de nivel 2 cuando están perplejos. Esto es, esencialmente, la creación de un escudo de interrupción mutua para todo el equipo, mientras que proporciona tiempos de respuesta que coinciden con las expectativas del cliente.

La priorización basada en las expectativas de los clientes y el uso del escudo de interrupción mutua reproducen el sistema de niveles del servicio de asistencia, lo que valida la combinación. O bien, se podría decir que la estructura de niveles se valida por el hecho de que pretende alcanzar el objetivo de satisfacer las expectativas del cliente. En cualquier caso, muy interesante, ¿no?

Volver al índice