Bloggande är personlig utveckling

Under 2005 pluggade jag marknadskommunikation och projektledning på Berghs School of Communication. Samtidigt drev jag en filmbutik på nätet (DVDarena), tog några konsultuppdrag samt drev egna webbutvecklingsprojekt. Jag skrev också min första blogg, forsandree.blogspot.com.

Flera av inläggen från 2005 var reflektioner jag gjorde om mig själv och mitt sätt att arbeta. Nu sex år senare har jag gått igenom min gamla blogg, rensat och flyttat över material till min nya vd-blogg.se (tekniknot: det går faktiskt att nästan få till 301 redirect från Blogger till Wordpress).

Jag konstaterar två saker: Dels att det faktiskt funkar att medvetet utveckla sig själv. Dels att bloggen är ett utmärkt verktyg för personlig utveckling. De saker jag skrev 2005 har jag faktiskt fortsatt jobba med ända sen dess och blivit bättre och bättre på.

Här är en sammanställning av inlägg från 2005, samtliga på temat personlig utveckling.

Så såg forsandree.blogspot.com ut

Så får du saker gjorda med Getting Things Done (GTD) i gMail

2005 läste jag en bok som kraftigt förändrade mitt sätt att tänka och jobba. Sedan dess har jag läst den igen ett flertal gånger, läst uppföljarna, läst ett tiotal relaterade böcker samt följer ett antal bloggar och författarens eget nyhetsbrev.

Den boken var Getting Things Done av David Allen.

Getting Things Done (GTD som det ofta förkortas) är en metod för att öka sin personliga produktivitet. Helt enkelt: Få saker gjorda. Getting Things Done utgår från hur mänskligt beteende faktiskt fungerar, till skillnad från de flesta andra handböcker i produktivetet som bygger upp onaturliga arbetssätt och teoriska idealkonstruktioner som inte fungerar i praktiken.

Googlar man på GTD får man över fem miljoner träffar. Och det har växt fram mängder av hjälpmedel för att jobba enligt GTD. Jag tycker tyvärr att många gör det mer komplicerat än det behöver vara. David Allen är pragmatisk och skriver att det fungerar lika bra med papper och penna som med webbaserade verktyg. Häromdagen ställde Mattias Östmar en fråga på Twitter om vilka verktyg folk använder. Jag kör GTD i gmail, då har jag det alltid tillgängligt, det är flexibelt, inga extra inloggningar och jag kan direkt flytta saker mellan GTD, mejlen och kalendern. Jag ska beskriva hur jag gör, men först försöka mig på att ge en mycket kort introduktion till GTD.

Grundprinciperna i GTD i fyra steg

 

1. Skriv ner allt. Och då menar jag ALLT, både det du ska göra, vill göra, har tänkt på att göra och inte gjort. Stress och svårigheter att koncentrera sig på en uppgift beror helt enkelt på att man har för mycket att tänka på, även om man kanske inte är medveten om det. Jag skulle ju köpa mjölk, jag måste skriva ett nytt blogginlägg, jag måste komma ihåg att boka tvättid, jag vill gå på bio, den där skivan kanske jag kan köpa, jag borde laga spisen, chefen ville ha ett möte, jag behöver få svar från Anna, när ringde jag mamma sist och så vidare och så vidare. När allt är nerskrivet kommer hjärnan att släppa taget och man kan fokusera på en sak i taget.
   
2. Bestäm om du ska agera. Många av de saker du skrivit ner kommer att vara sånt du inte direkt ska agera på.
   
   • Ska det göras "snarast" så sortera det i en hög.
   • Ska det göras på ett visst datum så ska det skrivas in i kalendern.
   • Väntar du på att någon annan ska göra något så sortera det under rubriken "Väntar på". Det kan till exempel vara "väntar på svar från chefen angående semester" eller "väntar på skivan jag beställde".
   • Är det mer en idé som egentligen inte behöver någon snar åtgärd så sortera det under rubriken "Nångång/kanske". Till exempel "den här skivan kanske jag ska köpa" eller "det vore kul att besöka Paris". 
   • Ska det inte göras alls så ska det slängas bort eller arkiveras.
