Hva gjør jeg nå? Planlegging for designendringer

Svært ofte befinner jeg meg i diskusjoner med folk om systemdesign, planer og arkitekturer. Og mange ganger skjer disse diskusjonene for sent – designene er enten allerede implementert eller delvis implementert. Dette kan være svært frustrerende dersom designet som er under utvikling har blitt vurdert som ikke ideelt for situasjonen.

Jeg forstår følelsen av frustrasjon som oppstår i en slik situasjon, men det er noe vi i IT må møte svært regelmessig, og å håndtere denne reaksjonen konstruktivt er en viktig IT-ferdighet. Vi må bli mestere i denne situasjonen både teknisk og følelsesmessig. Vi bør ikke la oss lamme av det – det er en naturlig situasjon som alle IT-fagfolk vil oppleve jevnlig. Det bør ikke være nedslående eller lammende, men det er svært forståelig at det kan føles slik.

En viktig grunn til at vi opplever dette så ofte er at IT er et enormt fagfelt med et stort antall variabler som må tas hensyn til i enhver situasjon. Det er også et svært kreativt fagfelt der det kan finnes mange levedyktige tilnærminger til ethvert gitt problem. At det i det hele tatt finnes ett enkelt «best» alternativ er sjelden sant. Normalt finnes det mange konkurrerende alternativer. Noen ganger er disse svært nært beslektet, andre ganger er alternativene dramatisk forskjellige noe som gjør dem svært vanskelige å sammenligne på en meningsfull måte.

En annen viktig årsak er at faktorer endrer seg. Dette kan skyldes at nye teknikker eller informasjon dukker opp, nye produkter lanseres, produkter oppdateres, priser endres eller forretningsbehov endres nær eller til og med under beslutnings- og designprosessene. Denne endringstakten er ikke noe vi som IT-fagfolk kan håpe å kontrollere. Det er noe vi må akseptere og håndtere så godt vi kan.

Noe annet jeg ofte ser bli oversett er at en løsning som var ideell da den ble valgt, kanskje ikke er ideell dersom den samme beslutningen ble tatt i dag. Dette utgjør på ingen måte en mangel ved det opprinnelige designet, likevel har jeg sett mange mennesker reagere som om det gjorde det. Det vanligste scenarioet jeg støter på der jeg ser folk oppvise denne atferden, er motstanden mot bruk av RAID 5 i moderne lagringsdesign – RAID 6 og RAID 10 er de populære alternativene av gode grunner. Men denne motstanden mot RAID 5, som er vanlig siden rundt 2009, eksisterte ikke alltid, og fra midten av 1990-tallet til nærmere slutten av 2000-tallet var RAID 5 ikke bare levedyktig – det var svært ofte den beste løsningen for de gitte forretnings- og tekniske behovene (økningen i motstand mot det var for det meste gradvis, ikke plutselig). Likevel ser mange mennesker RAID 5 som forståelig nok et dårlig alternativ i dag, og overfører denne nye motstanden til systemer designet og implementert for lenge siden, noen ganger nær to tiår tilbake. Dette gir ingen mening og er en rent følelsesmessig reaksjon. At RAID 5 var det beste valget for et scenario i 2002 innebærer på ingen måte at det fortsatt vil være det beste valget i 2015. Men på samme måte – at RAID 5 er et dårlig valg i 2015 for et scenario, nedvurderer eller ugyldiggjør på ingen måte det faktum at det svært ofte var et godt valg for noen år siden.

Jeg har mange ganger blitt spurt hva man bør gjøre når mindre enn ideelle designbeslutninger er tatt. «Hva gjør jeg nå?»

Å lære hva man bør gjøre når perfeksjon ikke lenger er et alternativ (som om det noen gang virkelig var det – all IT handler om kompromisser) er en svært viktig ferdighet. Det første vi må ta tak i er de følelsesmessige problemene, da disse vil undergrave alt annet. Vi må gjøre vårt beste for å ta et skritt tilbake, akseptere situasjonen og handle rasjonelt. Det siste vi ønsker er å ta en ikke-ideell situasjon og gjøre ting verre ved å forsøke å rettferdiggjøre dårlige beslutninger i ettertid eller få panikk.

