Cómo organizo mi actividad profesional con GTD

Organizar la actividad con GTD en un entorno de trabajo complejo con sus propias metodologías para administrar proyectos es un problema. Contraponer varias formas de trabajar destaca puntos fuertes y carencias de ambas.

Hace tiempo que buscaba la forma implementar GTD en mi entorno laboral y creo que perfil, con algunas concesiones que no tocan la estructura principal, lo he conseguido.

Sobre mi trabajo

La creación de software es una actividad compleja que ya cuentan con una segmentación propia de su actividad, por no hablar de un vocabulario para la misma. Crear equivalencias, paralelismos, con GTD se convierte en un problema adicional.

Trabajo con una aplicación de gestión de tickets a través de la cual me llegan los proyectos y tareas a realizar.

Cada ticket es una solicitud de corrección o mejora. Cuando hablo de proyecto lo hago de un conjunto de nuevas funcionalidades.

Incluyo un término de creación propia, el de unidad funcional. Mis proyectos de software no son equiparables a un proyecto GTD, por extensión y propósito.

Una unidad funcional sería la unidad básica. Cada elemento a realizar que acabaría convertido en una nota/acción en lista de próximas acciones en el sistema GTD. Ex: Crear una UI o un proceso con una finalidad concreta.

Mi GTD no es GTD

O porque hibride GTD con algunas características de SCRUM

GTD no encaja para administrar el trabajo de un programador y ya está. Transformar las solicitudes de los clientes en acciones y proyectos Getting Things Done con la misma rigidez que lo hacía en mis proyectos y asuntos personales era una locura.

La carga de trabajo derivada de preparar la actividad a realizar se disparaba y entorpecía mi verdadero rol. Por eso acabe desistiendo.

La lectura de SCRUM de Jeff Sutherland me dio la solución a algunos asuntos claves que no permitían el encaje entre mi actividad y mi sistema.

Dividir el trabajo en acciones

El primer asunto clave era la división de las solicitudes realizadas por los clientes o las especificaciones de nuevas funcionalidades en unidades indivisibles de actividad. Lo que en GTD se llaman acciones.

SCRUM define una lista llamada Backlog donde se detallan todas las funcionalidades que se implementarán. Para cada una se redacta una historia, la cual incluye un título descriptivo de la funcionalidad y una descripción de la misma.

Trabajar con historias, y dividirlas en unidades funcionales, me resultaba más natural que atomizar todo en proyectos y acciones GTD.

Lo veía y lo sentía! Ahora era viable gestionar mi trabajo con GTD, o algo similar fiel a su idea original.

Las listas de mi sistema

Mantengo el sistema de listas de GTD. Según el estado de la acción a realizar deposito cada una de las historias en una de las siguientes listas:

Mis bandejas de entrada

Mi bandeja de entrada principal sería la aplicación de tickets donde recibo las solicitudes de clientes, del equipo de apoyo o del resto de analistas. Recibo una descripción del error o una especificación de las funciones a implementar.

La otra bandeja de entrada es el correo electrónico. Cuestiones de coordinación, documentación adicional para proyectos y pequeños asuntos.

El mismo gestor de correo termina convertido en un archivo de material de apoyo adicional donde guardo la relación de mensajes recibidos en libretas agrupadas en dos categorías: proyectos y archivo.

Algún día: El Backlog

La lista de algún día/Tal vez se ha dividido en dos listas, una de posibles mejoras en el software o la forma como trabajamos (Algún día), y la otra lo que sería el Backlog. En esta última se van depositando las acciones inminentes pero que no realizaré en los próximos días.

La misma aplicación de tickets con las notas que aún no se han transformado en historias sirve como Backlog.

En espera

La lista en espera es la lista de control de los asuntos delegados o en espera de una interacción con tercero (clientes, colaboradores…). Dentro de la aplicación de correo mantengo una carpeta con este fin.

Próximas acciones

La lista de próximas acciones contiene el trabajo a realizar AHORA. Una vez marcadas las prioridades semanales, lo que no siempre depende de mí, transformo tickets en historias y las deposito en la lista de próximas acciones.

Como en GTD las divido en contextos. Cada contexto es un entorno de trabajo diferente, en mi cada contexto es un entorno de programación diferente. Los llamaré #Escritorio, #Web y #Servicios.

No sólo son ámbitos diferentes, también son entornos de trabajo que requieren de herramientas diferentes, de una configuración previa y reiterada – aunque sea mínima – y en definitiva de un notable cambio de chip cada vez que paso de uno a otro.

El cambio de un entorno a otro requiere de un esfuerzo a tener en cuenta. Me puedo pasar días trabajando en un contexto antes de pasar a otro.

Sumo un cuarto contexto para pequeñas tareas (#Otros) como contestar correos y devolver llamadas… que hago al final de la mañana o por la tarde, si es que tengo alguna.

Transformar

Lo que en GTD sería el paso de procesar o transformar ha tenido unas implicaciones considerables en mi forma de trabajar.

En primer lugar me obliga a leerme detenidamente el ticket que me llega o hacer una lectura completa del proyecto antes de empezar para tener una visión global.

Me invita a parar a pensar cómo hacer las cosas antes de empezar, si tienes que aclarar algún punto con el analista o el cliente, o en qué orden implementarás las modificaciones, etc …

Los tickets ya hacen referencia a una funcionalidad y quizás el termino dividiendo dos o tres subtareas. El proceso es importante en aquellas solicitudes con una gran carga de trabajo. Me obliga a dividirlas en bloques más fácilmente realizables.

Con qué herramientas lo implemento

Mi implementación es mínima. Aplicación de tickets para backlog, gestor de Email como archivo de material de apoyo y lista En espera. Mi lista de próximas acciones la implemento en documentos word.

Utilizo un documento word para cada uno de los tres contexto principales: Escritorio, servicios y web, más una lista en papel por pequeños asuntos.

En cada documento word anoto de forma secuencial cada una de las historias, en el orden en que pienso realizarlas. Para cada título en negrita y descripción de cada historia.

Escribir me ayuda a ordenar ideas, aunque sea a pequeña escala como en el caso de las historias. Detallar que voy a hacer ayuda a eliminar los puntos ciegos que pueda tener una especificación, los saca a la luz y pide su aclaración.

En su día pensé en implementar la lista de próximas acciones con Trello. Tres columnas o listas para cada contexto pero lo descarté. Mi sistema actual me parece más natural y accesible.

–

Un apunte final. Reviso una vez a la semana para mantener limpias mis listas eliminando los asuntos que ya han sido atendidos. El paso de revisión es el mínimo para mantener operativo el sistema.

Como habéis visto se trata de una forma de hacer las cosas sin concesiones ni florituras. Lo más importante es centrarme en el trabajo a realizar sin perderme en cuestiones de organización y administración de lo que tengo que hacer.

He escrito este post para una petición de un lector. Si tienes temas para proponerme recuerda que lo puedes hacer a través de @davidtorne o del formulario de contacto de la página.