Sjekkliste før du bestemmer deg for mappestruktur og navnestandard

Når høstsesongen med oppdrag fra bedrifter og organisasjoner tar til, bestemmer mange seg for å rydde opp i filene i all hast. Resultatet er ofte en mappestruktur som ser fin ut den første uka og som ingen følger etter tre måneder. Jeg anbefaler å bruke en time på spørsmål før du oppretter den første mappen.

En mappestruktur og en navnestandard er avtaler mellom mennesker, ikke bare et system på en disk. Derfor bør du prøve avtalen mot virkelige situasjoner: en kollega som tar over midt i et prosjekt, en redaktør som aldri har sett opptakene, og deg selv om et halvt år når kunden ber om en gammel versjon.

Listen under er ikke ment som en fasit. Den er ment som en rekke kontrollspørsmål du kan gå gjennom alene eller sammen med teamet, og svarene bør skrives ned før noe tas i bruk.

Start med menneskene. Hvem åpner prosjektmappen i løpet av et vanlig oppdrag: fotografen, produsenten, redaktøren, kanskje en frilanser som kommer inn i siste fase? Hver av dem leter etter ulike ting, og strukturen må la alle finne sitt uten å spørre.

Spør deretter hvem som har ansvar for å opprette mappene. Hvis alle kan lage nye mapper når som helst, vil strukturen gli ut etter noen få prosjekter. Én person bør eie malen, og alle andre kopierer den i stedet for å lage sin egen variant.

Se også på hvor nye medarbeidere skal starte. Kan en som kommer første dag forstå oppsettet ved å se på en ferdig eksempelmappe med tydelige merkelapper, eller må noen forklare det muntlig hver gang?

• Hvem skal finne filer uten å ringe noen?
• Hvem eier malen for prosjektmapper?
• Forstår en nyansatt oppsettet på ti minutter?

Tell nivåene. En struktur med mer enn fire–fem nivåer fra prosjektmappen og ned til en enkeltfil blir tung å navigere, og filbaner kan bli så lange at enkelte programmer og disker begynner å protestere. Hold deg til det du faktisk trenger.

Sjekk at råmateriale, prosjektfiler, lyd, grafikk og leveranser har hver sin faste plass, og at rekkefølgen er lik i alle prosjekter. Nummerering foran mappenavnene gjør at de sorteres likt på alle maskiner, uavhengig av språkinnstilling.

Til slutt: er det klart hvor ting havner når de ikke passer noe sted? En mappe for diverse kan bli en søppelkasse, men uten den legger folk filer rett i rotmappen. Bestem på forhånd hva som skjer med unntakene.

• Færre enn fem nivåer ned til en enkeltfil
• Samme rekkefølge på toppmappene i alle prosjekter
• En avtalt plass for filer som ikke passer inn

Et filnavn skal fortelle nok til at du kan kjenne igjen filen uten å åpne den. Vurder hva som minst må stå der: prosjektkode, dato eller opptaksdag, kamera eller kilde, og et løpenummer. Skriv ned rekkefølgen og bruk den konsekvent.

Test navnene mot praktiske grenser. Unngå mellomrom, æ, ø og å og spesialtegn dersom filene skal flyttes mellom ulike systemer eller leveres til eksterne. Understrek eller bindestrek fungerer bra, så lenge teamet velger én av dem og holder seg til den.

Spør også hva som skjer når en fil endres. Bruker dere versjonsnummer, og hvordan ser det ut? Uten en avtale ender mange opp med navn som endelig_ny_siste, og det hjelper ingen å finne den riktige.

• Faste felt i fast rekkefølge
• Ingen spesialtegn som kan skape trøbbel ved overlevering
• Én måte å skrive versjon på

Før du innfører noe, lag en prøvemappe med et lite, ekte utvalg filer fra et avsluttet prosjekt. Legg dem inn i den nye strukturen med de nye navnene, og be en kollega som ikke har vært med på å utforme oppsettet, finne tre bestemte filer. Ser du at hun nøler, har du funnet et svakt punkt.

Prøv også en overlevering på tvers. Send prøvemappen til en redaktør og spør hva som var uklart. Svarene er ofte små ting, som en mappe med et navn bare du forstår, eller en forkortelse som ikke er forklart noe sted.

Skriv til slutt en kort lesemeg-fil i toppmappen med reglene i få setninger. Den tar fem minutter å skrive og sparer mange spørsmål senere.

Et oppsett som ikke vedlikeholdes, forfaller. Bestem når strukturen skal gjennomgås, for eksempel ved slutten av hvert prosjekt eller to ganger i året, og hvem som kan foreslå endringer. En endring uten varsel til resten av teamet skaper fort to systemer ved siden av hverandre.

Avklar hva som skjer med gamle prosjekter. Skal de flyttes til den nye strukturen, eller bare stå som de er med en notat om at de følger en eldre mal? Det siste er som regel enklere og tryggere enn å omorganisere ferdige prosjekter.

Til slutt: er malen lagret et sted der alle finner den, og er det tydelig hvilken versjon som gjelder? En mal som ligger i tre varianter på tre maskiner, løser ikke noe problem.

• Fast tidspunkt for gjennomgang
• Én felles plass for gjeldende mal
• Gamle prosjekter beholder sin gamle struktur