Best practice for dokumentversionsstyring

Kort fortalt

• Hold nummereringssystemet stabilt, når det først er valgt: at omnummerere ødelægger hver krydshenvisning, der citerede det gamle nummer.
• Tryk version, dato og godkender på samme faste sted på hver side, ikke kun i filnavnet eller egenskaberne.
• Lad aldrig to personer redigere den »gældende« version parallelt uden en lås- eller checkout-konvention.
• Beslut på forhånd, skriftligt, præcis hvad der gør en ændring til en hovedversion over for en mindre version.
• Behandl »ingen ændringer nødvendige« som et registreret reviewudfald, ikke stilhed.
• QueryChart erstatter checkout-konventionen med ét kanonisk, levende diagram: se /features/version-control.

Et system er kun så godt som dets andet år

Et nummereringssystem svigter sjældent i sin første måned. Det svigter i sit andet år, når den person, der fastsatte »hele tal til udstedte kopier«, er gået videre, en ny dokumentansvarlig opfinder en lidt anden regel til at håndtere ét akut tilfælde, og to konventioner begynder at køre gennem det samme register samtidig. Denne side antager, at den grundlæggende beslutning allerede er truffet (at vælge et system i første omgang er gennemgået på /da/guides/versionsstyring-af-dokumenter) og handler om den håndfuld vaner, der holder et valgt system kørende, når reel volumen, udskiftning og hastværk rammer det.

Fire ting går galt, efter systemet er valgt, og ingen af dem handler om selve systemet. At omnummerere et eksisterende bibliotek for at rette en opfattet fejl ødelægger hver krydshenvisning, oplæringsregistrering og tidligere auditcitat, der navngav de gamle numre, så det koster som regel mere end at leve med fejlen. Et versionsnummer, der kun findes i et filnavn eller et egenskabspanel, forsvinder, i det øjeblik nogen printer en side eller videresender et skærmbillede, så det har brug for en fast, trykt placering i stedet. To forfattere, der redigerer den samme »gældende« fil samme eftermiddag, er slet ikke et nummereringsproblem: det er en manglende lås- eller checkout-konvention, og intet system overlever uden én. Og et periodisk review, der ikke finder noget galt, skal stadig efterlade et spor, ellers er det umuligt at skelne et år senere fra et review, der aldrig fandt sted. Intet af dette er dokumentets hele livsforløb (anmodning til udfasning gennemgås fuldt ud på /da/templates/dokumentstyring-proces). Det er nummereringslaget inden i det livsforløb, gjort godt frem for blot gjort.

QueryChart fjerner én af disse fejltilstande strukturelt frem for gennem politik. Der findes ét kanonisk, levende diagram pr. dokument frem for et sæt filer, nogen skal huske at låse, hver gemning fanges automatisk som en ny post i ændringsloggen med aktøren og det præcise felt, der ændrede sig, og Sammenlign versioner sætter to vilkårlige revisioner side om side. To personer kan ikke lydløst forgrene den »gældende« kopi, for der findes kun én, og hele dens historik er en forespørgsel frem for en hukommelsesprøve. Se /features/version-control.

Hvor disse praksisser dukker op i ét dokuments liv

Samme 18-rækkers diagram til dokumentversionsstyring, læst for, hvad der får dets nummereringssystem til at holde, frem for selve nummereringstrinnene.

1. Systemet starter, før nogen reviewer noget

   »Tildel indledende udkastversion 0.1« sker straks efter »Nyt dokument udarbejdet«, før »Send udkast til intern review« eller »Reviewer vurderer udkastet«: decimalsystemet er fastlagt ved række to, ikke opfundet midtvejs i den første »Kræves der ændringer?«-beslutning.

