En este capítulo 74 os hablo de la solución a un problema del cliente de OneDrive para Mac y ciertos detalles de configuración del almacenamiento caché compartido de macOS. En la sección de productividad seguiré hablando de la nueva definición de mi sistema GTD, tocándole el turno a la lista de siguientes tareas y a la configuración de proyectos. Para terminar, en la sección de podcasting veremos como mi plan para recuperar el control TOTAL de los feeds de mis podcasts ha encontrado varias dificultades (no olvidéis comprar el libro al respecto de Allan Tépper).
Weekly: (Protected Content)
Saludos, Emilio. Aquí está el «pesao» otra vez. Pero es que creo que lo que has hablado hoy es NUCLEAR y hay algunas indicaciones que señala la David Allen Company que me generan muchas cuestiones. Además, no me ha quedado claro si señalas que haya que identificar (poner etiqueta de contexto) a una sola acción por proyecto. Espero no soltar otro ladrillo… aunque me resulta difícil explicarlo brevemente. Lo intentaré:
Estoy totalmente de acuerdo contigo en que GTD viene finalmente a ser una metodología que facilita una continua toma de decisiones respecto a qué es lo más adecuado hacer en cada momento. Y que no será hasta ese «cada momento», en el que, con los elementos contextuales y las circunstancias específicas que concurran, cuando uno deberá (y podrá) tomar la mejor decisión en cada caso. Sobre todo porque quizá esos elementos del contexto o de las circunstancias no estaban presentes cuando uno incorporó la tarea al sistema o cuando se hizo la última revisión de este… y puede que después esas circunstancias sean totalmente distintas.
Por eso, no termino de entender bien el sentido de «próxima acción» en la metodología GTD. Concepto que creo que puede confundirse a veces con el de tarea «accionable» o disponible.
Quiero decir con esto: en mi opinión, para un proyecto determinado, deberían ser accionables (y visibles en las listas del contexto que correspondan) todas aquellas tareas que estén disponibles en un momento determinado, con independencia del número de las mismas y del contexto que requieran. No solamente una única próxima acción.
En proyectos sencillos no hay problemas. Pero en un proyecto complejo, podríamos encontrarnos en un momento determinado que existe un número x de tareas que están disponibles en ese momento, esto es, que pueden hacerse (y que cumplen los otros requisitos para que una tarea esté disponible: deba hacerse antes de la próxima revisión del sistema o tenga fecha de finalización, etc…). Incluso esas tareas podrían compartir contexto y/o repartirse entre contextos diferentes.
Si sólo asignáramos la etiqueta de contexto a una acción (esto es, si sólo identificáramos una primera acción en un proyecto), podría suceder que:
a. Estamos, en el momento de la revisión, en el que asignamos la etiqueta de contexto, de una forma u otra, decidiendo cuál será la próxima acción, algo que contradice la regla fundamental relativa a poder tomar, en cada momento, la decisión más adecuada.Puede que en ese mismo proyecto existan otras tareas, también accionables, que deberían aparecer, para poder así sopesar cuál es, en cada momento, la más adecuada para su abordaje. Si sólo aparece una, en la lista del contexto correspondiente, no podremos tomar la mejor decisión.
b. Por otra parte, si sólo asignamos etiqueta de contexto a una tarea identificándola como próxima acción, podría suceder que tuviéramos también otras tareas accionables que corresponden a otros contextos y que no se han activado, ya que no les hemos asignado etiqueta. Esto se podría solucionar tratando de «accionar» al menos una tarea por contexto en cada proyecto. Pero sería un trabajo… extraño, ya que tendríamos que ir evaluando los contextos de distintas tareas realmente disponibles para, finalmente, no identificar dichos contextos en cada una de ellas, sino sólo en aquella que señalemos como próxima acción, etiquetándola.
Por otra parte, si bien es cierto que las revisiones son fundamentales y, por supuesto, la semanal es casi una obligación sagrada, con esta fórmula que propone la DA Company, podría suceder que un proyecto se quedara «parado», disponiendo el mismo de tareas «accionables» sólo porque no hemos activado ninguna otra tarea. Incluso, llevado a un extremo, el sistema podría forzarnos a realizar una única tarea por proyecto entre revisión y revisión cuando quizá, el ritmo de trabajo podría ser superior.
No sé si me he explicado bien. Son las grandes dudas que desde siempre me genera el sistema GTD. Probablemente porque hay cuestiones elementales (matices, pero importantes) que nunca he llegado a entender del todo. ¡Ah! Y estas dudas están ahí si tratamos de dar al concepto «accionable» o «disponible» un sentido más bien coloquial (algo que se puede hacer). Si introducimos el sentido estricto de accionable que antes señalaba (existe un compromiso de realizar la tarea antes de la próxima revisión semanal del sistema o se derivará una consecuencia indeseable si no se realiza antes de dicha división, etc…) todo se complica aún más. O quizá no… y por eso no termina de funcionarme.
En fin, que esto del GTD es complejo. Aunque al menos puedo decir que es apasionante pensar, estudiar y debatir sobre él.
Un saludo. Buen episodio el de hoy.
Buenas: con WatchOS 6 siguen sin descargarse en la app Podcast del reloj los podcast de Weekly (imagino que sigue el problema con los que son de pago)
Un saludo y gracias
Repasando tu comentario y el audio veo que quizá no me he expresado bien: debemos poner contexto sólo a las tareas que sean accionables pero en ningún momento se nos dice que sólo una pueda serlo. De hecho, en el PDF dicen que el problema de los proyectos secuenciales de OmniFocus es que parten de un planteamiento demasiado sencillo e ideal, donde hago una cosa detrás de la otra como si fuera una receta de un bizcocho. Actualmente, y siguiendo la lógica de este procedimiento, tengo proyectos con dos y hasta tres tareas accionables, cosa que me parece muy natural y muy acorde a la naturaleza compleja de dichos proyectos.