Formato para las listas de proyectos

GTD en texto plano

Aquí tenéis una captura de pantalla de mi ordenador que muestra un protocolo esquemático de una de las clases de proyectos que estoy encargado. Por proyecto, siguiendo la metodología de GTD, quiero decir un conjunto ordenado de acciones simples orientado a la consecución de un fin. En este caso da la casualidad que es un expediente para solventar una de las incidencias relativas al personal. No voy a entrar a describirlo porque tiene escaso interés para la inmensa mayoría de la humanidad; en vez de eso vamos a usarlo como ejemplo de formato de lista de proyecto.

La primera línea es un subtítulo etiquetado estilo markdown con ## y contiene el título del proyecto junto con un par de datos esenciales para su identificación. No aparece en el prototipo pero los datos de identificación incluirían un número de expediente; útil para identificarlo.

Tareas por necesidad

Justo debajo, y ordenadas por secuencia de trabajo tenemos las tareas que conlleva la realización del expediente. Tareas, ojo, y no acciones porque sería absurdo tratar de reflejar todas las posibles acciones que conlleva un proyecto relativamente complejo como éste. Tened en cuenta que una acción, conforme a David Allen es cualquier actividad que puede completarse en menos de dos minutos. Notificar una resolución, por decir un caso, puede hacerse tanto por correo electrónico como por email, al centro de trabajo con acto y en presencia del interesado –conforme a diferentes requisitos legales que no nos interesan ahora mismo. Lo que importa es que no siempre puedo definir a priori la modalidad de la notificación que acabaré usando y las incidencias que puedan surgir. Además, incluso en una notificación, digamos de toda la vida, de una sola resolución, el número de acciones a realizar es divertido:

1. Imprimir Resolución y Registro.
2. Cumplimentar oficio de remisión.
3. Imprimir oficio de remisión y copia.
5. Registrar oficio de remisión en salida
6. Ir a la página web de correos.
7. Cumplimentar formulario.
8. Generar listado de notificaciones y etiquetas.
9. Imprimir listado de notificaciones y etiquetas.
10. Ensobrar.
11. Remitir a Subalternos para que lo lleven a la oficina de correos.
12. Archivar copia del oficio de remisión
13. Esperar a que correos devuelva acuse de recibo firmado.
14. Escanear acuse de recibo.
15. Archivar acuse de recibo.

Y eso suponiendo que todo vaya como la seda, no exista incidencia de ninguna clase; etc. Así que lo que hago en el prototipo es incluir las tareas principales y solo haría mención explícita de las acciones en la ejecución; según fuera necesario. Por ejemplo estoy notificando pero sale algo urgente y debo dejar la notificación a la mitad pues anoto la acción que he terminado y la que me disponía a emprender tal que así

* 4B(1) Imprimir oficio de remisión Hecho 2013-03-27
* 4B(2) Terminar notificación PorHacer 2013-03-27

El significado de los números

Tareas secuenciales

Una tarea es secuencial, digo yo, cuando la tarea posterior no puede completarse sin haber terminado la anterior. Por ejemplo no puedo notificar una resolución si no está firmada y no puede firmarse si antes no se ha redactado conforme al formulario, etc. Para indicar este orden secuencial uso números. 1 indica la primera tarea y 99 la última acción prevista.

Tareas paralelas

Defino las tareas paralelas como aquellas que pueden ejecutarse independientemente unas de otras. En estos casos numero esas tareas con letras como en A y B para indicar que no dependen una de la otra. 4A y 4B indican que estas tareas son secuenciales respecto a 1, 2, 3, y 5, etcétera. Es decir no puedo realizar la 4A ó la 4B si antes no he terminado la 1, la 2 y la 3; como tampoco puedo empezar la 5 o la 6 hasta haber terminado las tareas «4».

He descubierto que las tareas paralelas son muy frecuentes en los proyectos creativos. Muchas veces hay cientos de distintas maneras de hacer las cosas. Sin embargo quedan ciertos ámbitos en los que la rigidez de la Ley –nótese la mayúscula–, la norma o la naturaleza del asunto hace que sea necesario seguir un orden prefijado. Con este formato sencillo pretendo poder reflejar de forma concisa las relaciones que hay entre unas y otras. Hasta ahora y para las tareas de oficina y personales me han sido suficientes; no puedo recomendarlos para entornos más complejos sencillamente porque no tengo experiencias de esos entornos.

La columna estado

Estados

Habréis visto a la derecha de la imagen una columna con valores como «PorHacer» y «Esperando». Esta columna, escrita a mano, con el tabulador, informa del estado en que está cada una de las tareas. Tal y como explico en «Productividad para Mentes Inquietas» estos estados pueden ser:

Por Hacer
La tarea todavía no se ha comenzado
Esperando
La tarea está esperando a que otra tarea se complete. Muchas veces son tareas que corresponden a otra persona
Delegado a
La tarea ha sido delegada a otra persona. Sin embargo, por brevedad no anoto esta tarea en la listad de proyectos porque se deduce de la tarea correspondiente que está «Esperando». Por ejemplo si «notificar» está esperando a «Firma del Director» es evidente que la «Firma del Director» corresponde al Director y no intento controlar qué acciones emplea para revisar y firmar la resolución; esa es su responsabilidad. Como tampoco me voy a meter en cómo los subalternos manejan la correspondencia.
Hecho
La tarea se ha completado, pero puede quedar algo Por Hacer o Esperando para terminar el proyecto.
Terminado
El proyecto está completamente terminado

Fechas

Junto a cada estado, anoto la fecha en que la tarea se completó (si está _»Hecho»_) o está esperando. Además _siempre_ anoto la persona por la que la tarea está _esperando_ o a quién ha sido _delegado_. Pero estas anotaciones, no aparecen en el protocolo, así que aquí viene otra pequeña imagen de un proyecto real, pero con datos personales bien escondidos.

Si el proyecto tiene una fecha límite, la escribiría en el título.

Estados intermedios

¿Qué pasa con las tareas en estados intermedios? No existen. O se ha hecho o no se ha hecho. Me explico.

Por brevedad anoto las tareas, no las acciones de un proyecto, como ya expliqué más arriba. Sin embargo, si me quedo a mitad de una tarea anoto las acciones que me quedan por emprender y las acciones más significativas que ya he terminado.

Por ejemplo: Si estoy escribiendo un artículo pero me falta redactar el último párrafo escribiría algo como:

1. Redactar artículo Parráfos 1 al 3, ||| Hecho. 2013-03-25
2. Redactar artículo Párrafo 4 ||| Por Hacer 2013-03-25
3. Revisar ||| Esperando 2.

Esto funciona tanto con tareas homogéneas (las 1 y 2 del ejemplo, que «van» de lo mismo) y las heterogéneas (revisar es distinto de redactar).

¿Preguntas, comentarios?

Y este es el formato que uso para mi lista de proyectos (en terminología GTD) que a mí me gusta llamar Kanban de proyectos porque visualmente queda como un kanban. En mi caso particular lo estoy implementando en [vim](http://www.vim.org/), ese editor de texto que parece tan feo hasta que lo conoces bien y dropbox como herramienta de sincronización en nube. Sin embargo, podría emplearse cualquier otro editor de texto, o incluso un simple cuaderno de papel.

Esto es todo, probadlo y si queréis preguntad algo, soy todo comentarios.

de Miguel de Luis Espinosa