Krisehåndtering af IT-projekter, en 10-punkts checkliste

Det der kendetegner mange af de projekter vi får ind fra kunder, starter med et eksisterende projekt der er gået skævt. At projektet er gået skævt kan skyldes misforståelser mellem den tidligere leverandør og kunden om, hvordan projektet skulle være, uhensigtsmæssig eller dårlig teknisk implementering eller bare dårlige rutiner.

Om problemerne skyldes det ene eller det andet kan være svært at gennemskue uden en nærmere analyse, men med nedenstående 10-punkts-gennemgang er det måske nemmere at få overblik over, hvor eventuelle problemer kan ligge.

1. Ansvarsfordeling og proces

Første checkpunkt er ikke af teknisk karaktér - det handler om roller og ansvar for de forskellige dele af projektet og om, hvordan man samarbejder. Punktet kan relativt nemt afklares ved at identificere, hvordan forskellige typer af opgaver håndteres: Er det defineret hvem, der har ansvar for hvad, hvem der er kontaktperson for hvilke områder, hvem der kan afløse hvem, hvad er aftalt responstid, hvordan kvalificeres et krav som opfyldt og så videre. Er alle disse organisatoriske aspekter afdækket og dokumenteret, så det er klart for alle, hvordan nye features og eventuelle fejl håndteres på den nemmest mulige måde.

2. Miljøer, kildekodekontrol og backups

For at håndtere et stort system skal der som minimum være opsat et testmiljø, hvor nye features og rettelser kan testes og godkendes, inden de idriftsættes. Større systemer bør også have et stagingmiljø (en kopi af produktionsmiljøet med replikerede data). Udover dette bør der være fuld mulighed for at kunne gå tilbage i tiden (versionsstyring), således at hvis der sker uforudsete ting, kan man altid gå tilbage til tidligere versioner. Der bør også udarbejdes en backupprocedure, sådan at tidligere data altid kan findes frem, hvis der skulle opstå en uforudset fejl, eller hvis systemet bliver kompromitteret. Man bør tage en stikprøvetest af udrulning af backup for at sikre, at den er intakt, og at det i praksis kan lade sig gøre at rulle tilbage, hvis det skulle blive nødvendigt.

3. Fejlhåndtering og monitorering

Selv det mest gennemprøvede og gennemtestede system kan have fejl. Der et rigtig godt system, der adskiller et godt og et rigtig godt system fra hinanden, er blandt andet, hvordan fejl håndteres, når de opstår. Det første, der skal ske ved en fejl, er at brugeren skal have en forklaring (f.eks. ’Systemet er midlertidigt nede. Forsøg venligst igen om fem minutter’), og samtidig skal administrator have en e-mail /SMS-notifikation om den opståede fejl med detaljeret information, for at baggrunden kan undersøges nærmere og fejlen kan udbedres med det samme. Fejlhåndtering kan typisk pakkes ind af Microsoft Enterprise Library, som er et af de gængse standardframeworks til det formål. Du bør altså sikre, at dit system har en veldokumenteret model for fejlhåndtering og monitorering, hvis du ikke allerede har det?

4. Sporbarhed

Et uheld kan ske, men hvis man ikke ved, hvordan det er opstået, kan det være svært at udbedre og vil derfor med overvejende sandsynlighed gentage sig. Ved at fokusere på at udvikle sporbare systemer undgår man, at problemer gentager sig. Det betyder først og fremmest, at der skal være log på alle steder, hvor der kan opstå fejl (f.eks. e-mailafsendelse, IIS pool, og så videre). På den måde kan man undersøge i stedet for at gætte. En anden metode til at øge sporbarheden er at sørge for, at de rigtige notifikationssystemer er sat op. Sker der en fejl i produktionen, er det vigtigt, at den bliver opdaget hurtigt som en del af fejlhåndteringen (se næste punkt).
På den organisatoriske side bør man have sporbarhed under deployments og så videre ved at ændringer dokumenteres og registreres (med dato, tid, person), sådan at hvis der sker en fejl, kan der sættes et navn på.

5. Transaktionsstyring

Transaktionsstyring sikrer, at selv hvis noget går galt, så går det ikke rigtig galt. Banksystemer er et godt eksempel på systemer, der er pakket ind i transaktioner. Går en handling galt (f.eks. udbetaling af penge), skal pengene ikke trækkes fra kontoen. Alle systemer har interne afhængigheder, og går noget galt, bør man afbryde forløbet og rulle tilbage, sådan at en systemfejl ikke får utilsigtede konsekvenser, der kan være svære at forklare og håndtere. Som systemansvarlig bør man sikre sig, at alle centrale funktionsområder er dækket af en korrekt transaktionslogik, sådan at eventuelle fejl ikke forårsager andre utilsigtede og relaterede fejl.

6. Dokumentation

En grundig dokumentation sikrer at programmører, systemansvarlige og andre kan komme og gå, uden at der opstår store problemer. Dokumentation sikrer desuden, at vigtig viden ikke går tabt (bliver glemt) undervejs, men også at procedurer (f.eks. angående release og deployment) overholdes, og at der ikke sker menneskelige fejl på grund af et for lavt informationsniveau. Dokumentation er en disciplin for sig og bør ikke undervurderes, hvis man vil have sikkerhed for sit system og uafhængighed for leverandøren.

7. Læring

Alle kan lave fejl, men hvis man ikke lærer af sine fejl, begås de igen og igen. Derfor er gentagne, retrospektive analyser af forløb meget væsentlige at tage fat på. Sker der uhensigtsmæssigheder, bør de diskuteres, og der bør udarbejdes et løsningsforslag, som gennemføres, hvorefter dette igen evalueres og om muligt forbedres. Ved at have en organisation, der hele tiden lærer, kan man også hele tiden forbedre produktkvaliteten og sikre bedre kvalitet i udviklingen.

8. Brug af standard systemer

Kan noget købes, er det ofte billigere end at bygge det selv. Problemer opstår ofte ved, at hjemmelavede funktioner overtager områder, som etablerede CMS-, økonomi-, mass mail,- og CRM-systemer kunne have håndteret bedre. Hvis der findes standarder på markedet indenfor et bestemt område af dit system, kan det ofte være en fordel at integrere til standardsystemet i stedet for at genopfinde den dybe tallerken. For at afklare dette kan man spørge, om der er noget i ens system, der med fordel kunne erstattes af et standardiseret system?

9. Best practice

Alle større opgaver består af en række delopgaver, der findes gode og dårlige løsninger på. Inden for de fleste implementeringsopgaver findes, hvad man kalder ’best practice’-metoder og procedurer. Hvis man følger disse kendte mønstre gennem hele projektet, minimeres risikoen for fejl, da der anvendes kendte og gennemprøvede modeller, hvor de fleste overraskelser er fjernet. Er dit projekt ikke bygget på best practice bør det ses igennem, og eventuelle ’Georg Gearløs’ løsninger bør erstattes af best practice inden for området.

10. Test

Lad ikke brugerne være testere uden at de er klar over det. Gode test starter med gode, interne procedurer tæt på udviklingen - eksempelvis browser,- og devicekompatibilitetstests. Systemer bør også være dækket ind af både automatiserede tests (unit test, valideringstest, stresstest, og så videre), og ved stabilisering bør regressionstest baseret på realistiske brugsscenarier anvendes. Kun når alt dette forarbejde er på plads, bør rigtige brugere inddrages – og naturligvis under kontrollerede omstændigheder.

Opsummering