Aquesta entrada també està disponible en: Español
Organitzar l’activitat amb GTD en un entorn de treball complex amb les seves pròpies metodologies per administrar projectes és un problema. Contraposar varies formes de treballar destaca punts forts i mancances d’ambdues.
Fa temps que buscava la forma implementar GTD al meu entorn laboral i crec que perfil, amb algunes concessions que no toquen l’estructura principal, ho he aconseguit.
Sobre la meva feina
La creació de programari és una activitat complexa que ja compta amb una segmentació i un vocabulari propi. Crear equivalències, paral·lelismes, amb GTD es converteix en un mal de cap addicional.
Treballo amb una aplicació de gestió de tiquets a través de la qual m’arriben els projectes i tasques a realitzar.
Cada tiquet és una sol·licitud de correcció o millora. Quan parlo de projecte ho faig d’un conjunt de noves funcionalitats.
Incloc un terme de creació pròpia, el d’unitat funcional. Els meus projectes de programari no són equiparables a un projecte GTD, per extensió i propòsit.
Una unitat funcional seria la unitat bàsica. Cada element a realitzar que acabaria convertit en una nota/acció en llista de pròximes accions en el sistema GTD. Ex: Crear una UI o un procés amb una finalitat concreta.
EL meu GTD no és GTD
O perquè vaig hibridar GTD amb algunes característiques d’SCRUM
GTD no encaixa per administrar la feina d’un programador i ja està. Transformar les sol·licituds dels clients en accions i projectes Getting Things Done amb la mateixa rigidesa que ho feia pels meus projectes i assumptes personals era una bogeria.
La carrega de treball derivada de preparar el l’activitat a realitzar es disparava i no em permetia dedicar-me a la meva feina. Per això vaig desistir d’aplicar-lo al meu rol de programador.
La lectura d’SCRUM de Jeff Sutherland em va donar la solució alguns assumptes claus que no permetien l’encaix entre la meva activitat i el meu sistema.
Dividir la feina en accions
El primer era la divisió de les sol·licituds realitzades pels clients o les especificacions de noves funcionalitats en unitats indivisibles.
SCRUM defineix una llista anomenada Backlog on es detallen totes les funcionalitats que s’implementaran. Per cadascuna es redacta una historia, la qual inclou un títol descriptiu de la funcionalitat i una descripció de la mateixa.
Treballar amb histories, i dividir-les en unitats funcionals, em resultava més natural que atomitzar-ho tot en projectes i accions GTD.
Ho veia i ho sentia! Ara era viable gestionar la meva feina amb GTD, o quelcom similar i fidel a la seva idea original.
Les llistes del meu sistema
Mantinc el sistema de llistes de GTD. Segons l’estat de l’acció a realitzar diposito cadascuna de les histories en una de les següents llistes:
Les meves safates d’entrada
La meva safata d’entrada principal seria l’aplicació de tiquets on rebo les sol·licituds de clients, del equip de suport o de la resta d’analistes. Rebo una descripció del error o una especificació de les funcions que se’m requereix implementar.
L’altra safata d’entrada és el correu electrònic. Qüestions de coordinació, documentació addicional per projectes i petits assumptes.
El mateix gestor de correu s’acaba convertit en un arxiu de material de suport addicional on guardo la relació de missatges rebuts en llibretes agrupades en dues categories projectes i arxiu.
Algun dia: El Backlog
La llista d’algun dia/Potser s’ha dividit en dues llistes, una de possibles millores al software o la forma com treballem, i l’altra el que seria el backlog. En aquesta ultima es van dipositant les accions pendents i imminents però que no realitzaré en els propers dies.
La mateixa aplicació de tickets amb les notes que encara no s’han transformat en histories serveix com a Backlog.
En espera
La llista en En espera és la llista de control dels assumptes delegats o en espera d’una interacció amb tercer (clients, col·laboradors…). Dins de l’aplicació de correu hi mantinc una carpeta amb aquesta finalitat.
Pròximes accions
La llista de pròximes accions conté el treball a realitzar ARA. Un cop marcades les prioritats setmanals, el que no sempre depèn de mi, transformo tiquets en històries i les diposito en la llista de pròximes accions.
Com en GTD les divideixo en contexts. Cada context és un entorn de treball diferent, en el meu cada context és un entorn de programació diferent. Els anomenaré #Escriptori, #Web i #Serveis.
No tant sols son àmbits diferents, també són entorns de treball que requereixen d’eines diferents, de una configuració brava – encara que sigui mínima – i en definitiva d’un notable canvi de xip cada cop que passo d’un a un altre.
El canvi d’un entorn a un altre requereix d’un esforç a tenir en compte. Em puc passar dies treballant en un context abans de passar a un altre.
Sumo un quart context per petites tasques (#Altres) com contestar correus i tornar trucades… que faig al final del mati o la tarda, si es que en tinc alguna.
Transformar
El que en GTD seria el pas de processar o transformar ha tingut unes implicacions considerables en la meva forma de treballar.
En primer lloc m’obliga a llegir-me detingudament el ticket que m’arriba o fer una lectura completa del projecte abans de començar per tenir una visió global.
Et convida a parar a pensar com fer les coses abans de començar, si has d’aclarir algun punt amb l’analista o el client, o en quin ordre implementaràs les modificacions, etc…
Els tickets ja fan referència a una funcionalitat i potser l’acabo dividint dues o tres subtasques. El procés és important en aquelles sol·licituds amb una gran carrega de treball. M’obliga a dividir-les en blocs més fàcilment realitzables.
Amb quines eines ho implemento
La meva implementació és mínima. Aplicació de tickets pel backlog, Gestor d’Email com arxiu de material de suport i llista en espera. La meva llista de pròximes accions la implemento en documents word.
Utilitzo un document word per cadascun dels tres context principals: Escriptori, serveis i web, més una llista en paper per petits assumptes.
En cada document word anoto de forma seqüencial cadascuna de les histories, en l’orde en que penso realitzar-les. Per cadascuna títol en negreta i descripció de cada historia.
Escriure m’ajuda a ordenar idees, encara que sigui a petita escala com en el cas de les històries. Detallar que faré ajuda a eliminar els punts cecs que pugui tenir una especificació, els treu a la llum i demana la seva aclariment.
En el seu dia vaig pensar en implementar la llista de pròximes accions amb Trello. Tres columnes o llistes per cada context però ho vaig descartar. El meu sistema actual em sembla més natural i accessible.
–
Un apunt final. Reviso un cop a la setmana per mantenir netes les meves llistes eliminant els assumptes que ja han sigut atesos. El pas de revisió és mínim. El mínim per mantenir operatiu el sistema.
Com heu vist es tracta d’una forma de fer les coses sense consecions ni floritures. El més important és centrar-me en la feina a realitzar sense perdre’m en qüestions addicionals com l’organització i l’administració del que he de fer.
He escrit aquest post per una petició d’un lector. Si tens temes per proposar-me recorda que ho pots fer a través de @davidtorne o del formulari de contacte de la pàgina.
