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 productividad

Lean Personal

Crisis

Hace un mes, facilethings, la aplicación GTD que uso, falló; había acumulado demasiados proyectos para la base de datos y de lenta, se hizo inútil.


No nos pongamos trágicos. La mayoría de la gente vive sin GTD. No me iba a pasar nada a mí por un día… pero pasó una semana. Al final sobrevivía base de evernote hasta que el soporte de facilethings consiguió una nueva base de datos.

Redefiniendo GTD

Esta crisis me abrió los ojos. Resultar que la productividad es algo más que GTD y que, gulps, GTD no es ni un sistema de productividad personal ni el éxito final de la evolución de las productividad personal.

Lo que es GTD

GTD
una aproximación sistemática a la organización de la información sobre las tareas personales.

Vale esa es la definición aburrida a la que he llegado.

Me explico:

  1. aproximación sistemática: esto viene del propio David Allen, que en “Making it all work” entiende que no ha alcanzado un sistema completo, sino que da las piezas necesarias para que cada cual cree su sistema, desarollándolas más o menos de acuerdo a sus necesidades.

  2. organización de la información: GTD va de organizar información; nada más. Responde así a las dificultades específicas de los llamados trabajadores del conocimiento y de otros ámbitos en los que el trabajo está poco definido.

Esto está bien, pero es insuficiente.

Entra Lean

…puedes estar pensando que la naturaleza creativa de tu trabajo, y su variabilidad, significa que no puedes estandárizar nada –al contrario. Piensa, por ejemplo, en un artista –el epítome de la creatividad, hasta la boina calada con garbo. Pero si te fijas en su paleta, notarás algo intereante: los colores no está dispuestos aleatoriamente. En realidad, siempre están en el mismo lugar para que sea más fácil y más rápido encontrar el color adecuado cuando se necesita. En otras palabras, parte del trabajo estándar de un artista es mezclar los colores en el lugar justo de la paleta. Esta estándarización es importante porque si estás tumbado pintando el techo de la Capilla Sixtina, lo último que quieres es tener que ir cazando continuamente al color amarillo. –Daniel Markovitz, “A factory of One”

En otras palabras: hasta un artista tiene trabajo estandarizable y esta estandarización es importante. Pongamos que llamas o recibes llamadas por teléfono: éstas son estandarizables. Mandas y recibes emails: pueden someterse a un estándar.

Por importante que sea tu trabajo este seguramente contiene procesos humildes pero importantes, que si conseguimos estandarizar nos harán trabajar mejor y, descargarán nuestro sistema GTD.

La respuesta no son más recursos

Una mejor base de datos me sacó del lío. Pero me quedó claro que no puedo seguir acumulando información de acciones y proyectos sin límite. Los más de cien proyectos, muchos con listas de acciones largas, que llevaba se hacían inmanejables incluso con una aplicación informática, incluso con la que es la mejor implementación de GTD que conozco. Sí, hasta cuando la base de datos aguantaba.

Con una mejor base de datos la tentación era volver al cauce anterior. No lo hice porque la respuesta a la ineficiencia no son más recursos.

La bajamar revela las piedras, proverbio Lean

En otras palabras: cuando menguan tus recursos descubres tus fallos. Es buen momento para quitar esas piedras y no quedarse a esperar a que vuelva la marea. Es buen momento para resolver los fallos y no esperar a una mejora en la base de datos… a una mejora en la situación económica, tampoco.

Lo que hago

En primer lugar dejarme de fanatismos. Son malos en religión y también en productividad personal. GTD, por ejemplo, es un estándar, pero los estándares nunca son estáticos sino que deben mejorarse, deshaciéndonos de todo elemento que carezca de valor.

También en GTD puede haber muda.

Debido a que GTD es un sistema muy genérico, por necesidad, requiere que todo proyecto se divida en acciones de dos minutos y todas estas acciones se anoten por contextos. Esta es la aproximación necesaria cuando la variabilidad de las tareas es infinita.

Pero la variabilidad de las tareas nunca es infinita. Todavía me han de presentar a la persona que anote por contextos las tareas necesarias para asearse todos los días. O para conducir, por ejemplo, ambos proyectos en sentido GTD porque conllevan varias acciones de duración superior a dos minutos.

Mi nuevo estándar GTD

  1. Estandarizar el trabajo en lo posible.
  2. Identificar cada proyecto con su estándar, si tiene.
  3. Anotar en un proyecto sólo las acciones que se salen del estandár o la última acción completada de una secuencia fija.
  4. Llevar los proyectos muertos a un “archivo muerto”.

La 2. puede significar algo tan sencillo como poner a un proyecto el siguiente título “Escribir artículo Lean Personal”. Debido a mi experiencia ya sé las acciones estandárs que me lleva escribir un artículo.

La 3. supongamos que me interrumpen mientras buscaba información para mi artículo. Ahora es cuando debo introducir en mi sistema GTD “Buscar información” en #wikipedia“ (por ejemplo)” o, algo más concreto como “consultar A Factory of One”.

La 4. Un proyecto completado o desechado es un proyecto “muerto”. No es necesario que aparezca en el sistema “vivo” de la herramienta GTD que emplees, pero puede ser conveniente guardar referencia de ella para un futuro. Esto puede ser un simple archivo de texto plano con una línea por proyecto que contenga algo así como:

  1. Fecha de finalización
  2. Nombre de Proyecto.
  3. Incidencias, en su caso.
  4. Lugar de archivo, si es necesario (por ejemplo si no se tiene un archivo sistemático o si este proyecto no está archivado en el lugar habitual).

Lo que, en la práctica, escribo de esta manera en una nota de Evernote

13 de mayo
----------------
* Expediente de Nadie Hernández Hernández 
* Expediente de Nadie García García | Se finaliza por defunción del interesado | Archivado en "Sin expediente"

De esta manera descargo a mi aplicación GTD, pero, a la vez tengo la información si alguien me pregunta en el futuro por qué no terminé el expediente de Nadie García García y, como mínimo, me evito el mal rato y el tener que ir a buscar los documentos archivados. En cuanto al de Nadie Hernández Hernández se finalizó sin incidencias y está guardado en el archivo normal.

Aún hay más

Pero será en otra ocasión. Apenas he rascado lo que el Lean puede suponer para GTD, mucho menos lo que puede significar para la productividad personal. Tampoco os prometo que lo haga en un futuro porque bueno, para eso está Markovitz y yo quiero dedicar mi tiempo libre a escribir.

Por ello os recomiendo leer “A factory of One”, que está en Amazon, por ejemplo. Para todo lo demás está Google. Si aprendo algo más por mi cuenta, ya os diré.

Foto

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.