Hvad gør jeg nu? Planlægning af designændringer

Jeg befinder mig ofte i situationer, hvor jeg taler med folk om deres systemdesign, planer og arkitekturer. Og mange gange sker denne samtale for sent, og designene er enten allerede implementerede eller delvist implementerede. Dette kan være meget frustrerende, hvis det igangværende design er vurderet til ikke at være ideelt til situationen.

Jeg forstår den frustration, der opstår i en sådan situation, men det er noget, vi i IT meget regelmæssigt må stå ansigt til ansigt med, og at håndtere denne reaktion konstruktivt er en vigtig IT-færdighed. Vi skal blive mestre i denne situation, både teknisk og følelsesmæssigt. Vi bør ikke lammes af det – det er en naturlig situation, som enhver IT-professionel vil opleve regelmæssigt. Det bør ikke være nedslående eller lammende, men det er meget forståeligt, at det kan føles sådan.

En vigtig årsag til, at vi oplever dette så ofte, er, at IT er et enormt felt med et stort antal variabler, der skal tages i betragtning i enhver situation. Det er også et stærkt kreativt felt, hvor der kan være adskillige, levedygtige tilgange til et givet problem. At der overhovedet er én enkelt "bedste" løsning er sjældent tilfældet. Normalt er der mange konkurrerende muligheder. Nogle gange er disse meget tæt beslægtede, andre gange er disse muligheder drastisk forskellige, hvilket gør dem meget svære at sammenligne meningsfuldt.

En anden vigtig årsag er, at faktorer ændrer sig. Det kan skyldes, at nye teknikker eller oplysninger dukker op, nye produkter udgives, produkter opdateres, priser ændrer sig, eller forretningsmæssige behov ændrer sig tæt på eller endda under beslutnings- og designprocesserne. Denne forandringstakt er noget, vi som IT-professionelle ikke kan håbe på nogensinde at kontrollere. Det er noget, vi må acceptere og håndtere så godt, vi kan.

Noget andet, jeg ofte ser blive overset, er, at en løsning, der var ideel, da den blev valgt, muligvis ikke er ideel, hvis den samme beslutning skulle træffes i dag. Dette udgør på ingen måde en mangel ved det oprindelige design, men jeg har set mange mennesker reagere, som om det gjorde. Det mest almindelige scenarie, jeg støder på, hvor jeg ser folk udvise denne adfærd, er modviljen mod at bruge RAID 5 i moderne lagerdesign, hvor RAID 6 og RAID 10 er de populære alternativer med god grund. Men denne RAID 5-modvilje, der er udbredt siden omkring 2009, har ikke altid eksisteret, og fra midten af 1990'erne og næsten til slutningen af 2000'erne var RAID 5 ikke kun levedygtigt – det var meget ofte den bedste løsning for de givne forretnings- og tekniske behov (stigningen i modvilje mod det var for det meste gradvis, ikke pludselig). Mange mennesker ser dog RAID 5 som forståeligt nok en dårlig mulighed i dag, men anvender denne nye modvilje på systemer, der blev designet og implementeret for lang tid siden, sommetider tæt på to årtier siden. Det giver ingen mening og er rent en følelsesmæssig reaktion. At RAID 5 var det bedste valg for et scenarie i 2002, indebærer på ingen måde, at det stadig vil være det bedste valg i 2015. Men ligeledes nedgør eller annullerer RAID 5 at være et dårligt valg i 2015 for et scenarie på ingen måde det faktum, at det meget ofte var et godt valg for flere år siden.

Jeg er mange gange blevet spurgt, hvad man skal gøre, når der er truffet mindre end ideelle designbeslutninger. "Hvad gør jeg nu?"

At lære, hvad man skal gøre, når perfektion ikke længere er en mulighed (som om den nogensinde virkelig var det – al IT handler om kompromiser), er en meget vigtig færdighed. Det første, vi skal tage fat på, er de følelsesmæssige problemer, da disse vil underminere alt andet. Vi må gøre vores bedste for at træde et skridt tilbage, acceptere situationen og handle rationelt. Det sidste, vi ønsker at gøre, er at tage en ikke-ideel situation og gøre tingene værre ved at forsøge at baglæns retfærdiggøre dårlige beslutninger eller gå i panik.

