Publicado en productividad

Productividad: Anota esa tarea, ¡como sea!

Anota todo lo que tengas que hacer. En la bandeja de entrada, en tu agenda, cuaderno, pedazo de papel arrugado o en la mano. Esta es la regla principal; la secundaria es que la anotes bien. Iba a decir que esta regla es fundamental para GTD, pero lo cierto es que vale para cualquier otro sistema de productividad que exista, haya existido o esté por inventar.

A Entrada cuando entre

Lo reafirmo por la siguiente situación muy común. Viene un tal Rodrigueñez con su habitual velocidad de curvatura y te dice que “termina lo del otro día, como quedamos” y tú no estás seguro de que fue lo del otro día ni lo que quedaste, y entonces, mientras estás pensando te viene una llamada. ¿Qué hacer? Pues anotar, aunque parezca estúpido, “terminar lo del otro día, lo que quedé con Rodrigueñez” o incluso “lo de Rodrigueñez”. Vale, no es perfecto, no es para nada perfecto, pero a tu memoria le es mucho más fácil tirar de recuerdos desde una pista tan minúscula, que intentarlo desde la nada.

Si apuntas lo de Rodrigueñez, lo peor que puede pasar es que tengas que preguntarle que a qué se refería. Pero si no lo haces, corres el riesgo que lo de Rodrigueñez se te pase por completo. Es por esto que debes rechazar cualquier tentación de no anotar las cosas hasta tenerlo muy claro. Oye, si lo tienes muy claro, mejor. Pero el momento de anotar las cosas no es el momento de tenerlas claras. Si es así puede que nunca llegues a tenerlo claro, porque puede que se te olviden completamente aplastadas por una pila de otras cosas que tienes o quieres hacer. No, el momento de anotar las cosas es el mismo instante en que llegan. Tendrás que aclararlas tarde o temprano, realizar un plan o simplemente determinar las acciones concretas; pero eso se hará cuando llegue el momento diario de examinar la bandeja de entrada o repasar tus listas; cuando todo lo importante y urgente de hoy esté hecho y no sufras interrupciones. Precisamente anotarlas, aunque sea de forma imperfecta habrá mejorado sus posibilidades de ser aclarada y de hacerlo sin molestar a tus otras actividades. Y es que, si no lo anotas, zumbará en tu mente, como una mosca, “lo de Rodrigueñez”, hasta que, quizás te olvides y seguro te moleste.

Procesa como monje que lleva un hábito

Perdón por el jueguito de palabras; la idea es que junto al hábito de anotar las cosas, debes tener también el hábito de procesarlas (en lenguaje GTD) o de aclarar qué son (en lenguaje normal). La “entrada” no es un lugar para vivir, es un estado transitorio, donde dejas las cosas “esperando” hasta que tengas tiempo de decidir qué hacer con ellas. Eso requiere el hábito de procesarlas, para el que cualquier momento es bueno; pero es mejor reservar también un momento de las primeras horas para dejar la entrada limpia y aclararlo todo. También es bueno asegurarse al final de la jornada no dejar nada sin aclarar. En cualquier caso, y semanalmente, cuando revises tus tareas, siempre deja todo aclarado.

No tengas reparos a anotar las cosas que todavía no entiendas. Si lo puedes aclarar directamente bien, si ya venía claro desde el principio, mejor; pero la vida no se va a parar porque las cosas no sean perfectas. Ni tampoco tu trabajo. Anota ahora y aclara lo anotado cuando puedas. Por que si no…

Tenía que hacer algo, ¿verdad? ¿qué era? bueno, ya me acordaré… supongo.

Publicado en productividad

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.

Publicado en productividad

Herramientas de Productividad Simple 2 – Kanban GTD

¿Kanban o GTD?

Si alguien piensa que un kanban puede sustituir a GTD, o que con mi pequeño artículo puede ignorar a David Allen, pues se siente. Aquí de lo que voy a hablar es de un kanban que estoy usando personalmente para implementar las listas de tareas (acciones en terminología gtd) y proyectos de GTD, dentro del contexto de mi trabajo, nada más. Dicho con estas salvedades, sí un kanban es mi sistema de confianza, que me ha demostrado ser seguro, rápido y eficaz. ¿Quieres verlo?.

Sigue leyendo “Herramientas de Productividad Simple 2 – Kanban GTD”

Publicado en sabiduría

