Førstehjælp ved katastrofer

(c) Ditlev V. Petersen 1997
Tidligere bragt i PROSA-bladet under pseudonymet Mikkel Klamper

Inden for edb-faget kommer man engang imellem ud for, at et eller andet pludselig udvikler sig til den rene katastrofe. Det kan være en simpel liste, der udnævner pæne borgere til at være forhærdede forbrydere, det kan være et lille engangsprogram, der viser sig at opdatere cpr-registret, så den samme kvinde bliver mor til 4618 børn, et simpelt registreringsprogram, som skal bruges, kan slet ikke køre. Eller værst af alt: en bruger opdager, at det system de har købt, slet ikke er det, de havde forestillet sig.
I sådanne tilfælde er det altafgørende at kunne edbfagets førstehjælp uden ad. Det kan være et spørgsmål om ens fremtid i firmaet! Her skal vi se på trinvis førstehælp i katastrofer.
Trinvis førstehjælp under edb-katastrofer er fuldstændig homolog til trinvis førstehjælp under mindre alvorlige katastrofer (harmonikasammenstød, togulykker osv.). For det tilfælde, at nogle af læserne ikke kan huske trinene fra førstehjælpskurserne, repeteres de her:
1. stands ulykken
2. yd livreddende førstehjælp
3. tilkald den nødvendige hjælp
4. giv almindelig førstehjælp.

Stands ulykken

Katastrofer kan altid udvikle sig til det værre. At begynde på at afbøde virkningerne inden man har har fået erkendt årsagen og standset den, er håbløst. Det er som at ville øse en læk båd læns uden at stoppe lækken. Ingen programmer må rettes, ingen bruger må beroliges, ingen data må reddes - før ulykken er standset.
   Dette trin er uden diskussion det vigtigste i enhver katastrofe- og krisestyring. Her må der ikke sjuskes, her kan tingene ikke jages igennem. Det er vigtigt, at arbejdet bliver gjort meget grundigt. På den anden side kan det være vigtigt, at kunne reagere meget hurtigt.
   Når katastrofen har vist sig, kan man være ganske sikker på, at adskillige chefer vil styrte forvildet rundt og brøle noget i retning af: "Hvem er den idiot, der ...". Her skal man kunne svare hurtigt.
   Essensen i hele punktet er, at finde den skyldige! At det ikke er en selv, er givet, men hvem er det så? Hvis en udvikler netop er rejst fra firmaet, er vedkommende en god kandidat. Det er dog normalt en forudsætning, at vedkommende på en eller anden måde har haft noget med sagen at gøre. Til nød kan man klare sig med "- jamen N.N. har selv hjulpet mig med lige netop dette her".
   Ellers må man tage sin tilflugt til folk, der er på ferie eller på anden måde ikke (eller kun dårligt) kan svare for sig. Evt. kan en upopulær person agere syndebuk.

Yd livreddende førstehjælp

Hvis "liv" drejer det sig om at redde? Ja enhver er jo sig selv nærmest, og selv om det skulle lykkes at udpege en anden som den skyldige, foreligger der altid en risiko for, at man selv får snavs på sit gode rygte. Og det kan i værste fald få konsekvenser for ens fremtidige "liv" i virksomheden.
   Derfor drejer det sig nu om at påvise, at man absolut intet vidste, om at tingene var ved at udvikle sig i en uheldig retning. Eller bedre endnu, at man i god tid har advaret mod netop denne situation.
   Som forebyggende foranstaltning kan det derfor være hensigstmæssigt med jævne mellemrum at aflevere memo'er (der garanteret ikke bliver læst), som indeholder kryptiske og vage advarsler mod noget. Husk at tage kopi. Nu, i nødens stund, kan man hive et sådan memo frem og påvise, at man allerede for to år siden advarede mod noget i den retning.
   Ellers vil man normalt skynde sig at skrive et memo eller lignende, hvor man beklager sig højlydt over, at man er blevet forholdt vigtige oplysninger om projektets udvikling og derfor ikke har haft nogen mulighed for at erkende, hvor galt det stod til. Da man under ingen omstændigheder får alt at vide, er dette ret enkelt at udføre.

Tilkald den nødvendige hjælp

Nu kan man begynde at tage sig af brugerne. Få fat i en juniorprogrammør eller to, og sæt dem i gang med at bikse en lappeløsning sammen i en fart. Man bør ikke selv påtage sig dette arbejde, da det ofte ender galt, og man skal jo helst ikke selv have snavs på fingrene.
I mellemtiden kan man jo ringe til brugerne og berolige dem med henvisninger til års- eller kvartalsskifte, til problemer med telenettet eller alt muligt andet. Og selvfølgelig bliver det bedre i næste uge.

Giv almindelig førstehjælp

Til sidst kan man begynde at skitsere en varig løsning i form af et ændret design, eller hvad der nu skal til. Man bør under dette arbejde ikke sætte sit eget lys under en skæppe. Ej heller skal man undlade at kritisere det arbejde, som den skyldige har udført.
Dernæst bør der udfærdiges en fejlrapport (eller hvad man nu kalder det). Fejlrapporten placeres i en bunke, der hvis det overhovedet er muligt, bør flyttes over i en anden gruppe, hvor den kan hvile trygt. Selve fejlrapporten bør ikke indeholde henvisninger til en selv, da det måske kan medføre, at den vender tilbage. Få i stedet en af juniorprogrammørerne til at skrive fejlrapporten. De gennemskuer det ikke, men betragter det som en tillidserklæring.

Slutning

Pladsen forhindrer mig i en mere grundig behandling af dette emne. Men den intelligente læser vil let kunne bygge videre på disse ideer.