Hr. Bachs fornemmelse for antagelser

Livet må leves forfra, men kan kun forstås bagfra
Søren Kierkegaard

Introduktion

Kære Far.

Jeg syntes altid at du var en ukuelig pessimist. Med alderen, og visdommen?, er det dog gået op for mig, at du var optimist. Dit mantra var/er: Murphys Lov: “Alt der kan gå galt, går galt” Den finder jeg, nu, alt, alt for optimistisk, så jeg vil derfor introducere: Murphys Udvidede Lov. “Alt det der kan gå galt, går galt; selv det der ikke kan gå galt”.

Antagelser… (Har du set liget?)

Antagelser kan være skæbnesvangre, bare tænk på filmen “Kapring i høj fart” hvor terroristerne antager at de har gjort det af med Steven Seagal. Det overlades til den interesserede læser at finde det præcise citat. The Internet Movie Database (http://www.imdb.com) kunne være et sted at begynde.

I mange projekter er antagelser en nødvendighed, og man kan have sine tvivl om hvorvidt der ville være gennemført eet eneste (IT) projekt i verdenshistorien, hvis der ikke blev foretaget antagelser. Antagelser er dog ikke skabt lige, og jeg vil I det følgende opremse nogle antagelser jeg anser for dødssynder. Dødssynder er der som bekendt 6 af, men jeg er landet på 7 “dødsantagelser”. Den intellektuelle forklaring på tallet 7, kunne være, at det ikke altid er givet at man får en hviledag, når man har valgt at arbejde med IT, men det er nu et tilfælde.

Når jeg kalder det for “dødsantagelser” betyder det dog, præcis som det er tilfældet med dødssynderne, at de ikke bare kan afvises religiøst, men at de kræver stillingtagen.

Antagelse 1: Vi har jo allerede et system vi kender, det skal bare migreres 1-1

Der sker ofte – altid? – det, at der fra det tidspunkt analyse fasen i et projekt starter til det tidspunkt hvor udviklingen påbegyndes, har det system der skal migreres ændret sig markant. Da der i projektet er blevet lovet en 1-1 migrering, skal den ændrede funktionalitet naturligvis også implementeres.

Antagelse 2: Processerne er velkendte

Dette er ikke altid tilfældet. Hvis der findes mange eksisterende manuelle processer, skal disse analyseres og beskrives, og allerede automatiserede processer skal ofte genudvikles.

Antagelse 3: Vi når jeres deadline

I alle projekter er der, overraskelse, deadlines! Deadlines kan være dikteret af ting som marketings kampagner, tid til marked, nye produkt introduktioner etc. Hvis antagelse 1 så ikke holder og kravene bliver voldsomt udvidet, er der kun et at gøre, at ændre indholdet – kaldet scope – da deadlinen er ultimativ. Det såkaldte rescoping.

Antagelse 4: Prototypen var jo god nok

Det er jo helt normalt at der bliver udviklet en prototype, eller et proof of concept. Men hvad er der bag? PowerPoint slides eller noget færdig kode. Det viser sig som regel at det er ren facade. Og så et mysterium, hvorfor sker det så ofte at prototypen slet ikke ligner det færdige produkt, hvis prototypen blev accepteret af kunden?

Antagelse 5: Vi har de rigtige mennesker

CVer er nogle gange ikke det papir værd de er trykt på, og når man sammensætter projekt teams, sker det ofte at der ikke bliver sat ret megen tid af til at lave egentlige job interviews.

Antagelse 6: Vi kan samarbejde

Det er også en svær een, og da de fleste projekter i dag er så komplekse at der kræves samarbejde mellem flere projekt grupper, kan der også opstå konflikter mellem de enkelte teams.

Antagelse 7: Vi har teknologien

Vi anvender teknologi dagligt, og verden bliver mere og mere kompliceret hverdag. og vi er ofte nødt til at tage nogle ikke helt modne teknologier i brug. Hvis man vælger at anvende “det nyeste” skal man være forberedt på at det sjældent er “det bedste” (endnu), og være forberedt på alvorlige børnesygdomme, misforståelser og stejle indlæringskurver.

Anbefaling 1: Samtale fremmer forståelsen

Udover systemer der holdes på 0 Kelvin – det absolutte nulpunkt – er få systemer statiske. Der sker ofte – altid? – det, at der fra det tidspunkt analyse fasen i et projekt starter til det tidspunkt hvor udviklingen påbegyndes, har det system der skal migreres ændret sig markant. Da der i projektet er blevet lovet en 1-1 migrering, skal den ændrede funktionalitet naturligvis også implementeres. En måde at undgå dette på kan være at leve efter mobil selskabet Mobilixs gamle motto “Samtale fremmer forståelsen”.

Anbefaling 2: Styr på krav og Å“ndringer? .

Hvis der er tale om ældre systemer, der har været i drift i årevis, er der som regel mange ændringer der kunne have været dokumenteret, hvis man er så heldig at de overhovedet er blevet dokumenteret, udover som en overskrift i en ændringsforespørgsel – en Change Request. Det er vigtigere end nogensinde at der foreligger opdateret system dokumentation, og at en kravs- og ændrings processerne er underlagt voldsomt styring.

Anbefaling 3: Operationen lykkedes men patienten døde

Når lægen siger, at der er gode og dårlige nyheder, hvilken vil man så høre først? Mange IT projekter er ikke underlagt realistiske deadlines – og at Å“ndre dette er meget svært. Men en forudsÅ“tning er at der findes gode, og fastfrosne, specifikationer.

Anbefaling 4: Ren facade?

Den udviklede prototype er som regel ren facade, som da Tintin i “Tintin i Sovjet” kigger bag facaden på den flotte fabrik, og opdager at det bare er en teater kulisse. Desværre kan denne facade dÅ“kke over yderst kompliceret funktionalitet, som kunden forventer bliver implementeret. Dette er nok forklaringen på et af universets store mysterier. Hvorfor sker det så ofte, at prototypen slet ikke ligner det færdige produkt. Prøv derfor at udvikle en så simpel prototype som mulig, undgå kodning. Skærmbilleder og PowerPoint præsentationer er bedre, da de så heller ikke dikterer bestemte teknologi valg

Anbefaling 5: CV, det er da en musiker

Det kunne være en god idé at bruge længere tid på at vælge projekt medlemmerne.

Anbefaling 6: Jeg ved det! Du vil lege kujon!

Da de fleste projekter i dag er så komplekse at der kræves samarbejde mellem flere projekt grupper, kan der også opstå konflikter mellem de enkelte teams. I grelle tilfælde kan det ende med at man “leger kujon”, som det f.eks. ses i filmene “Vildt Blod” og “Den Sidste Actionhelt”; den der drejer fra først er en kujon – eller på engelsk kylling. Det er vigtigt at der eksisterer en central projekt ledelse, også teknisk, der går på tværs af de forskellige projekt teams og som har reel magt. På den måde kan man bedre samarbejde.

Anbefaling 7: Livgivende kys

For at citere en BEA Danmarks dygtige konsulenter, Jan Schouboe, som vi har haft fornøjelsen af at høre til et af ProDatas seminarer. Så er udvikling af business applikationer ikke teknologi. “SR-71” spionflyet og – min egen aktuelle tilføjelse: “SpaceShipOne” – er derimod teknologi. Når det er sagt, så er moderne IT arkitektur så kompliceret, at det næsten ligner teknologi.

Så KISS (Keep It Simple Stupid) princippet bør anvendes. Undgå teknologi for teknologiens skyld. Vær konservativ, men informeret om hvad der duer og hvad der ikke duer. Vig ikke, religiøst, bort fra nye teknologier, men valget af nye teknologier skal, dokumenteret, resultere i konkrete besparelser og/eller andre forbedringer – performance, stabilitet, hastighed, popularitet, udbredelse, høj grad af standardisering er vigtige parametre. Valget af teknologi skal under ingen omstændigheder – og det gælder også fravalget – være baseret på religiøs fundamentalisme.

Descoping (hug en hæl og klip en tå)

Når rescoping så bliver til descoping – hug en hæl og klip en tå – og når der også begynder at ryge så vitale legemsdele med, at det bliver svært for kunden at se, at der bliver leveret noget som helst; så går der forhåbentlig ikke længe før projektet bliver lukket.

IT projekternes Tacoma bro (det svinger)

Alle bygnings ingeniører har billederne af Tacoma broen, der svinger sig selv i stykker, indprentet i baghovedet hver gang de designer en bro.

Findes der tilsvarende IT projekter vi, som arbejder professionelt med IT, alle burde have i baghovedet?

Kategorien “IT projekternes Tacoma bro”; Og de nominerede er:

• Politisk dikteret lancering: AMANDA – dårlige krav?
• Katastrofal lukning: DORA – for teknologisk og så flyttede teknologien sig!
• Modig lukning: KommuneDatas lønsystem fra 80erne – umuligt?
• Korrekt lukning (men ikke et IT projekt): NASAs Mars projekt fra 90erne – for dyrt og for teknologisk!

The impossible takes just a little longer, that’s all, Commander.
Commissioner Simmonds til Commander Koenig, Månebase Alpha, Sæson 1, Episode 5 Earthbound