Hay una promesa muy específica que David Allen lleva 25 años haciendo, y es la siguiente: si tú metes todo lo que te pesa en la cabeza —pendientes, recados, ideas, miedos chicos, recordatorios sueltos— en un sistema externo confiable, tu mente deja de hacer de bandeja de entrada y vuelve a hacer de cerebro.
Eso es Getting Things Done en una línea. El libro salió en 2001 y la edición revisada de 2015 le cambió los nombres a las fases (la antigua “Collect” se volvió Capture y “Process” se volvió Clarify, lo cual es importante sólo si discutes con alguien que se quedó en la edición vieja). El libro lleva más de dos millones de copias vendidas y traducción a 28 idiomas según la propia empresa de Allen — la cifra de cuatro millones que a veces circula está sin confirmar, así que cuidado al citarla en una junta.
Para muchos de nosotros GTD entró por dos puertas. La primera fue Merlin Mann, que en su blog 43folders.com en 2006 inventó eso de “Inbox Zero” —que no significa “ten cero correos en la bandeja”, significa “no pases tu vida ahí dentro”— y que es básicamente la fase de Capture/Clarify de Allen aplicada al email. La segunda puerta fue la comunidad de Emacs org-mode, que escribió la versión en texto plano más obsesiva del planeta y que sigue siendo lo más cerca que se puede llegar a “GTD para gente que se enoja con las apps que no se pueden scriptear”.
Y luego está el problema, que Cal Newport articuló mejor que nadie en un post brutal de su blog: GTD trata todas las tareas como iguales. Y para alguien que escribe software, no, no son iguales. Responder un correo no es lo mismo que diseñar un módulo de pagos, aunque en tu lista de pendientes se vean idénticos. Pero a esa crítica llegamos más adelante; primero veamos qué propone Allen.
La frase del libro que sí justifica leerlo
Allen tiene una frase que repite en cada charla como si fuera mantra:
“Your mind is for having ideas, not holding them.”
(Tu mente es para tener ideas, no para retenerlas.)
Versión extendida del libro: “Use your mind to think about things, rather than think of them” — usa tu mente para pensar sobre las cosas, no para acordarte de ellas. La diferencia parece chiquita y es enorme. Cuando tu mente está cargando “no se me olvide pagar la luz” + “tengo que revisar el PR de Luis” + “responder a mi mamá” + “ese bug de producción del miércoles”, literalmente no le queda RAM para pensar el problema que sí estás tratando de resolver.
Allen lo dice con una frase que parece publicidad pero es buena:
“There is an inverse relationship between things on your mind and those things getting done.”
(Hay una relación inversa entre las cosas que tienes en la cabeza y las cosas que terminas haciendo.)
La traducción al oficio: cualquier pendiente que vive sólo en tu cabeza es lo que Allen llama un “open loop” — un ciclo abierto, una pestaña del navegador mental que no cerraste. Y van a aparecer en duchas, juntas y a las tres de la mañana, en lugar de cuando podrían ser útiles.
La consecuencia operativa es ridículamente simple: captura todo, en sistemas externos, sin filtrar en el momento. Inbox de email, un inbox.md en Obsidian, el issue tracker, un post-it físico, lo que sea — mientras lo saques de la cabeza. La decisión de qué hacer con cada cosa viene después, en una fase distinta. Esto es Capture, y es la única parte de GTD donde toda la industria —incluyendo a los críticos del libro— está de acuerdo.
Las cinco fases (edición 2015)
Allen separa el trabajo de “lidiar con tus pendientes” en cinco actividades distintas. Suena a obviedad pero es donde la mayoría de la gente se atora: las mezclamos todas en cinco minutos de pánico antes de la reunión de los lunes y luego decimos que “el sistema no funciona”.
| Fase | Qué resuelve realmente |
|---|---|
| Capture (Capturar) | Sacar de la cabeza todo lo que pesa y echarlo a una bandeja externa. Sin pensar. Sin clasificar. Sólo sacarlo. |
| Clarify (Clarificar) | Decidir qué es cada cosa y qué hay que hacer con ella. Esta es la fase difícil. |
| Organize (Organizar) | Poner cada cosa en su lugar: calendario, lista de tareas por contexto, lista de proyectos, archivo de referencia. |
| Reflect (Revisar) | Mirar el sistema diaria y semanalmente para que no se vuelva un cementerio. |
| Engage (Hacer) | El verbo más subestimado de la lista. Elegir qué hacer ahora y hacerlo. |
El nombre nuevo de cada fase tiene una intención: capturar no es procesar, y procesar no es ejecutar. Cuando intentas hacer las tres a la vez, las tres salen mal. Por eso a las 11 de la noche, con prisa, decides que un correo “merece ser un proyecto entero” y al día siguiente no sabes ni por qué lo etiquetaste así.
El árbol de decisión que sí ayuda
La parte más útil de Clarify es un árbol de decisión que cabe en una pantalla. Para cada cosa que entra al inbox, Allen te hace dos preguntas y nada más: ¿es accionable? y, si sí, ¿cuál es el siguiente paso físico, visible?.
La regla de los 2 minutos es una de las pocas cosas del libro que vale verbatim:
“If an action will take less than two minutes, it should be done at the moment it’s defined.”
(Si una acción toma menos de dos minutos, hazla en el momento en que la definiste.)
Aplicada a un programador es brutalmente eficaz para correos, mensajes de Slack y revisiones de código triviales — los lugares donde pensar en hacerlo más tarde cuesta más caro que hacerlo ya.
La regla del “siguiente paso físico, visible” es la que más se rompe en la práctica, y la que más rendimiento tiene. “Pensar en la arquitectura del módulo de pagos” no es un siguiente paso — es una intención disfrazada de tarea. “Abrir Excalidraw y dibujar los tres flujos principales del módulo de pagos” sí lo es. La diferencia entre una lista que se mueve y una que se atasca casi siempre vive en esa frontera.
Conceptos GTD ↔ vocabulario del oficio
Allen escribió el libro pensando en ejecutivos de los 90s, así que su jerga viene de ahí. Aquí está la traducción al lenguaje en el que de hecho hablamos:
| Concepto en GTD | Lo mismo, en lenguaje de programador |
|---|---|
| Open loop (ciclo abierto) | Un TODO sin contexto, un issue olvidado, un PR que lleva tres semanas sin merge |
| Next action (siguiente paso) | Una tarea atómica y concreta — no “diseñar X” sino “abrir editor y escribir el primer esquema de X” |
| Project (proyecto, en sentido GTD: cualquier cosa con más de 1 paso) | Lo que tu equipo llama epic, milestone o feature |
| Weekly review | Una retro contigo mismo, los viernes |
| Tickler file (archivo de recordatorios diferidos) | Cualquier sistema de “recuérdame esto el lunes”: cron, snooze de issues, Google Calendar |
Context list (@phone, @laptop) | Lo mismo pero por estado: @offline, @necesita-prod, @esperando-review, @con-energía |
| Inbox | inbox.md, issues sin etiquetar, TODO.txt, lo que sea — el punto es que sea uno |
| Waiting For (esperando respuesta) | PRs ajenos por revisar, dependencias bloqueadas, “blocked by” |
| Someday/Maybe (algún día) | Backlog congelado, “ideas.md”, la carpeta donde guardas links que jurabas leer |
| Reference (referencia) | Wiki, runbooks (manuales de operación), tus dotfiles |
La traducción más útil para el día a día, créeme, es la de contextos. Allen los pensó como entornos físicos (@phone, @oficina, @laptop), pero para nosotros se modernizan a entornos de estado. Hay tareas que sólo puedes hacer offline en el avión, otras que requieren acceso a producción, otras que estás esperando que alguien revise. Una lista bien etiquetada por contexto convierte cinco minutos muertos en una tarea cerrada — en lugar de scrollear LinkedIn.
Las “horizons of focus” — la parte que casi nadie usa
Allen propone seis altitudes para mirar el trabajo, usando una metáfora aérea que suena genial en un keynote:
| Altitud | Nivel | Qué es |
|---|---|---|
| Nivel del piso (runway) | Acciones de hoy | Lo que estás haciendo en este momento |
| 10,000 ft | Proyectos | Compromisos con más de un paso |
| 20,000 ft | Áreas de responsabilidad | Roles continuos: familia, salud, equipo, el producto X |
| 30,000 ft | Metas | Objetivos a 1–2 años |
| 40,000 ft | Visión | A 3–5 años |
| 50,000+ ft | Propósito y principios | Por qué te levantas, qué valoras |
Diagnóstico honesto: el 90% de la gente que dice usar GTD opera en los dos niveles más bajos —tareas y proyectos— y casi nadie revisa los superiores con la cadencia que Allen pide. Y está bien. Para alguien que programa, la utilidad real del modelo no es contemplarlo religiosamente cada semana, sino preguntarse de vez en cuando una sola cosa: ¿lo que estoy haciendo hoy está alineado con la meta de este año? Si la respuesta es no, alguien decidió mal en algún punto. El modelo sirve para detectar ese desalineamiento, no para meditarlo en una hoja de cálculo.
La revisión semanal: la parte no-negociable y la que más se evade
Si vas a adoptar una sola pieza de GTD, que sea esta. Allen es tajante:
“The weekly review is the one factor upon which your success with this system hinges. Do it, it lives and grows. Don’t do it, it dies.”
(La revisión semanal es el factor del que depende tu éxito con este sistema. Si la haces, vive y crece. Si no la haces, se muere.)
Hay un PDF oficial con el checklist completo, pero la versión condensada para alguien que escribe software es esta, y dura entre 30 y 60 minutos los viernes:
- Vaciar la cabeza otra vez. Lo que se acumuló durante la semana y nunca llegó al inbox.
- Procesar inboxes pendientes. Email, Slack, issues sin etiquetar — todo termina en una de las cubetas del árbol de arriba.
- Repasar la lista de siguientes pasos y matar lo que ya no aplica. Las tareas que llevan tres semanas en la lista normalmente ya no son tareas; son fantasmas.
- Repasar la lista de proyectos. Cada proyecto debe tener al menos un siguiente paso vivo. Si no, está muerto y no te has dado cuenta.
- Revisar “esperando respuesta”. ¿Quién te debe qué? ¿Hay que dar empujón?
- Mirar el calendario de la semana pasada (¿qué cumpliste, qué no?) y de las dos siguientes (¿qué viene?).
- Mirar la lista de “algún día” sin compromiso de mover nada. Sólo recordarse de que existe.
Es la parte del sistema que más se evade — el viernes a las 5 de la tarde quieres cerrar la laptop, no abrirla. Y es justamente la que más rendimiento da. Saltarla una semana te perdona; saltarla dos semanas seguidas y el sistema deja de ser confiable. Cuando deja de ser confiable, tu cabeza vuelve a no soltar las cosas, y todo el experimento se cae.
Las herramientas que la gente usa de verdad
Hay literalmente cientos de apps de productividad. Estas son las que aparecen una y otra vez cuando preguntas a programadores:
| Herramienta | Para quién |
|---|---|
| Emacs org-mode | El favorito de la comunidad hacker. Texto plano, scriptable hasta el delirio, jerárquico. Curva de aprendizaje despiadada. Mobile mediocre. |
| Things 3 (Cultured Code) | Diseño impecable, modelo Áreas/Proyectos/Hoy muy alineado con GTD. Sólo Apple, cerrado, de pago. |
| OmniFocus | El más “ortodoxo GTD” del mercado. Muchísimo poder, también muchísima opción de procrastinar configurándolo. Sólo Apple. |
| Todoist | Multiplataforma, sintaxis de filtros buena, plantillas GTD oficiales. Si no quieres pelear con tu app, esta. |
| Obsidian + plugin Tasks | Markdown plano, multiplataforma, hackeable. Para quien quiere control total y portabilidad. |
| Taskwarrior | Línea de comandos pura, en C++. Atributos custom, dependencias, fórmula de urgencia. Para quien vive en la terminal. |
Texto plano + scripts (todo.txt) | Minimalismo extremo. Portable, se puede grepear, sin dependencias raras. |
Aquí va una verdad que ninguna review honesta dice y todas deberían: la elección de herramienta importa muchísimo menos que la disciplina de capturar y revisar. Cualquiera de estas funciona. Ninguna sustituye el hábito. Si llevas tres meses cambiando de app, el problema no es la app.
La crítica de Cal Newport — la que sí hay que tomar en serio
Newport publicó hace años un post titulado Getting (Unremarkable) Things Done que es la mejor crítica seria a GTD que existe. Tres frases clave del post, traducidas:
“Allen preaches task universalism: when you get down to concrete actions, all work is created equal.”
(Allen predica el universalismo de las tareas: en el momento en que bajas a acciones concretas, todo trabajo es igual.)
“Cranking widgets cannot create results of lasting value.”
(Producir tareítas en serie no puede crear resultados de valor duradero.)
“Deep work cannot be reduced to clear next actions.”
(El trabajo profundo no puede reducirse a ‘siguientes pasos’ bien definidos.)
El diagnóstico de Newport es preciso. GTD optimiza la captura y el flujo, pero no enseña a distinguir “responder a Pepe” de “diseñar el módulo de pagos”. En tu lista de siguientes pasos las dos se ven idénticas: una línea, un checkbox, un verbo. Pero la primera la haces en cinco minutos en cualquier ratito; la segunda necesita tres horas de concentración seria, sin notificaciones, con dos cafés y un cuaderno. Tratarlas como tareas equivalentes es la trampa.
Aquí conviene aclarar lo que Newport entiende por “trabajo profundo” (deep work) versus “trabajo superficial” (shallow work), porque es vocabulario suyo y no es obvio a la primera:
- Trabajo superficial: lo cognitivamente barato. Email, Slack, code review trivial, mover tickets, juntas de status, llenar timesheets. Importante hacerlo, fácil de retomar después de una interrupción.
- Trabajo profundo: lo cognitivamente caro. Diseñar arquitectura, escribir el código difícil de un módulo nuevo, depurar un bug de concurrencia, leer un paper que entiendes a la cuarta. Una interrupción te cuesta media hora de recuperar el contexto.
Newport no descarta GTD — lo usa para el trabajo superficial. Pero argumenta que el trabajo profundo necesita un sistema distinto: bloques de tiempo protegidos, notificaciones apagadas con violencia, métricas de profundidad y no de volumen. Para alguien que escribe código en serio, GTD es la mitad del problema. Deep Work (Newport, 2016) es la otra mitad.
La crítica incómoda de Oliver Burkeman
Four Thousand Weeks (Burkeman, 2021) es una crítica más amplia al productivismo en general, pero le pega a Allen de paso. Su frase central es difícil de tragar:
“Productivity is a trap. Becoming more efficient just makes you more rushed, and trying to clear the decks simply makes them fill up again faster.”
(La productividad es una trampa. Volverte más eficiente sólo te hace andar más apurado, y tratar de despejar la mesa hace que se vuelva a llenar más rápido.)
La premisa implícita de los libros tipo GTD —que podrías hacerlo todo si tuvieras mejor sistema— es, según Burkeman, una mentira muy bien envuelta. Nunca vas a hacer todo lo que está en tu lista. Nunca. Aceptar la finitud (literal: las cuatro mil semanas que dura una vida humana promedio) es el verdadero punto de partida. No es demolición total: Burkeman concede que la idea de “tener un pensamiento sólo una vez” es buena. Pero quita de la mesa la fantasía del backlog vacío como meta legítima.
Para un programador esto se traduce en algo que tu issue tracker ya sabe y nadie quiere admitir: siempre va a tener más de lo que puedes ejecutar. La pregunta correcta no es “¿cómo cerramos todo?” sino “¿cuáles cinco cosas, de las cuarenta posibles, mueven la aguja del producto?”. GTD no responde esa pregunta. Sólo te ayuda a no perder ninguna.
El “GTD purgatory” — la trampa más común
Es la queja recurrente en los foros oficiales de GTD: hay gente que pasa más tiempo manteniendo el sistema que ejecutándolo. Etiquetando contextos. Moviendo cosas entre listas. Optimizando vistas en OmniFocus. Reorganizando el setup de Emacs. Todo lo cual se siente productivo y literalmente no produce nada.
Para alguien cuyo 90% del día es @laptop, el sistema de contextos físicos se vuelve teatro. Tres reglas de seguridad que aplicamos en el lab:
- Si pasas más de 30 min/semana manteniendo el sistema fuera de la revisión semanal, el sistema es el problema. No es que necesites más etiquetas. Necesitas menos.
- Las herramientas que requieren tutorial de YouTube de 45 minutos antes de poder capturar la primera tarea son mala señal. Si no puedes anotar algo en menos de 60 segundos en cualquier dispositivo, no es un sistema confiable — es un hobby.
- No confundas “haber etiquetado el TODO” con “haber hecho el TODO”. El primero te da la sensación del segundo, y es la dopamina más cara del oficio.
Lo que sí adoptamos en el lab
Nuestra versión honesta de GTD para escribir software, después de varios años probándolo:
Capturar siempre, sin filtrar. Cualquier cosa que llega al cerebro va a un inbox externo en menos de 30 segundos. No discutimos esto, no lo posponemos, no lo “guardamos para luego en la cabeza”. Esa es la parte no-negociable.
Revisión semanal sagrada. 45 minutos los viernes. Vaciar inboxes, repasar siguientes pasos y proyectos, mirar calendario de la semana siguiente. Una semana saltada se perdona; dos seguidas y el sistema empieza a oler a leche vieja.
La regla de 2 minutos sólo para trabajo superficial. Email, Slack, code review trivial, decisiones operativas chicas: si toma menos de 2 minutos, ya. Para trabajo profundo la regla no aplica — interrumpir un bloque de concentración para hacer “una cosita rápida” es exactamente lo opuesto a lo que el día necesita. La supuesta “cosita rápida” cuesta media hora de recuperar el hilo.
Contextos por estado, no por lugar. @offline, @necesita-prod, @esperando-review, @profundo, @admin. La pregunta no es dónde estás, es qué tipo de tarea puedes hacer ahora con el cerebro y los accesos que tienes en este momento.
Bloques de trabajo profundo protegidos. GTD no los pide; Deep Work sí. Dos bloques de 90 minutos al día, sin Slack, sin email, con el sistema de captura cerrado pero accesible si aparece un open loop urgente. Cuando termina el bloque, lo capturado va al inbox y se procesa después, en frío.
Una sola lista de proyectos, revisada semanalmente. Cada proyecto debe tener al menos un siguiente paso vivo. Si lleva más de tres semanas sin moverse, o se mata o se manda a “algún día” sin culpa. La culpa es lo que llena las listas de zombies.
Para profundizar
- David Allen, Getting Things Done (Penguin, 2015 ed. revisada). Si vas a leer un libro de productividad en tu vida, este. Los capítulos 2 y 3 son el corazón del libro; los siguientes son repetición con ejemplos.
- Cal Newport, Deep Work (2016). Lectura obligatoria como complemento crítico. Resuelve lo que GTD no resuelve.
- Oliver Burkeman, Four Thousand Weeks (2021). El antídoto contra el productivismo cuando GTD ya te tiene atrapado en el purgatorio.
- Merlin Mann, charla Inbox Zero en Google (2007). El documento canónico de la idea aplicada al email.
- Bernt Hansen, Organize Your Life In Plain Text!. La implementación de referencia de GTD en Emacs org-mode. Sólo si te emociona la palabra “scriptable”.
- Jim Benson & Tonianne DeMaria, Personal Kanban (2011). Buen complemento: GTD decide qué entra al sistema, Kanban personal limita cuántas cosas avanzas a la vez.
TL;DR — GTD funciona muy bien para la mitad superficial de tu día (email, code review, admin, decisiones rápidas) y francamente mal para la mitad profunda (escribir código difícil, diseñar arquitectura, depurar problemas raros). Adopta sin pensarlo: captura externa, regla de 2 minutos para lo superficial, revisión semanal los viernes, una lista de proyectos con siguientes pasos vivos. Ignora sin culpa: el ritual de los seis horizontes, los contextos físicos, la fantasía del inbox vacío como meta. Y léete a Newport — la otra mitad del problema vive ahí.