PA-versionering av dokument
I mina projekt använder jag alltid ett och samma system för namngivning av dokument och filer för att lätt kunna avgöra version. Systemet är grundat i hur jag arbetade på Ericsson i slutet av 90-talet, och jag har under åren gjort vissa justeringar och förtydliganden. Så här funkar det.
Heter det verkligen versionering? Nja, det är jag som utövar konstnärlig frihet och lånar från begrepp som Software Versioning –och det används på svenska även av t ex Svensk nationell datatjänst. I det här sammanhanget tycker jag det funkar fint, även om versionshantering kanske är att föredra för vissa målgrupper.
Bakgrund och principer
Filnamnet utgår alltid från en hierarki, där det första ordet i filnamnet meddelar vilket projekt som avses. Nästa ord kan handla om ett delprojekt eller ett arbetsområde. Till exempel förstudie, integration, eller kvalitet alternativt ux, arkitektur eller projektledning. Sedan avslutas dokumentnamnet med något ord som signalerar dess specifika innehåll.
Här är ett exempel, för ett projekt som heter smurfkoncept:
smurfkoncept-kommunikation-persona.pdf
Det här innebär att dokumentnamnet blir som en brödsmula (en sådan som ofta återfinns på webbplatser) som hjälper till att identifiera dokumentet även om det skulle hamna på villovägar utanför sin mappstruktur. Arbetar man i projektet får man också en god uppfattning om vem som ansvarar för dokumentet.
Tre är bättre än fyra
Skälet till att jag rekommenderar att man i andra ledet använder namn på delprojekt eller arbetsområde, snarare än båda två, är att jag vill att man strävar efter att begränsa sig till tre led totalt. I tre led är filnamnet användbart, men i fyra led kan dokumentnamnet bli för långt, och det börjar skapa mer frågor än svar.
Men alla regler är till för att brytas, och när det behövs förtydligande använder jag förstås fyra led.
Versionsnumret
Exemplet ovan saknar förstås fortfarande det väsentliga: versionsnumret. Hos de flesta organisationer ser jag här ett sammelsurium av olika varianter, som datum i olika längd och format:
- -20090910
- -09-09-10
eller någon variant av förkortad version och versionsummer,
- ver_02
- 1.1.3
- ver.2.03
Principen och ambitionen är sund men fallerar så fort den inte är enhetlig, och alla gör olika. Det är inte heller ovanligt att se olika versionsnummer i dokumentet och i filnamnet. Detsamma gäller datum, som ibland inte uppdateras när man uppdaterar filen.
När det gäller datum så bedömer jag också att det ofta är överflödigt och oväsentligt för filnamnet, eftersom filen automatiskt har tillhörande datum som visar när det skapades och senast sparades.
Filens versionsnummer i två delar
Hos mina kunder har jag ofta skapat förvirring när jag använder denna versionering eftersom det råkar vara så att mina initialer, PA, används flitigt. Helt naturligt tror då många att jag anger upphovsperson i filnamnet. Men så är det alltså inte. Men om du vill ha 'Per Axbom' som minnesteknik, varsågod. 😉
När du ser det här filnamnet:
smurfkoncept-kommunikation-persona-PA01.pdf
så ska du tänka "preliminär A-version, första versionen".
Tänk dig att alla dokument når en verkshöjd när de inte längre är tänkta att uppdateras. Det händer när till exempel en styrgrupp säger att nu är dokumentet godkänt, eller det bestäms att ett dokument ska skickas ut från arbetsgruppen till en given mottagare, eller att en designer bestämmer att nu är underlaget färdigt och ska inte ändras mer.
👆 Det är A-versionen.
Allt du gör fram till dess med dokumentet är alltså en preliminär A-version, eller PA. Den absolut första versionen av dokumentet är alltså PA01. Det är viktigt med den där nollan, eftersom det är sannolikt att många dokument har tvåsiffriga versioner innan de når A-versionen. Utan nollan så sorteras dokumenten fel. PA3 skulle till exempel sorteras in efter PA14.
Men om vi ändå behöver uppdatera efter detta?!
Jo, det går jättefint. Om vi skulle inse att vi behöver gå vidare och göra ett nytt, officiellt dokument baserat på A-versionen, då påbörjar vi på en B-version. Och vad heter då den första versionen då? Jo, just det:
smurfkoncept-kommunikation-persona-PB01.pdf
Nu ska sägas att det inte är jätteofta det händer att man påbörjar B, C, D-versioner och så vidare, men det är bra att veta att möjligheten alltid finns inom ramen för namngivningen.
Det gör också att det blir jättetydligt om en väsentlig, ny version har påbörjats.
Hur ser det ut?
Tänk att vi tittar i en mapp där vi har jobbat med ett dokument i sju versioner innan det blev en färdig A-version och sedan nödgades påbörja en B-version som blev klar redan efter två versioner. När vi sorterar på dokumentnamn skulle vyn se ut så här:
◽️ smurfkoncept-kommunikation-persona-A.pdf ◽️ smurfkoncept-kommunikation-persona-B.pdf ◽️ smurfkoncept-kommunikation-persona-PA01.pdf ◽️ smurfkoncept-kommunikation-persona-PA02.pdf ◽️ smurfkoncept-kommunikation-persona-PA03.pdf ◽️ smurfkoncept-kommunikation-persona-PA04.pdf ◽️ smurfkoncept-kommunikation-persona-PA05.pdf ◽️ smurfkoncept-kommunikation-persona-PA06.pdf ◽️ smurfkoncept-kommunikation-persona-PA07.pdf ◽️ smurfkoncept-kommunikation-persona-PB01.pdf ◽️ smurfkoncept-kommunikation-persona-PB02.pdf
De godkända versionerna hamnar högst upp, även om de skapades sist i respektive flöde, och allt annat hamnar i ordning efter hur de skapades. Det finns även organisationer som använder namnen för att i en logg kunna beskriva vilka ändringar som gjorts i varje version.
Såklart är det sannolikt att du sorterar in alla preliminära versioner i en egen underliggande arkiv-mapp när väl A-versionen är klar. Tänk då att arbetsområdet kommunikation har skapat flera dokument enligt denna princip. I deras övergripande mapp kanske vi hittar filer i stil med detta:
◽️ smurfkoncept-kommunikation-förstudie-A.pdf ◽️ smurfkoncept-kommunikation-instruktionsfilm-PA02.pdf ◽️ smurfkoncept-kommunikation-intressentanalys-A.pdf ◽️ smurfkoncept-kommunikation-nollmätning-A.pdf ◽️ smurfkoncept-kommunikation-persona-A.pdf ◽️ smurfkoncept-kommunikation-vision-A.pdf ◽️ smurfkoncept-ux-wireframes-PA06.pdf
Vi ser då genast vilka dokument man har klara och vilka som fortfarande är under arbete. Även om det såklart är rimligt att A-versioner och prel-versioner kanske ligger i olika mappar. Men om dokumentet skulle skickas i mejl, hamna i fel mapp eller laddas upp någon annanstans, så vet projektmedlemmarna var det hör hemma – och var man letar efter en ny version. Här ser vi att ett dokument från UX-teamet hamnat i samma mapp.
Fördelar med sammanhållen versionering
Du är varmt välkommen att använda dig av denna metod, såvida du inte har en annan som du föredrar. Det jag verkligen vill understryka är att det kan vara oerhört tidsbesparande att komma överens om sådana här enkla saker i början av ett projekt, oavsett vilken metod som används. Några av fördelarna är:
- Det motverkar förvirring och missförstånd för alla, om alla namnger enligt samma princip.
- Du förstår snabbt vem/vilka det är som ansvarar för ett dokument.
- Du kan lista ut var ett dokument hör hemma i mappstrukturen.
- Du ser om dokumentet är att betrakta som färdigt eller om du ska räkna med att det kommer fler versioner.
- Om du är osäker på om du har den senaste versionen så går det snabbt att se i mappen.
- Du ser indirekt progress i arbetet för en arbetsgrupp eller ett delprojekt.
Som alltid när man inför sådana här system gäller det att vara snäll mot varandra. Det kommer fortfarande bli fel och det kommer fortfarande bli missförstånd. Men kanske är det ändå lite bättre än det var innan.
Lycka till!