3. Bestäm nästa konkreta steg för de saker som ska göras snarast. Den allra första saken du behöver göra, är det enda din hjärna verkligen kan förstå och agera på, men den behöver hjälp att hitta dit. Om du har "skriva mejl till chefen" på din att-göra-lista, men det aldrig blir gjort, så fundera på vad nästa steg egentligen är. Ändra benämningen på åtgärden till exempelvis "plocka fram papperet med uppgifterna som chefen ville ha". När du väl plockat fram papperet kommer du troligen inte att skjuta upp på att skriva mejlet. Och att ta fram papperet är greppbart för hjärnan.
   
4. Sortera efter kontext. Sortera de konkreta åtgärder du ska göra snarast, efter vilken kontext de ska göras i. Om du har "köp mjölk" på din att göra-lista, så ska du köpa mjölken när du ändå är i affären, även om du har 10 andra saker att göra som är "viktigare". Eller så här: Det spelar ingen roll hur hög prio det är på "skriva ut rapporten", så länge du inte är vid skrivaren kan du inte göra det. Så istället för att prioritera, sortera de saker du ska göra i listor som "Hemma", "På kontoret", "I affären", "Vid nästa möte med chefen". Här gäller det att du skapar en uppsättning kontexter som fungerar för just dig.

GTD i gMail

