Las listas GTD no son para gestionar proyectos
Hace unos meses, Jerónimo Sánchez habló sobre la gestión de las acciones que forman parte de un proyecto, a raíz de una discusión sobre la herramienta Things:
Según el autor del post, el problema estriba en que Things debería permitir marcar qué tareas pueden llevarse a cabo en parelelo, y cuáles secuencialmente, de modo que las próximas acciones que no se pueden llevar a cabo todavía queden ‘ocultas’ al consultar las listas contextuales correspondientes.
Leer eso fue más que suficiente para entender el verdadero problema del autor: estaba cayendo en un error de concepto muy común entre muchos de los practicantes de GTD —yo también cometí errores parecidos en su momento—, y es creer que nuestras listas de GTD son una herramienta para gestionar proyectos. ¡No lo son!
Jerónimo tiene razón: según la filosofía Getting Things Done, las listas de acciones deben contener sólo las próximas acciones del proyecto, es decir las acciones que no tienen ninguna dependencia a otras acciones y con un compromiso para terminarla lo antes posible.
El autor del artículo sobre Things no ha entendido bien este aspecto de GTD. Pero además ha cometido otro error.
Al leer los argumentos en contra de Things me quedo directamente muy claro cual es la aplicación favorita del autor, porque OmniFocus es la única aplicación que conozco —y he estudiado un gran número de aplicaciones— que permite definir grupos de tareas secuenciales y paralelos. OmniFocus es una de las aplicaciones GTD más populares, aunque también se puede utilizarlo para implementar otros sistemas productivos.
El autor se ha equivocado pensar que todas las funciones de OmniFocus forman parte de la metodología GTD. Se ha dejado guiar por las funciones disponibles en una aplicación y no por los principios del método. Es un error muy habitual y la razón porque todavía hoy recomiendo empezar con GTD en papel.