2. Omarbejdning tæller op, den omnummererer aldrig

   »Optæl den mindre version« og »Ret udkastet i forhold til kommentarerne« løkker tilbage til review på en gren, der hedder »Nyt review«, før »Indsend det endelige udkast til godkendelse« og »Godkender gennemgår det endelige udkast«: samme decimalregel holder gennem hver runde, så at citere udkast 0.3 stadig navngiver én præcis kopi.

3. Én beslutning trækker linjen mellem hoved- og mindre version

   »Godkendt til udstedelse?« er den eneste række med en vej til et helt tal: grenen Godkendt når frem til »Tildel hovedversion 1.0«, mens Afvist løkker tilbage til »Optæl den mindre version«: derefter fikserer »Opdater versionshistorikregistret«, »Publicer den godkendte version« og »Markér den forrige version som erstattet« den beslutning i en Fil-række, før nogen læser den nye kopi.

4. Et dokument, der ikke behøver en ændring, får stadig et mærke

   »Ønskes der ændring efter publicering?« bliver besvaret, selv når svaret er Nej: den gren ender ved »Aktuel version forbliver gældende«, et navngivet udfald frem for et fravær af aktivitet, mens Ja genåbner dokumentet ved »Genåbn dokumentet ved den næste version« i stedet for at starte en anden kopi ved siden af.

Sådan fungerer det

1. Frys nummereringssystemet, når rigtige dokumenter afhænger af det

   Behandl en ændring af selve systemet (at gå fra hele tal til semantisk versionering, eller at omdefinere, hvad et decimaltal betyder) som et projekt, ikke en justering: det ugyldiggør hver eksisterende krydshenvisning, oplæringsregistrering og tidligere auditcitat. Dukker en fejl op, så dokumentér undtagelsen fremadrettet i stedet for at omnummerere biblioteket.

2. Sæt version, dato og godkender ét fast sted på hver skabelon

   Vælg én position (sidehoved eller sidefod) og bag den ind i dokumentskabelonen, så hver forfatter bruger den uden at skulle beslutte det. Et versionsnummer i et filnavn eller i dokumentets egenskaber overlever ikke en udskrift, et skærmbillede eller en videresendt mail; ét trykt på siden gør.

3. Giv den »gældende« version en lås- eller checkout-konvention

   Beslut, hvem der må have den gældende version åben til redigering ad gangen, og hvordan en anden forfatter finder ud af, at nogen allerede har den: et checkout-flag i registret, en låst fil, eller én kanonisk, levende kopi, hvor kun én gemning kan vinde ad gangen. Uden dette er to godkendte redigeringer, der lander på samme version, ikke en hypotese.

4. Skriv reglen om hovedversion over for mindre version ned, før det første dokument har brug for den

   Angiv, i det samme dokument, der definerer nummereringssystemet, præcis hvad der udløser et hele-tal-trin: formel godkendelse alene, eller godkendelse plus en væsentlig omskrivning. Et team, der beslutter dette fra sag til sag, ender med to forskellige dokumenter, der begge hedder version 2.0.

5. Registrér hvert periodisk review, også dem, der ikke ændrer noget

   Giv reviewtrinnet en Beslutning-figur med en navngiven »ingen ændring«-udgang, der skriver en dateret post i registret, på samme måde som »Ønskes der ændring efter publicering?« når frem til »Aktuel version forbliver gældende« i stedet for blot ikke at gøre noget. En manglende post bør betyde, at reviewet ikke fandt sted, ikke at der ikke skete noget under det.

6. Lad én kanonisk, levende kopi fjerne låseproblemet helt

   Åbn dokumentet som et QueryChart-diagram i stedet for et sæt filer, der sendes rundt over mail, og der er kun én gældende version at redigere: hver gemning fanges automatisk som en ny post i ændringsloggen, så en checkout-konvention ikke har noget tilbage at håndhæve. Se /features/version-control.

Faldgruber du skal undgå

