RELOCATE
Cuando nos encontramos ante un INPUT que tiene la enjundia suficiente como para requerir, no sólo más atención, sino también ser ejecutado por nosotros, pasamos a tomar en consideración el factor tiempo. Debemos entonces distinguir entre los que no acarrean prisa y los que sí. Aquellos que no son urgentes podrán ser tratados con más calma al final de la jornada, pero los urgentes deben ser transformados en TAREA de inmediato. Se inicia en este punto el proceso de RELOCATE. En función de si la urgencia que incorporan es inmediata para ya o no inmediata y pueden esperar a ser hechas más tarde seguiremos un procedimiento u otro: NOW o LATER.
La secuencia de preguntas que nos permite dotar de orden y concierto la entrada de INPUTS que impactan en nuestra PDA durante la jornada laboral se representa en cualquiera de estos dos esquemas (arriba o abajo).
De las 6 posibles salidas, 4 van a para a “recipientes” o BOXES (FILEBOX, SIDEBOX, INBOX y OUTBOX) que incorporan un cierto grado de sosiego y calma para ser analizados, mientras que las otras 2 requieren de mayor dinamismo. Son las que van a ser tratadas en el proceso que llamamos RELOCATE.
Es el proceso de encontrar un espacio temporal entre las tareas de la programación diaria para ubicar nuevas tareas que surgen espontáneamente en el transcurso de la jornada laboral como consecuencia de la entrada de inputs, que pueden ser de dos tipos:
Conversión de INPUTS en TAREAS: Procesos de RELOCATE ("reubicación o traslado")
Los dos últimos potenciales destinos de los inputs están relacionados con el proceso de convertirse en tarea al que denominaremos RELOCATE. Nacen de la urgencia y representan la necesidad de hacer hueco a lo nuevo que llega (TNP) y remover el espacio ocupado por las tareas en la jornada laboral (PDA):
- LATER: cuando nos encontremos ante un grado de urgencia no inmediata vamos a querer post-poner la ejecución de una tarea dentro la jornada laboral. No podemos esperar al final de ésta pero tampoco es necesario “ponerse ya”. Activamos el proceso de buscar el momento idóneo para emplazar la tarea que nace (TNP), sabiendo que tendremos que sacrificar alguna otra tarea (PDA) y minimizando el impacto sobre la productividad. Esta falta de inmediatez hace que no peligre la continuidad de la actividad PDA que se está ejecutando cuando aparece el INPUT que se convertirá en TNP, pero en cambio suponemos que alguna PDA se verá afectada. La cuestión es que podemos elegir cuál. Y si se diera el hipotético caso de que no encontráramos una de menor rango para ser sustituida en lo que reste de jornada laboral, podríamos enviar la LATER a “tareas pendientes”.
- NOW: hay inputs que, al convertirse en actividades, piden ser ejecutadas ya, sin demora (urgencia inmediata), pese a no estar programadas. En esos momentos, se plantea la necesidad de elegir entre la actividad que se está llevando a cabo (PDA) y la tarea que nace pidiendo paso. O una o la otra. Por lo tanto, aquí no sólo está en cuestión la continuidad de la actividad PDA en curso sino que tampoco está claro si la TNP va a poderse ejecutar. Y además, no tenemos capacidad de elegir contra quién chocamos. Para saber quién tiene la preferencia por defecto en caso de choque esa para lo que hemos creado la MATRIZ DE PREVALENCIAS, que determinará si “HACER YA” o si “NO HACER” la TNP. La celda en la que confluyan fila TNP que pide paso y columna PDA en curso tendrá la solución al dilema. No obstante, se puede dar el caso excepcional (que luego se verá) de que se abra la posibilidad de “POSPONER” la TNP.