At acceptere, at intet design er perfekt, at der ikke er nogen måde at altid få tingene helt rigtigt, og at det at håndtere dette blot er en del af at arbejde med IT, er det første skridt. Træd et skridt tilbage, træk vejret dybt. Det er ikke så slemt. Dette er ikke en unik situation. Enhver IT-professionel, der arbejder med design, oplever dette hele tiden. Du bør forsøge dit bedste for at træffe de bedst mulige beslutninger, men du må også acceptere, at det sjældent kan gøres – ingen har adgang til nok ressourcer til virkelig at kunne gøre det. Vi arbejder med, hvad vi har. Så her er vi. Hvad er det næste?

Det næste er at vurdere situationen. Hvor er vi nu? I mange tilfælde er implementeringen færdig, og der er ikke mere at gøre. Situationen er ikke ideel, men er den dårlig? Meget ofte er den største fejl, jeg ser folk stå over for med et allerede implementeret design, at det er for dyrt – typisk er "bedre" løsninger ikke bedre, fordi de er hurtigere eller mere pålidelige, men er bedre, fordi de er billigere, nemmere eller hurtigere at have implementeret. Det er en uheldig situation, men næppe en lammende en. Uanset hvilken tid eller penge der blev brugt, må det have været et acceptabelt beløb på det tidspunkt og må have været godkendt. Det bedste, vi kan gøre lige nu, er at lære af beslutningsprocessen og forsøge at undgå overforbrug i fremtiden. Det betyder ikke, at den eksisterende løsning ikke vil fungere eller endda ikke vil fungere fremragende. Det er blot, at det måske ikke har været et perfekt valg givet de forretningsmæssige behov, primært finansielle, involveret.

Der er situationer, hvor et design, der er blevet implementeret, ikke tilstrækkeligt opfylder de angivne forretningsmæssige krav. Dette er heldigvis mindre almindeligt, efter min erfaring, da det er en meget vanskeligere situation. I dette tilfælde er vi nødt til at foretage nogle ændringer for at opfylde vores forretningsmæssige behov. Dette kan vise sig at være dyrt eller komplekst. Men tingene er måske ikke så slemme, som de ser ud. Reaktioner på dette er ofte vildledende, og situationen kan ofte reddes.

Det første skridt, når vi er i en position, hvor vi har implementeret en løsning, der ikke opfylder forretningsmæssige behov, er at revurdere de forretningsmæssige behov. Dette er ikke for at antyde, at vi bør forfuske behovene for at massere dem til at være, hvad vores system er i stand til at opfylde – overhovedet ikke. Men det er et godt tidspunkt at gå tilbage og se, om de oprindeligt angivne behov virkelig er gyldige, eller om de simpelthen ikke er blevet tilstrækkeligt verificeret, eller endnu mere sandsynligt, at gå og se, om de forretningsmæssige behov har ændret sig i den tid, implementeringen fandt sted. Det kan være, at den implementerede løsning faktisk opfylder de faktiske forretningsmæssige behov, selv hvis de oprindeligt var forkert angivet, eller fordi behovene har ændret sig over tid. Eller det kan være, at forretningsmæssige behov har ændret sig så dramatisk, at selv perfekt planlægning oprindeligt ville have haft utilstrækkelig kapacitet i forhold til de eksisterende behov, og det faktum, at den implementerede løsning ikke præsterer som forventet, er af mindre betydning. Jeg har været meget overrasket over, hvor ofte denne verificering af forretningsmæssige behov har vendt en løsning, der mentes at være utilstrækkelig, til en "overkill"-løsning, der faktisk kostede mere end nødvendigt, simpelthen fordi ingen satte spørgsmålstegn ved overdrevne angivelser af forretningsmæssige behov, eller ingen satte spørgsmålstegn ved den finansielle værdi af visse teknologiinvesteringer.

Det andet skridt er at skabe en ny teknologisk baseline. Dette er et meget vigtigt skridt for at hjælpe med at forhindre IT i at falde i fælden med sunk cost-fejlslutningen. Det er ekstremt almindeligt for enhver – dette er ikke unikt for IT på nogen måde – at se på den tid og de penge, der er brugt på et projekt, og antage, at det at fortsætte ad den oprindelige vej, uanset hvor tåbelig den er, er den rigtige vej, fordi der allerede er brugt så mange ressourcer på den vej. Men dette giver selvfølgelig ingen mening – hvordan du nåede din nuværende tilstand er irrelevant. Det relevante er at vurdere de aktuelle behov for afdelingen og virksomheden og tage bestik af de aktuelt tilgængelige løsninger, teknologier og ressourcer. Givet den nuværende tilstand kan den bedste vej frem bestemmes. Enhver overvejelse af den indsats, der er brugt på at nå den nuværende tilstand, er kun vildledende.

