Som jeg har sagt i mange eZines, skal du skrive ting.
Anden dag, en interviewer spurgte,
“Hvor mange sider du skrevet?”
“Et eller andet sted omkring 30.000 sider leveret, ikke herunder tusindvis af udkast til sider.”
“Du skal elske skriftligt!”
“Ikke rigtig.”
“Hvad så…?”
“Jeg ikke elsker skriver per se. Jeg elsker applikationer. Jeg elsker at resultaterne. Skriftligt, kan du oprette, lad os sige, det første niveau af virkelighed. Ved at skrive, kan du begynde at give immaterielle idéer form i det fysiske univers.
“Kan du forestille dig hvor mange mennesker opdaget hemmeligheden om brand og ikke skrive det ned? Nyheden skulle spredes ved “tribal viden!”
“Hvor mange gange hemmeligheden forsvinde fordi nogle brand-novice kvalt sig selv og familien? Hvor mange gange tror nogle gør-gooder forbudt brand på grund af dens farer?
“Det sandsynligvis tog evigheder at opdage at hemmelighed – igen og igen!
“I sidste ende, vel, nogen skrev hemmeligheden på hulen væg eller cocktail serviet…”
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
“Planlægger at skrive ikke skrive. Skitserer… forske… taler med folk om hvad du laver, intet af dette er at skrive. Skrivning er skriftligt.”–E.L. Doctorow
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Anyway, når du skriver ting, til sidst skal du opdatere den. (Jeg taler her om store, vigtige dokumenter – driftshåndbøger, tekniske manualer, brugerhåndbøger eller måske hemmeligheden bag brand og hvordan de kan kontrollere det.)
“Mike, hvad har du lært i årenes løb om at opretholde dokumentation?”
Nå, har store dokumentation projekter deres egen “livscyklus”. Denne cyklus strækker sig fra undfangelse til forældelse.
Når du udvikler store dokumenter, vil du typisk iterere gennem følgende:
1. krav.
Omfatter definition, opgørelse over mål, foreløbig analyse, funktionelle specifikationer og design begrænsninger.
2. design.
Omfatter disposition definition, format definition, osv.
3. gennemførelse.
Kræver, redigering, integration af forskellige komponenter, og korrektur.
4. test.
Omfatter kontrol og evaluering af kravene.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Men vent! Der er en anden fase jeg kalder dokumentation vedligeholdelse! Det begynder efter du levere dokumentationen til din bruger.
Du kan opdele dokumentation vedligeholdelse i følgende trin:
Fastlægge behovet for ændringer
Indgive anmodning om ændring
Gennemse foreslåede ændringer
Analysere krav
Godkend/afvis anmodning om ændring
Planlægge opgaver
Gennemgå og analysere Design
Skriv og Rediger
Test
Kontrollere mod standarder
Brugeraccept
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I disse trin skitserer jeg vedligeholdelse proces, som begynder, når en person har brug for en ændring og slutter, når brugeren accepterer ændringerne.
Som du kan forestille dig, ændre dokumentation er ofte komplekse og kan involvere mange mennesker.
Forestil dig f.eks., til opgave at opdatere dokumentation for applikationer i komplekse elektronik, luft-og rumfartsindustrien, lov, medicinsk, forsikring, osv. Eller hvad med ajourføring flight-prep manual for en kommerciel PASSAGERFLY?
Vedligeholdelse processen ovenfor synes lineær. Men igen, du vil gennemgå mange trin og iterativ sløjfer.
For eksempel,
Du skal måske præcisere, Change Request. Du kan kræve mere analyse af Design Reviews. Du skal muligvis omskrive din standarder revision. Brugerne kan ikke acceptere de resultater, osv.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Nogen, “Maintainer” skal gøre arbejdet.
Denne vedligeholder skal foretage ændringer inden for rammerne af den eksisterende dokumentation. Vedligeholdelse folk finde ofte dette den mest udfordrende problem.
Jo ældre den dokumentation, de mere udfordrende og tidskrævende vedligeholdelse indsats. Men normalt, vedligeholdelse tager du mindre tid end udvikling.
Din udviklingsindsats kan spænde over flere måneder. Du kan planlægge PERFECTIVE vedligeholdelse i cyklusser af en til seks måneder. Men du kan kræve korrigerende vedligeholdelse inden for timer.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Funktionelt, kan du opdele dokumentation vedligeholdelsesaktiviteter i tre kategorier:
PERFECTIVE,
ADAPTIVE, og
KORRIGERENDE.
Lad mig forklare…
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
PERFECTIVE VEDLIGEHOLDELSE
“Perfective vedligeholdelse” er, når du foretager ændringer, indsættelser, sletninger, ændringer, udvidelser og forbedringer til at forbedre forståelighed eller vedligeholde.
Du gør generelt Perfective vedligeholdelse, fordi du har nye eller ændrede behov, eller du kan være nødvendigt at finjustere dokumentationen.
Finjustere er en fremragende måde at introducere en ny forfatter til din dokumentation. Dette vil mindske din chance for alvorlige fejl senere.
Både fejl og succeser af dokumentationen kræver Perfective vedligeholdelse. Hvis dokumentationen virker godt, ønsker brugerne flere funktioner; dokumentationen virker dårligt, skal du reparere den.
Når du udfører Perfective vedligeholdelse på dårligt skriftlig dokumentation, kan du dramatisk reducere ressourcekrav ved at gøre din dokumentation mere vedligeholdelsesvenlig.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ADAPTIVE VEDLIGEHOLDELSE
“Adaptive vedligeholdelse” er når du tilpasse dokumentationen til ændringer i brugermiljø. Miljøændringer er normalt uden for kontrol af forfatteren og består hovedsagelig af ændringer:
Regler, love og forordninger, der påvirker dokumentationen. Typisk skal du hurtigt foretage disse ændringer at møde datoer oprettet af regler og forordninger.
Udstyr konfigurationer, såsom nye computere, nye terminaler, lokale printere mv. Normalt, ønsker du at drage fordel af forbedrede funktioner og/eller priser. Du udfører normalt denne vedligeholdelse efter en fastlagt tidsplan.
Dataformater, filstrukturer, osv. Du kan kræve omfattende vedligeholdelse, hvis disse varer var ikke korrekt designet og implementeret. Hvis du kan isolere ændringer til bestemte moduler, kan vedligeholdelse have mindre indflydelse. Hvis ikke, indsatsen kan være både langvarige og kostbare.
Systemsoftware, operativsystemer, compilere, utilities, osv. I disse tilfælde kan udfører du normalt vedligeholdelse på en tidsplan.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
KORRIGERENDE VEDLIGEHOLDELSE
“Korrigerende vedligeholdelse” er, når du skal lave fejl – nogle gange straks.
Generelt, vil du finde tre typer af fejl:
Designfejl.
Disse fejl omfatter ufuldstændig eller fejlbehæftet design på grund af urigtige, ufuldstændige eller uklare beskrivelser, eller når forfatteren ikke fuldt ud forstår brugerens behov.
Logik fejl.
Logik fejl opstår ofte, når brugeren instruktioner og/eller usædvanlige data kombinationer ikke er testet under udvikling eller vedligeholdelse. Disse fejl, normalt tilskrives designer eller tidligere vedligeholder, omfatter ugyldig antagelser, tests, instruktioner, eller konklusioner, eller defekt logik flow og ukorrekt gennemførelse.
Skrive fejl.
Forfatteren forårsager disse fejl. Disse fejl omfatter ukorrekt gennemførelse eller design logik eller forkert brug af særlige vilkår. Disse fejl kan være resultatet af uagtsomhed eller almindelig forsoemmelighed, men de er normalt den nemmeste at lave.
Bemærk: Mange ledere overveje vedligeholdelse til at ændre specifikationer og tilføjer nye funktioner.
Fascinerende ting, eh?
5. opfordring til handling
Som jeg har sagt før, er jeg en fanatiker om dokumentation af forretningsprocesser.
Finde ud af for dig selv! Du har intet at tabe.
Sammen, lad os dokumentere, hvad du vil, hvordan du ønsker det, og når du ønsker det. Vi vil diskutere forskellige kreative tilgange, før projektet starter.
Mike Hayden
Hovedstol/konsulent
Din partner i strømlining business.
