GTD® guarda similitudes formales muy claras con el sistema Waterfall, por lo que se adapta de maravilla a entornos simples donde se pueden aprovechar las sinergias de la producción en cadena. Ello conlleva una visión del tiempo lineal: detrás de una acción, hacemos la siguiente sin mezclar fases, para centrarse en lo que estamos. El problema viene cuando se pretende utilizar GTD® en entornos complejos o caóticos, donde la previsibilidad de lo que va a ocurrir es muy baja.
CONCEPCIÓN CÍCLICA (Agile) VS. LINEAL (Waterfall)
CICLOS CORTOS ITERATIVOS VS. FASES LINEAS CORRELATIVAS
La metodología ágil SCRUM considera que, para ejecutar proyectos, el tiempo debe verse como una sucesión de ciclos temporales de duración fija, llamados “sprint”, que no son más que iteraciones muy cortas -entre una y cuatro semanas-, en cada una de las cuales se crea un incremento de producto terminado, utilizable y potencialmente desplegable. Dentro de cada sprint, además, se lleva a cabo un Scrum diario, que no es más que una pequeña reunión de 15 minutos donde se establece el contexto para el día de trabajo.
Por su parte, según GTD®, las fases en las que se materializa el proceso de control son primero capturar, luego aclarar, después organizar, a continuación revisar y, por último, hacer. Estas fases se han de abordar secuencialmente, por separado. Se tiene, pues, una visión lineal del tiempo. No se han de mezclar unas con otras. Es decir, que si estás organizando, no revisas; si estás capturando, no aclaras; si estás aclarando, no organizas, etc. Luego, sin embargo, se rompe este criterio general y se crean un par de excepciones cuando se nos habla de la regla de los dos minutos (hacer en la fase de aclarar) o de delegar (organizar en la fase de aclarar).
DIFICULTADES DE IMPLEMENTACIÓN
Pero esto no es más que un problema de falta de coherencia teórica del modelo. El verdadero problema es más mundano y solo lo percibes cuando lo sufres. Y esto ocurre cuando estás intentando implementar este método.
Por una parte, la dificultad número uno que hay que señalar, es que es un auténtico fastidio disponer, no de una sino de multitud de bandejas de entrada: una en la oficina, otra en casa, otra en el coche, otra en el correo electrónico,… no menos de diez según Bolívar. Cuando decido procesar ¿cuál de todas las bandejas de entrada proceso?, ¿debo repetir varias veces el proceso según donde me encuentre?, ¿todas a la vez? El tema es en qué momento y con qué frecuencia.
Por otra, la que podríamos llamar dificultad número dos, es que no hay que olvidar que, en la práctica, mientras estamos procesando, organizando, revisando o haciendo, hay nuevos input que, de forma espontánea, van haciendo su aparición. ¿Qué hacen?, ¿esperar a la mañana siguiente en la bandeja de entrada? ¿y si hay algo que no puede esperar porque requiere atención inmediata?
Vamos a ilustrar con dos ejemplos la problemática que se genera como consecuencia de llevar a la práctica los preceptos del método de David Allen. Si, buscando el modo de solucionar este problema, llegamos a la conclusión de que lo mejor es aumentar la frecuencia, igual nos sorprenden las conclusiones que se derivan de ahí.
EJEMPLO 1: AMBULATORIO / URGENCIAS
Pensemos por un momento en un hipotético CENTRO DE SALUD o AMBULATORIO. Un espacio en el que poder crear un paralelismo funcional con el método GTD®. Digamos que podemos considerarlo un entorno simple y previsible. La gente que acude allí, lo hace por su propio pie, por lo que no presenta dolencias muy graves. Disponen de una sala de espera bien grande (bandeja de entrada) a la que se derivan todas las personas (input) que entran en el recinto (proceso). Esto se corresponde con la fase de recopilar o capturar. Huelga decir que, si en lugar de disponer de una sala de espera, tuviéramos diez, el problema que se describe a continuación se complicaría sobremanera. Pero vamos a simplificar el ejemplo, obviando por un momento la dificultad número uno, para centrarnos en la número dos. Una vez quede expuesto, ya podemos incorporar a la ecuación esa variable y reflexionar. Pues bien, considerando una única bandeja de entrada y asumiendo el rol de gestor que aplica GTD®, actuarías del siguiente modo: llegado un momento, por ejemplo a las 9 h, te diriges a la sala de espera, los pones a todos en fila india y empiezas a procesar o aclarar (tú tienes esto, tú lo otro...) pero les vas a tener que decir que deben esperar todos allí (excepto a uno que solo requería una atención primaria mínima -regla de los dos minutos- y otro que derivas a un laboratorio de análisis para unas pruebas de diagnóstico -delegar-) hasta que vuelvas en otro momento para organizarlos. No a continuación porque no se han de mezclar las fases. El caso es que vuelves a las 11 h y empiezas a organizar o clasificar a cada uno de los pacientes que quedan a un destino (tú aquí, tú allá,...). Más adelante, a las 13 h, te pones a revisar los destinos asignados para ver si están todos los pacientes bien ubicados y que no les falte nada. A algunos se les habrá dado cita y otros quedarán a la espera de que se los pueda atender cuanto antes. La pregunta es ¿Qué haces con los nuevos input que, desde las 9 h hasta las 13 h, han ido ocupando la bandeja de entrada (nuevas personas en la sala de espera)? ¿Pasarán la noche allí esperando que alguien vaya a por ellos para tratarlos como merecen? ¿No sería más lógico aumentar la frecuencia de ejecución del proceso? ¿Mejor dos veces al día que una? ¿O quizá mejor cuatro que dos? Parece evidenciarse que, cuanto mayor sea la frecuencia, menores tiempos de espera. ¿Y si los ciclos fueran tan pequeños y frecuentes que pudiéramos atender a cada input conforme entrara, diagnosticarlo y derivarlo a un destino? El problema es que los puristas de GTD® lo verían casi como un desacato, un sacrilegio, pues sería como juntar las fases del proceso y hacer una mezcla que no aprueban. Como diría Bolívar en su libro "Productividad personal": “Si estás montando ruedas, monta ruedas”, que hay que aprovechar las sinergias de la producción en cadena. ¿Dónde sería posible encontrarnos esos menores tiempos de espera y esa inmediatez en la atención, esos ciclos cortos e iterativos (ese juntar en una las tres fases de capturar-procesar-organizar)? Esto es lo que ocurriría en una SALA DE URGENCIAS de un hospital, un entorno más caótico y menos previsible. Pero si atendemos a lo expuesto en el apartado anterior, ese entorno ya no es el idóneo para GTD®.
EJEMPLO 2: COMEDOR SOCIAL / RESTAURANTE
Ahora pensemos en un COMEDOR SOCIAL con dos turnos. Las personas irían llegando y serían alojadas en un hall hasta que les diera acceso al recinto y permiso para sentarse. Sirva para este ejemplo la misma reflexión que para el ejemplo anterior en cuanto a que, si en lugar de un hall, tuviéramos a la gente esperando en diez espacios distintos. El caso es que, cuando llegara la hora del inicio del turno, se les iría a buscar a todos para aposentarles y se pondría en marcha el servicio. Se les serviría la comida preparada para ese día, guardando los tiempos de espera correspondientes entre plato y plato. Lo que corresponda al menú diario, y punto. Ahora toca el primero, servimos a todos el primero. Finalizado el primero, retiramos los platos de todos los comensales. Con el segundo, lo mismo y, por último, acabamos con el postre. Y cuando estamos en el postre, estamos en el postre (“monta ruedas”). Los que accediesen al recinto tarde, ya tendrían que esperar al siguiente turno en el mejor de los casos. Si no, hasta el día siguiente, nada. En cualquier otro RESTAURANTE, con un cierto nivel de calidad, las cosas serían de otro modo. Cada cliente que entrara sería recepcionado de inmediato y ubicado como mandan los cánones. A cada uno se le tomaría nota y se le serviría con arreglo a sus gustos y necesidades con los tiempos de espera mínimos e imprescindibles. El servicio se adaptaría por completo al cliente y de eso dependería su grado de satisfacción final. Aquí ya no habría necesidad de sala de espera y cada input que entrase en el sistema recibiría el tratamiento adecuado. Mientras unos están siendo recepcionados, otros están en el entrante, otros en el postre y otros pagando. Cada elemento del sistema lleva su ritmo y el sistema está preparado para atenderlos al unísono pero no en fases lineales a todos de golpe, sino adaptándose a los pequeños ciclos individuales de cada cual.
CONCLUSIÓN
La conclusión a la que llegamos enlaza lo tratado en el capítulo anterior con lo que se aborda en este: GTD® guarda similitudes formales muy claras con el sistema Waterfall, por lo que se adapta de maravilla a entornos simples donde se pueden aprovechar las sinergias de la producción en cadena. Ello conlleva una visión del tiempo lineal: detrás de una acción, hacemos la siguiente sin mezclar fases para centrarse en lo que estamos. No te puedes saltar ninguna fase ni se permite priorizar un input en relación con otro en ningún momento porque tienes que tener la confianza en mi sistema y saber que, cuando te pones, te pones y aclaras todo hasta vaciar la bandeja de entrada.
Vuelvo a recalcar la idea de que esto no es bueno ni malo por sí mismo: para cada entorno, tenemos un sistema que se adapta mejor. El único problema aparece cuando se pretende utilizar GTD® en entornos complejos o caóticos, donde la previsibilidad de lo que va a ocurrir es muy baja. En una sala de urgencias de un hospital o en un restaurante de cierto nivel, en ámbitos con un grado de exigencia de calidad alta, necesitamos unos requerimientos de organización del tiempo para los cuales GTD®, por su rigidez y su falta de flexibilidad, no es todo lo ágil que tendría que ser.