Et godt eksempel på sunk cost-fejlslutningen er i skakspillet. Med hvert træk er det vigtigt igen at vurdere alle tilgængelige træk, risici og strategier, fordi hvilke træk der er brugt til at nå den nuværende tilstand ikke har nogen betydning for, hvilke træk der giver mening fremover. Hvis verdens bedste skakspiller eller en fantastisk computerskak-algoritme skulle bringes ind midt i spillet, ville de ikke have brug for nogen viden om, hvordan den nuværende tilstand er opstået – de ville simpelthen vurdere den nuværende tilstand og skabe en strategi baseret på den.

Dette er det samme, som vi bør opføre os i IT. Vores nuværende tilstand er vores nuværende tilstand. Det har ingen betydning for strategisk planlægning, hvad der udspillede sig for at bringe os til den tilstand. Vi bekymrer os kun om disse beslutninger og omkostninger, når vi gennemfører en post mortem-proces for at fastslå, hvor beslutningstagningen måske har fejlet, for at lære af det. At lære om os selv og vores processer er meget vigtigt. Men det er en meget anden opgave end at lave strategisk planlægning for det aktuelle initiativ.

Det uheldige her er, at vi skal begynde vores planlægningsprocesser igen, men denne gang med, antager vi, mere at arbejde med. Men dette kan ikke undgås. I de værste tilfælde er budgetter ikke længere tilgængelige, og der er ingen ressourcer til at rette det fejlbehæftede design og opnå de nødvendige forretningsmål. Kompromiser er sommetider nødvendige. At klare sig med, hvad vi har, er sommetider det bedste, vi kan gøre. Men i langt de fleste tilfælde ser det ud til, at en kombination af yderligere budget eller kreativ genanvendelse af eksisterende produkter kan være tilstrækkelig til at afhjælpe situationen.

Når vi har nået en tilstand, hvor vi har adresseret vores mangler – hvad enten det blot er ved at acceptere, at vi har overbrugt, underleveret, eller har tilpasset os for at opfylde behov – har vi mulighed for at gå tilbage og undersøge vores beslutningsprocesser. Det er ved at gøre dette, at vi håber at vokse som individer og, hvis overhovedet muligt, på et organisatorisk niveau at lære af vores fejl, eller afgøre om der overhovedet var fejl. Hvert firma og hvert individ begår fejl. Det, der adskiller os, er evnen til at lære af dem og undgå de samme fejl i fremtiden. Vækst kommer primært fra at opleve smerte på denne måde, og selv om det ofte er ubehageligt at stå over for, er det her, vi har den bedste mulighed for at skabe reel, varig værdi. Udskyd ikke eller spring denne mulighed for gennemgang over, hvad enten det er en hård, personlig gennemgang, du selv foretager, eller en formel, organisatorisk gennemgang, der gennemføres af folk uddannet til det, eller noget derimellem. Jo hurtigere beslutningsprocesserne evalueres, jo friskere vil hukommelsen være, og jo hurtigere kan kursuskorrektionen træde i kraft.

Det endelige skridt, vi kan tage, er at begynde beslutningsprocessen om at designe en erstatning for den nuværende implementering så hurtigt som muligt, når gennemgangen af beslutningsprocessen er afsluttet. Dette betyder ikke nødvendigvis, at vi bør have til hensigt at bruge penge eller ændre vores design i den nærmeste fremtid. Overhovedet ikke. Men ved at være ekstremt proaktive i designbeslutninger kan vi forsøge at undgå tidligere problemer ved at give os selv yderligere tid til planlægning, mere tid til kravindsamling og dokumentation, bedre indsigt i ændringer i krav over tid ved regelmæssigt at genbesøge disse krav for at se, om de forbliver stabile eller ændrer sig, mere mulighed for at opnå ledelsens og kollegernes accept og investering i beslutningen og bedre forståelse af problemdomænet, så vi er bedre rustet til at ændre det tiltænkte design eller vide, hvornår vi skal skrotte det og starte forfra, inden vi implementerer det næste gang. Det kunne også potentielt give os en bedre chance for at kodificere organisatorisk viden, der kunne videreføres til en efterfølger, hvis du selv ikke er i en position til at træffe beslutninger eller implementere, når den næste cyklus kommer.

Med gode, rationelle processer og en god forståelse af de skridt, der skal tages i et tilfælde af mindre end ideelt systemdesign eller implementering, kan vi komme os over fejltrin og ikke kun, i de fleste tilfælde, komme os over dem på kort sigt, men vi kan isolere organisationen fra de samme fejl i fremtiden.