• At omnummerere for at rette en fejl

  At opdage, at systemet har en fejl to år inde, og omnummerere hele registret for at rette den, ødelægger hvert citat, der navngav de gamle numre: audits, oplæringsregistreringer, krydshenvisninger i andre dokumenter. Dokumentér i stedet undtagelsen fremadrettet; lev med fejlen i det, der allerede er udstedt.

• Versionsnummeret, der kun findes i filnavnet

  »Politik_v3_FINAL.docx« fortæller ingen noget, så snart den bliver printet, videresendt eller kopieret uden sit navn. Sæt version, dato og godkender inde i selve dokumentet, på samme faste sted hver gang.

• To »gældende« kopier redigeret samme eftermiddag

  En kopi på et fælles drev og en mailet kopi bliver begge redigeret, som om hver er masterversionen, og de to sæt ændringer overskriver lydløst hinanden eller forgrener sig. Ret dette med en checkout-konvention eller, bedre, én kanonisk, levende kopi: se /features/version-control.

• Et review, der ikke efterlader et spor, når intet ændrede sig

  Et dokument, der er revieweret og fundet stadig korrekt, uden at der er lavet en post noget sted, er umuligt at skelne et år senere fra et dokument, ingen overhovedet reviewede. Giv »ingen ændring nødvendig« sin egen daterede linje i registret, på samme måde som en beslutningsrækkes Nej-gren stadig når frem til et navngivet udfald.

Anvend disse praksisser på jeres eget dokument

Åbn eksemplet på dokumentversionsstyring som jeres eget diagram, og lad én kanonisk, levende kopi plus en automatisk ændringslog føre reglerne på denne side for jer.

Anvend disse praksisser på jeres eget dokument

Relaterede guides

• Versionsstyring kontra ændringsstyring: hvad er forskellen
• Sådan sporer du ændringer i en proces
• Sådan laver du et workflow til dokumentgodkendelse

Ofte stillede spørgsmål

Hvad er den enkelt største fejl at undgå i dokumentversionsstyring?

At behandle systemet som fast kun indtil, nogen finder en grund til at ændre det. At omnummerere et eksisterende bibliotek (selv for at rette en reel fejl) ødelægger hver krydshenvisning, oplæringsregistrering og auditcitat, der navngav de gamle numre, og den omkostning overstiger næsten altid omkostningen ved at leve med et ufuldkomment system. Ret problemer fremadrettet med en dokumenteret undtagelse, ikke ved at røre det, der allerede er udstedt.

Hvordan stopper jeg to personer i at redigere den samme »gældende« version samtidig?

Enten tilføj en eksplicit checkout-konvention (et flag i registret, der viser, hvem der har dokumentet åbent, så en anden forfatter ved, at de skal vente) eller fjern muligheden strukturelt ved at holde præcis én kanonisk, levende kopi i stedet for filer, der sendes rundt over mail eller et fælles drev. QueryChart gør det sidste: hvert dokument er ét levende diagram, hver gemning versioneres automatisk, og der er ingen anden kopi at forgrene. Se /features/version-control.

Hvad bør tælle som en hovedversion over for en mindre version?

Der findes ingen universel regel, hvilket er præcis grunden til, at det skal skrives ned, før det første dokument har brug for det, frem for vurderet fra sag til sag. En almindelig konvention binder hele-tal-trinnet, hovedversionen, til formel godkendelse alene (hver udkastrevision imellem, uanset hvor omfattende, forbliver et decimaltal), så »hvor stor var ændringen« aldrig skal diskuteres i det øjeblik, et versionsnummer tildeles.

Skal jeg logge et periodisk review, der ikke fandt nogen ændringer nødvendige?

Ja: et uregistreret review er umuligt at skelne fra et review, der aldrig fandt sted. Giv reviewtrinnet i jeres proces en Beslutning-figur med en navngiven udgang for »ingen ændring nødvendig«, der stadig skriver en dateret post i registret, på samme måde som en diagram-beslutningsrække registrerer hver gren, den tager, ikke kun dem, der fører et nyt sted hen.