Aquesta entrada també està disponible en: Español
Hem parlat una infinitat de vegades de la força de GTD, la seva simplicitat i facilitat en la implementació fa que qualsevol pugui aprendre’n i posar-lo en marxa sense massa dificultat. Un cop engegat comencem a recollir els fruits i a descobrir detalls a polir que perfeccionen el nostre sistema. És precisament aquest factor el que ens fa avançar i millorar, entendre que darrera cada detall, cada petita inconcreció és troba una oportunitat perduda per ‘funcionar’ millor.
Vist des d’un altra perspectiva, la flexibilitat de GTD permet introduir i digerir comportaments que no son els més adients pel seu funcionament adient, però que tolerem per comoditat o per desconèixer una alternativa millor. Les següents línies repassen els errors més comuns i plantegen la seva correcció.
Imatge via soilse sota llicència Creative Commons
Com defineixes les teves tasques?
Com accions indivisibles o apareix el pensament “Ho puc fer tot d’una sola tacada” o “No cal tanta especificació”… Ens passa tots, una cosa és reconèixer les accions individuals que componen una tasca a realitzar, i que hauríem de definir dins del nostre sistema de llistes en forma de projectes, i una altra de molt diferent és saber que quelcom a fer esta composat per dues accions, però no tenir-ho en compte per creure que no val la pena realitzar la seva especificació:
“Buscar informació sobre el mètode lean startup” ¿Vols dir només buscar o llegir?
“Repassar i enviar post col·laboració a emprenderalia.com” La conjunció i defineix dues accions diferents. Potser no les separes per que vols realitzar-les de forma consecutiva per estalviar temps, oi?
Més enllà de la falta de granularitat al definir el que hem de fer apareix el problema de la inconcreció. Redactar accions com si fossin idees i no accions concretes que requereixen d’una especificació mínima. Quan les redactis pensa sempre que entendria una persona que no te res a veure amb la teva activitat.
“Planificació d’abastiments” Destaques un concepte, però si fos una ordre a una tercera persona com la donaries? “Realitzar l’informe per la planificació d’abastiments” No seria més correcte?
Estructurar i gestionar els projectes
Un projecte GTD no és una via per definir la seqüència d’activitat del mateix, per fer una previsió en costos de temps i altres recursos, simplement és una forma d’administrar el flux de treball que genera. El primer problema és entendre aquesta diferencia, ja que condicionarà la resta del procés.
Un projecte comença amb un germen d’accions provinents d’una planificació natural, o de la divisió d’una tasca en varies accions (com hem vist en el punt anterior). En el cas de la planificació natural generem el projecte de forma específica, perseguint una finalitat, els riscos són dos: ignorar el sistema de planificació natural o condicionar els seus resultats a una forma tradicional preparar l’activitat, on predomini el planning d’activitats i la previsió per sobre de la finalitat i el fons del que es persegueix. En ambdós casos apliquem una forma reactiva de fer les coses, ho intentem preveure i controlar-ho tot amb antelació el que suposa un error ja que és quelcom impossible. En aquest cas us recomano seguir els passos del sistema de planificació natural al peu de la lletra.
En el segon cas no és suficient dividir una tasca en accions per crear el projecte, ens hem de fer una pregunta sobre l’acció inicial: És realment el primer que hem de fer per engegar el projecte? Si la resposta és no, hem de buscar l’acció anterior i fer-nos la mateixa pregunta fins que la resposta sigui si.
“Retornar el llibre a la biblioteca” És la primera acció? NO
“Buscar el llibre prestat per la biblioteca” És la primera acció? Si
Això no defineix l’activitat complerta, però crea el lot d’accions inicial per engegar-la. Els projectes GTD són dinàmics, poden variar l’activitat o integrar noves accions que inicialment no han sigut tinguts en compte. La seva integració resulta tan senzilla com definir-la, escriure-la i introduir-la en el flux de treball.
Revisió i millora continuada
El pilar fonamental de GTD, la seva revisió setmanal per depurar el sistema. Com acció concreta ens permet netejar el sistema d’accions realitzades o mal ubicades en llistes que no toca, adonar-nos de quins son els projectes i accions que no avancen. Ficar a punt i crear un marc per a la reflexió.
Sense ànim de repetir-me i per destacar dos dels aspectes més importants insisteixo en la necessitat de la ortodòxia a l’hora de realitzar la revisió setmanal, deixant de costat invents i afegits propis que poden alentir-la i reduir el seu retorn en forma d’augment de la funcionalitat. Abans de corre hem de saber caminar, una vegada tinguem totalment interioritzat el sistema ja innovarem.
Sovint, tot i trobar coses que no van a l’hora ens retraiem i no ens atrevim a canviar-les, a fer quelcom diferent per millorar-les. Una tasca que es procrastina durant setmanes, un projecte que queda parat…. o simplement s’ignora i les deixem passar.
Més enllà de la revisió setmanal, preguntar-se si la forma de classificar les accions al processar l’inbox és del tot adient, de si escollim la següent acció de forma prou acurada, perquè no acabem d’integrar i aprofitar el nivell de perspectiva i la planificació natural? Fer-se preguntes i mantenir l’actitud crítica és fonamental per continuar aprenent i millorant. Com ho pots fonamentar: No saltant-te cap revisió setmanal i implementant les revisions de projectes i objectius.
El fet de repassar els teus assumptes i veure que no van com tu voldries, faran que et plantegis el perquè. Un cop et plantegis el perquè i vulguis canviar-ho et durà a trobar una solució, i la posterior correcció si aquesta no és del tot encertada… El camí és l’important, descobrir un procés d’aprenentatge que a posteriori es pugui aplicar en altres aspectes del sistema o de la teva activitat.
En una primera fase el que compta és acostumar-se a treballar amb el sistema, però per passar a una major sofisticació necessites augmentar el teu rigor a l’hora d’implementar-lo, identificar/ acceptar els errors que produeixes i plantejar una solució. La prova-error, sumat a un cert grau de reflexió per part del usuari, posa les bases per a la millora continuada del teu sistema.