Jag har gjort enklast möjliga uppsättning av GTD i Google Mail. Jag använder gMails etiketter, färgmärkning samt filter. Det ser ut så här (i det här fallet visas kontexten "Läsning":

1. Inkorgen används på det sätt som David Allen beskriver för insamlingen av allt som ska göras. När något ska skrivas upp så mejlar jag till mig själv. En mycket stor del av de saker som ska göras har dessutom sitt ursprung i mejl från andra, då behöver de bara sorteras. I exemplet syns att jag har 7 olästa mejl i inkorgen, målet är att den ska tömmas hela tiden och det som ligger där fördelas ut enligt nedan.
2. De gröna etiketterna med namn som inleds med K är kontexter. I det här fallet har jag klickat på kontexten "Läsning", där jag har sånt som jag vill läsa när jag har lite tid över. (Bilden är redigerad och visar bara några av mina kontexter.)
3. De bruna etiketterna med namn som inleds med P är projekt. För David Allen är allt som omfattar mer än en åtgärd, i själva verket ett projekt. Jag använder inte riktigt den synen på projekt, utan definierar projekt lite smalare. En åtgärd kan ha både en grön kontext-etikett och en brun projekt-etikett. (Bilden är redigerad och visar bara några av mina projekt.)
4. Här syns de åtgärder som ligger i den aktuella vyn ("Läsning"). I det här fallet har samtliga åtgärder fått etiketten "Läsning" automatiskt genom ett filter i gMail (se nedan).

Så sätter du upp GTD i gMail

1. Skapa dina etiketter. Klicka på Inställning och därefter Etiketter (eller här) och skapa etiketter för de kontexter och projekt du vill ha.
2. Färgsätt etiketterna. Klicka på den lilla ytan framför etiketten där den visas till vänster i gMail. Du får en liten meny med färgval.
3. Börja sortera. Enklast är att dra-och-släppa. Klicka på den lilla prickade ytan längst till vänster om varje åtgärd/mejl. Det går också bra att öppna mejlet och välja i menyn "Etiketter".
   
   
   
   
4. Skapa filter. Vissa delar i flödet kan effektiviseras med hjälp av gMails filter. Jag använder det dels för kontexten "K/Läsning" och "K/Betalningar". Och dels för att sätta många av de bruna projekt-etiketterna. I båda fallen använder jag filter baserat på Från-adress. Mejl som är skickade från familjen hamnar i K/Fam och det som är relaterat till betalningar jag ska göra hamnar i K/Betalningar (här har jag faktiskt också ett filter på mejlets ämne). Och nyhetsbrev, prenumerationer och liknande hamar i K/Läsning. För att skapa ett filter, klicka på "Skapa ett filter" till höger i sökrutan och följ gMails instruktioner.
   
   
   
5. Ändra namn. Om du ska göra flera åtgärder efter varandra, ändra ämnet för mejlet genom att vidarebefordra det till dig själv (där finns ett fält för att ändra ämnesrad).
6. Tips: Du kan mejla direkt till en etikett. Om du skapar filter som fångar alla mejl vars ämnesrad innehåll till exempel #Betalningar så behöver du bara skriva in #Betalningar så får mejlet automatiskt rätt etikett när du skickar det.

Läs också
karatekoll.se, en blogg på svenska om GTD och personlig effektivitet
Fleecelabs.se, Kom igång med GTD på det nya året!
Macworld, Så ordnar du upp ditt liv med GTD-metoden

GTDinbox - GTD i gMail i Firefox
GTDinbox är en addon till Firefox för att köra GTD i gmail. Jag använde den under en kort period men tyckte att den tillförde mer komplexitet än värde - och jag blev beroende av just den webbläsaren.

Projektledning enligt Sokrates

Sokrates använde en speciell metod i sina diskussioner med invånarna i Aten. Han visade sällan någon konkret åsikt själv, utan ställde små och öppna frågor till dem på ett sätt som utmanade andras åsikter och ställde olika uttalanden mot varandra. På så sätt tvingades folk resonera sig fram till bättre och bättre lösningar. Istället för att diskutera som motståndare, så tvingas alla inblandade försvara och utmana varandras åsikter. Om Sokrates fick en fråga, svarade han ofta med att anta att frågan var verklighet och låta motparten tänka vidare på konsekvenserna av detta.

Det är en typ av undersökande arbetssätt som jag tror är väldigt användbart i projektledning. Frågor och svar driver successivt arbetet framåt. Det leder till:

• bättre beslut eftersom man utforskat förslagen tillsammans, dragit dem till sin spets och sett var det kan finnas brister
• bättre förankring eftersom parterna som är inblandande också varit med och tillsammans resonerat kring alternativen och kommit fram till vad som är bäst (konsensusbeslut betyder inte att alla håller med, men att alla varit med och förstår resonemangen som lett fram till beslutet)
• mer pedagogiskt synsätt, deltagarna måste förklara varför de tänker som de gör och de blir successivt mer och mer pedagogiska när de tar upp saker (vilket är mycket postivit med tanke på mängden olika professioner som ofta är inblandade i webbprojekt)
• högre kreativitet, eftersom man inte direkt accepterar det någon säger utan utmanar idéerna och förbättrar dem
• mer struktur, eftersom frågetekniken hjälper till att splittra upp stora problem och idéer i små hanterbara enheter

Några nyckelord för att arbeta mer sokratiskt är samarbete, aktivt lyssnande, klarhet, tydlighet samt kritiskt tänkande.

• Fråga alltid varför, i minst två led. Exempel: "Vi tänkte lägga knappen till vänster", "Varför ska den ligga till vänster?", "Den får mer uppmärksamhet då", "Varför får den det?". På den nivån börjar man nå en intressant diskussion.
• Tänk högt, försök "förlänga" resonemangen. Exempel: "Och vi vill att den där knappen ska få mer uppmärksamhet för att den är en del av köpprocessen på sajten?".
• Uttryck dig hypotetiskt och prövande. Dels för att öppna för att andra ska komma med synpnukter, dels för att skapa ett klimat där det är okej att spekulera utan att först ha tänkt igenom allt i minsta detalj. Exempel: "Om vi antar att knappen vore en del av köpprocessen, hade vi placerat den annorlunda då?".
• Utgå från att andra har rätt. Även om du inte håller med, prova anta att de har rätt och för ett resonemang från den synvinkeln. Det är ofta lättare att utmana en idé från "insidan" än utifrån.

Sokrates utgick från förnuftets rätt att fritt och förutsättningslöst pröva alla frågor, och att den som har rätt insikt också handlar rätt. Ett - välvilligt - kritiskt ifrågasättande hjälper till att upptäcka bristerna i ett resonemang och på så sätt når man allt närmre en optimal lösning. Konfrontationen mellan människor, synsätt, och erfarenheter leder till allt bättre resultat.

En ledare är inte en person som alltid har rätt svar, utan en person som ställer rätt frågor.

Definition of Done: How to Test

Först en mycket kort historisk återblick för att förstå vad Definition of Done (DoD) handlar om. I jordbrukssamhället var det ofta uppenbart när ett arbetet var slutfört. När åkern var plöjd var man klar och kunde ta itu med nästa uppgift eller med gott samvete gå hem för dagen.

Så fungerar det inte i informationssamhället. Allt kunskapsarbete lider av att det aldrig tycks ta slut, det kan alltid göras lite bättre och det är svårt att veta när det egentligen är "klart". Blir det överhuvud taget nånsin klart?

Därför är Definition of Done en helt avgörande del i Scrum och andra agila projektmetoder. För att styra projektet framåt behöver man definiera när respektive uppgift, sprint eller projekt är klart. Definition of Done är helt enkelt en checklista över vad som ska vara klart. Jag har bland annat använt den här varianten:

Definition of Done (exempel från offentlig sektor)

• Kod testad
• Användningstestat
• Fel åtgärdade
• Utvärderat så att kraven för tillgänglighet för människor med funktionsnedsättning uppnås (Verva nivå 1)
• Koden validerad enligt W3C
• Modul-dokumentation upprättad/uppdaterad

Men hur man upprättar en Definition of Done är inte självklart och i praktiken kommer den säkert att förändras under projektets gång. Två utmaningar jag tycker återkommer är att:

• man måste få samsyn på vad Definition of Done innebär och förståelse för varje punkt. Det räcker inte att man förstår "sin del" eftersom de nästan alltid hänger ihop.
• det är ofta i avgränsningen av uppgifter, funktioner, sprintar eller delmål som komplikationerna uppstår. Checklistan ovan är ganska meningslös om man inte vet ifall "Gör det möjligt att skicka nyhetsbrev" även inkluderar "Nyhetsbreven ska kunna innehålla bilder".

Bättre Definition of Done med How-to-test och förändring på scrum-väggen

I nästa projekt kommer jag att prova två åtgärder för att bättre hantera dessa svårigheter.

• Arbeta med konceptet "How-to-Test" som alternativ eller komplement till Definition of Done. Genom att fokusera mer på hur något ska testas uppnår man flera saker: det är ett mer visuellt sätt att beskriv vad som ska åstadkommas, det är något som alla medlemmar i gruppen har lättare att ta till sig och det för arbetet mycket närmre den affärsnytta som projektet ska skapa.
• Se till att alla steg i Definition of Done också har en motsvarighet på scrumväggen. Den traditionella indelningen av en scrumvägg är Ej påbörjat, Pågående, Avslutat. Till detta kanske man ska lägga till exempel Klart för test och utvärdering och Testat och utvärderat?

Dags att revidera den traditionella projekt-triangeln

Projekttriangeln är en av grundbultarna i klassisk projektmetodik. Tid ("jag vill att det ska gå snabbt"), pengar ("jag vill ha det billigt") och resultat ("jag vill att det ska bli bra") blir var sin sida i en triangel för att visa på beroendena mellan de tre enheterna. Poängen är förstås att förändras budget så påverkas de båda andra, och så vidare.

Jag tycker att modellen har brister när den tillämpas i moderna projekt, till exempel webbprojekt. Kraven och verkligheten förändras och "resultat" blir ett för trubbigt mått. Jag föreslår därför istället en projektromb.

Tid och pengar är samma enheter som i den traditionella projekttriangeln, men resultat har delats in i kvalitet och omfång. Om kvalitet handlar om hur bra en funktion fungerar ("jag vill att det ska bli bra") så handlar omfång om hur många funktioner som finns ("jag vill ha mycket av 'det'"). Att göra en distinktion mellan kvalitet och omfång är väldigt viktigt i webbprojekt eftersom vi ofta ställs inför valet att förbättra en funktionalitet mer och mer eller att låta det vara och fokusera på att bygga nästa funktionalitet.

Jag har använt en projektromb i två projekt. Det kan se ut till exempel så här:

• Kvalitet framför omfång – vi levererar färdigställda och kvalitetssäkrade resultat stegvis, mängden resultat kan skäras ner.
• Kalendertid framför budget – måste vi välja så utökar vi budgeten, inte kalendertiden.

Mer lyckade webbprojekt genom att belöna kompromisser

Den största utmaningen i IT-projekt är att överbrygga glappen mellan alla olika professioner, kompetenser, behov och krav. Jag tror att ett viktigt redskap för detta är att helt enkelt prata om det i teamet. Till exempel diskutera vad varje person ser som en "bra lösning".

I nästa projekt kommer jag att testa en modell där vi lyfter fram och belönar "kompromisser" eller "balans mellan mellan olika perspektiv" som positivt. Det som ska premieras är inte den bästa serverlösningen, de coolaste client-side-grejerna, den häftigaste grafiska formen, den bästa interaktionsdesignen, den mest välskrivna texten eller den mest researchade artikeln. Det vi ska fråga oss vid varje avstämningsmöte är istället "var det här en bra kompromiss".