Å akseptere at ingen design er perfekt, at det ikke er mulig å alltid gjøre alt helt riktig, og at det å håndtere dette bare er en del av å jobbe med IT, er det første steget. Ta et skritt tilbake, pust dypt. Det er ikke så ille. Dette er ikke en unik situasjon. Alle IT-fagfolk som driver med design går gjennom dette hele tiden. Du bør prøve ditt beste for å ta de beste beslutningene som er mulige, men du må også akseptere at det sjelden kan gjøres – ingen har tilgang til nok ressurser til virkelig å kunne gjøre det. Vi arbeider med det vi har. Så her er vi. Hva er neste steg?

Neste steg er å vurdere situasjonen. Hvor er vi nå? I mange tilfeller er implementeringen ferdig og det er ingenting mer å gjøre. Situasjonen er ikke ideell, men er den dårlig? Svært ofte er den største feilen jeg ser folk gjøre overfor et allerede implementert design, at det er for kostbart – typisk er «bedre» løsninger ikke bedre fordi de er raskere eller mer pålitelige, men er bedre fordi de er billigere, enklere eller raskere å ha implementert. Det er en uheldig situasjon, men knapt en lammende en. Uansett hvilken tid eller penger som ble brukt, må det ha vært et akseptabelt beløp på det tidspunktet og må ha blitt godkjent. Det beste vi kan gjøre akkurat nå er å lære av beslutningsprosessen og forsøke å unngå overforbruket i fremtiden. Det betyr ikke at den eksisterende løsningen ikke vil fungere eller til og med ikke fungere forbløffende godt. Det er rett og slett slik at det kanskje ikke var det perfekte valget gitt forretningsbehovene, primært finansielle, som var involvert.

Det finnes situasjoner der et design som har blitt implementert ikke tilstrekkelig oppfyller de angitte forretningskravene. Dette er heldigvis sjeldnere, etter min erfaring, da det er en mye vanskeligere situasjon. I dette tilfellet må vi gjøre noen endringer for å oppfylle våre forretningsbehov. Dette kan vise seg å være dyrt eller komplekst. Men ting er kanskje ikke så ille som de ser ut. Reaksjoner på dette er ofte misvisende og situasjonen kan ofte reddes.

Det første steget når vi befinner oss i en posisjon der vi har implementert en løsning som ikke oppfyller forretningsbehovene, er å revurdere forretningsbehovene. Dette er ikke for å antyde at vi bør jukse med behovene for å tilpasse dem til det systemet vårt er i stand til å oppfylle – slett ikke. Men det er et godt tidspunkt å gå tilbake og se om de opprinnelig angitte behovene virkelig er gyldige, eller om de rett og slett ikke ble tilstrekkelig undersøkt, eller – enda mer sannsynlig – gå og se om forretningsbehovene har endret seg i løpet av den tiden implementeringen fant sted. Det kan hende at den implementerte løsningen faktisk oppfyller de faktiske forretningsbehovene, selv om de opprinnelig ble feilangitt eller fordi behovene har endret seg over tid. Eller det kan hende at forretningsbehovene har endret seg så dramatisk at selv perfekt planlegging opprinnelig ville ha kommet til kort for de eksisterende behovene, og at det faktum at den implementerte løsningen ikke fungerer som forventet er av mindre betydning. Jeg har blitt svært overrasket over hvor ofte denne bekreftelsen av forretningsbehov har gjort en løsning som ble ansett som utilstrekkelig til en «overkill»-løsning som faktisk kostet mer enn nødvendig, rett og slett fordi ingen tilbakeviste overstatements av forretningsbehov eller ingen stilte spørsmål ved den finansielle verdien av visse teknologiinvesteringer.

Det andre steget er å opprette en ny teknologibaseline. Dette er et svært viktig skritt for å hindre IT i å falle i fellen med sunk cost-feiltanken. Det er svært vanlig for alle – dette er ikke unikt for IT på noen måte – å se på tid og penger brukt på et prosjekt og anta at det å fortsette langs den opprinnelige stien, uansett hvor tåpelig det er, er veien å gå fordi så mange ressurser allerede er brukt på den stien. Men dette gir selvfølgelig ingen mening – hvordan du kom til din nåværende tilstand er irrelevant. Det som er relevant er å vurdere de nåværende behovene til avdelingen og selskapet og ta stock av de tilgjengelige løsningene, teknologiene og ressursene. Gitt den nåværende tilstanden kan den beste veien fremover bestemmes. Enhver hensyntagen til den innsatsen som ble brukt for å komme til den nåværende tilstanden er kun misvisende.