Pequeños actos de sabiduría

Supongamos que un gran problema nazca de una causa pequeña, como un vaso con una pequeña grieta por la quoe pierde toda el agua. En ese caso encontrar y eliminar la pequeña resolverá el problema, como sellar la pequeña grieta recuperará la utilidad del vaso.

## Cadena de kaizen

Os acordaréis de Cadena de Favores. En la película un niño pretende cambiar el mundo a través de pequeños actos de amabilidad, que debían trasmitirse como un virus, consigue cierto éxito y en el proceso transforma las vidas de las personas que más quiere.

Si seguís Sabiavida, os sonará también el concepto de kaizen,del que os he hablado muchas veces aplicado a diversos ámbitos. Se trata de una actitud de mejora constante que utiliza técnicas sencillas, pero bien definidas, de forma que la responsabilidad de la mejora puede distribuirse entre todos, no sólo los expertos y que, por tanto, permite a cualquiera tomarla iniciativa.

Mi idea es combinar estas dos aproximaciones. El concepto del kaizen, que ha triunfado en la empresa, ya ha salido de ese ámbito y no extraña hablar de kaizen personal, o incluso de herramientas lean que se han pasado a la organiación y productividad personal. Debemos ir más allá.

Un evento kaizen puede ser limpiar una ciudad. En el caso de [Alba Iulia](http://www.youtube.com/watch?v=Mktnus9bhPs), Clean Up Japan una ong japonesa promovió los apoyos locales necesarios para una simple actividad de limpieza: una de las estrategias más simples y efectivas del kaizen. En ella participaron los miembros de una asociación de kaizen local, funcionarios y policías. Y no se hacía simplemente por dejar la ciudad más bonita, o porque las estadístIcas muestren que a mayor suciedad mayor número de crímenes sino para cosechar voluntades para el cambio: voluntades kaizen y, ya de paso dar a conocer la técnica.

Sigue leyendo “Pequeños actos de sabiduría”

Publicado en productividad

GTD Test de Velocidad

Es difícil hacer un test de velocidad a una aplicación GTD. Resulta que el tiempo de respuesta de una aplicación depende, en no pequeña parte, de la cantidad de información que tenga acumulado el sistema. En otras palabras hacer una prueba con cinco #proyectos de tres #tareas cada uno no sirve de nada.

Debido a que GTD denomina proyecto a cualquier conjunto de dos o más acciones dirigidas a un fin y limita una acción a una actividad elemental que puede completarse en dos minutos; pronto habremos acumulado cientos de tareas, incluso proyectos.

Ese “pronto” pueden ser un par de meses; tiempo que es poco razonable: ni el desarrollador de GTD puede darte tres meses para probar gratis el producto, ni tú puedes cambiar cada tres meses de sistema.
Por tanto, #usuarios, aprended a desconfiar de toda reseña o #crítica de una herramienta GTD si el comentarista no ha hecho una prueba con, al menos, varias decenas de proyectos.

Por tanto, #desarrolladores, cread tres cuentas de ejemplo con 50, 100, 200 proyectos, cada uno con cinco tareas o así y en diferente grado de finalización. De esta manera podréis probar razonablemente cómo se va a comportar la aplicación y poner límites o precios adecuados a los consumos de cada cual.

Publicado en productividad

El secreto de la productividad

## O por qué la productividad es imprescindible

Productividad es simplemente saber lo que hay que hacer y cómo hacerlo. A veces hay quien lo expresa de esta manera:

Productividad = Conocer que Acciones hay que hacer + Conocer cómo ejecutar las acciones.

Normalmente nos forman para la segunda. Es decir si vas a cualquier escuela de electricistas te enseñan como instalar un enchufe; también te formarán para ser capaz de realizar proyectos tipo; por ejemplo realizar la instalación eléctrica de un edificio. Lo que es más raro que te formen es para lo desconocido. ¿Qué haces si el proyecto que te piden no estaba previsto en tu formación? Que o has buscado recursos por tu cuenta o has perdido el trabajo.

La fórmula anterior olvida que conocer que acciones hay que hacer es más importante que saber como ejecutarlas. Sí, va en serio. Si conoces lo que necesitas hacer para montar un restaurante, ya contratarás al personal que lo puedan llevar a cabo, o aprenderás por tu cuenta.

Sigue leyendo “El secreto de la productividad”