Et godt eksempel på sunk cost-feiltanken er i sjakk. Med hvert trekk er det viktig å vurdere alle tilgjengelige trekk, risikoer og strategier på nytt fordi hvilke trekk som ble brukt for å komme til den nåværende tilstanden ikke har noen betydning for hvilke trekk som gir mening fremover. Hvis verdens beste sjakkspiller eller en fantastisk datamaskin-sjakkalgoritme skulle settes inn midt i spillet, ville de ikke trenge noen kunnskap om hvordan den nåværende tilstanden hadde oppstått – de ville rett og slett vurdere den nåværende tilstanden og lage en strategi basert på den.

Dette er det samme som vi bør gjøre i IT. Vår nåværende tilstand er vår nåværende tilstand. Det spiller ingen rolle for strategisk planlegging hva som skjedde for å bringe oss til den tilstanden. Vi bryr oss bare om disse beslutningene og kostnadene når vi gjennomfører en post mortem-prosess for å bestemme hvor beslutningstakingen kan ha sviktet, for å lære av det. Å lære om oss selv og våre prosesser er svært viktig. Men det er en svært annerledes oppgave enn å drive strategisk planlegging for det aktuelle initiativet.

Det uheldige her er at vi må begynne planleggingsprosessene på nytt, men denne gangen med, antar vi, mer å jobbe med. Men dette kan ikke unngås. I de verste tilfellene er budsjetter ikke lenger tilgjengelige og det er ingen ressurser til å fikse det mangelfulle designet og oppnå de nødvendige forretningsmålene. Kompromisser er noen ganger nødvendige. Å klare seg med det vi har er noen ganger det beste vi kan gjøre. Men i det aller fleste tilfeller ser det ut til at en kombinasjon av ekstra budsjett eller kreativ gjenbruk av eksisterende produkter kan være tilstrekkelig til å avhjelpe situasjonen.

Når vi har nådd en tilstand der vi har adressert våre mangler – enten ved å akseptere at vi har overforbrukt, underlevert eller har tilpasset oss for å møte behovene – har vi en mulighet til å gå tilbake og undersøke våre beslutningsprosesser. Det er ved å gjøre dette at vi håper å vokse som enkeltpersoner og, hvis i det hele tatt mulig, på organisasjonsnivå å lære av våre feil, eller bestemme om det i det hele tatt var feil. Hvert selskap og hvert enkeltmenneske gjør feil. Det som skiller oss er evnen til å lære av dem og unngå de samme feilene i fremtiden. Vekst kommer primært fra å oppleve smerte på denne måten, og selv om det ofte er ubehagelig å møte, er det her vi har den beste muligheten til å skape virkelig, varig verdi. Ikke skyv unna eller hopp over denne muligheten for gjennomgang – enten det er en streng, personlig gjennomgang du gjør selv, en formell organisasjonsgjennomgang utført av folk trent til å gjøre det, eller noe imellom. Jo raskere beslutningsprosessene evalueres, jo ferskere vil minnet være og jo raskere kan kurskorreksjonen tre i kraft.

Det siste steget vi kan gjøre er å starte beslutningsprosessen for å designe en erstatning for den nåværende implementeringen så snart som mulig, når gjennomgangen av beslutningsprosessen er fullført. Dette betyr ikke nødvendigvis at vi bør ha til hensikt å bruke penger eller endre design i nær fremtid. Slett ikke. Men ved å være ekstremt proaktive i designbeslutninger kan vi forsøke å unngå problemene fra fortiden ved å gi oss selv ekstra tid til planlegging, mer tid til kravinnsamling og dokumentasjon, bedre innsikt i endringer i krav over tid ved regelmessig å gå tilbake til disse kravene for å se om de er stabile eller om de endrer seg, mer mulighet til å oppnå ledelsens og kollegers støtte og engasjement i beslutningen, og bedre forståelse av problemdomenet slik at vi er bedre rustet til å endre det planlagte designet eller vite når vi skal skrote det og begynne på nytt før vi implementerer det neste gang. Det kan også potensielt gi oss en bedre sjanse til å kodifisere organisasjonskunnskap som kan overføres til en etterfølger, dersom du selv ikke er i posisjonen til å ta beslutninger eller implementere når neste syklus kommer.

Med gode, rasjonelle prosesser og god forståelse av de stegene som må tas i tilfelle av mindre enn ideelt systemdesign eller implementering, kan vi komme oss over feiltrinn og ikke bare, i de fleste tilfeller, komme oss fra dem på kort sikt, men vi kan beskytte organisasjonen mot de samme feilene i fremtiden.