Ønskelisteeffekten

Hvorfor skjer det så ofte at de store løftene innen IT feiler, forsinkes og/eller sprenger sine rammer? Det å gjøre endringer på eksisterende løsninger i et vedlikeholdsløp er man gjerne mer forsiktig med - men det går jo som regel helt fint. Hvorfor er det mer utfordringer ved å lage noe nytt?

Her ønsker jeg å snakke litt om en av faktorene som påvirker dette, som jeg har kalt ‘Ønskelisteeffekten’.

Ønskelisteeffekt? Aldri hørt om…

Når man starter å utvikle et datasystem har man en arkitektur som er basert på tilgjengelig teknologi og arkitektenes og utviklerenes kunnskap og kompetanse. Sistnevnte er i større eller mindre grad basert på hva som er den kollektive oppfatning av hvordan man skal lage et system ut fra de gitte krav. Denne er tilgjengelig for oss via kanaler som utdanning, kurs, bøker, konferanser, osv. De som følger godt med og holder seg oppdatert gjennom disse kanalene lar seg ofte prege av dette når de skal starte med noe nytt, mens andre vil i større grad benytte seg av egen erfaring.

Alle disse tingene forandrer seg over tid. Fra man starter å utvikle et nytt system og til det har vært i bruk en stund, kan man ha erfart at arkitekturen ikke fungerte helt som man håpet. Man kan ha fått ny innsikt på et foredrag, lest en bok som ga en mer kompetanse osv. Noe av dette kan man ta i bruk mer eller mindre umiddelbart i systemet, men ofte er det vanskelig fordi omfanget blir for stort, pga. tidspress og/eller økonomiske forhold. Ofte er tilgang til ressurser for å endre på et system betraktelig lavere enn det man hadde da man lagde det, og frykten for å forstyrre daglig drift er stor.

I tillegg kommer det nye krav fra eksterne aktører, da verden og teknologien er i konstant forandring. Dette kan være nye lover eller forskrifter, nye bestemmelser i organisasjonen, nye eller oppdaterte standarder - listen er nesten uten ende. Igjen er det ikke gitt at dette er noe man kan introdusere i et datasystem som er i bruk.

Samlingen av nye behov og krav, både innenfra og utenfra, som man ikke kan eller vil implementere, samles opp i det man kan kalle en ønskeliste. Noen av disse klarer man å innføre innenfor de strenge rammene et «ferdig» system kan endres i, men som regel ender man opp med et sett med krav som aldri blir introdusert.

Alle interessenter i et system har en slik ønskeliste, fra hver enkel utvikler, tester, leder, arkitekt, bruker, osv. og opp til organisasjonen som helhet. Når, eller hvis, det kommer nye behov som utløser midler til å endre et system, eller lage et nytt, vil disse interessentene prøve å få med ting fra sine ønskelister med som krav i dette nye. Det blir litt som å åpne en demning, når nye bestillinger kommer.

Dette er ikke bra.

Gjør det noe da?

For de som styrer produktkøen i nye systemer eller større endringer, er en av de viktigste oppgavene å holde krav fra ønskelistene unna. Fordi for dem handler det om å holde risiko nede. Risikoen i å lage noe som er nytt er mye større enn å forandre på noe som allerede fungerer. Dersom en liten endring her skulle vise seg å være feilaktig, vet man med ganske stor sikkerhet hva som er kilden, og man har også mulighet til å gå tilbake til forrige versjon. Slipper man noe nytt eller en større endring, og avvik oppstår, kan ofte årsakssammenhengene være innfløkte og skjulte.

Dette er analogt til et menneske. Et fungerende og modent system kan sees på som en sterk og voksen person, som tåler å bære tyngden av nye krav. Et nytt system derimot er som en baby. De bør ikke bære på så mye. Man ber jo ikke en baby bære handleposene inn fra bilen f.eks.

Nevn ett eksempel!

Et eksempel på et krav som ligger på mange ønskelister er å bytte databaseprogramvaren . Mange er nok lei av å betale i dyre dommer for proprietære løsninger, og ønsker seg en av de med åpen kildekode og som i tillegg er ‘gratis’. Til å begynne med kan det virke som et fornuftig krav å ta tak i når man lager nye systemer. For systemer som allerede er laget for å gå mot en database, er det mye jobb med å skrive om kode og å flytte data. Det fører kanskje til en del nedetid, mens man bytter, og sikkert også en periode med feil og kanskje også dårligere ytelse. Ting man slipper unna med i et nytt system – eller gjør man det?

Dagen da man produksjonsetter første versjon av et nytt system, så er det veldig mange ting som kan gå galt. All funksjonalitet er uprøvd i den virkelige verden. Har man da også lyst til å gå mot en database man ikke har noe erfaring med i produksjon? Babyen som nå skal lære å gå, skal gjøre det på et helt nytt sted, hvor han ikke vet hvor han skal holde seg eller hvordan underlaget er.

Skulle noe gå fryktelig galt og det viser seg at man kommer opp i problemer som ikke lar seg løse kjapt, så har man ikke noe å rulle tilbake til, og man kan få nedetid som varer dager og uker og ikke minutter som er ‘worst case’ dersom man bare avlyser en oppgradering. I tillegg så vil man med nye systemer ofte starte med nesten tom database, og problemer som oppstår med en stor database blir ikke lagt merke til før uker, måneder eller år senere, og da vil det være for sent å snu på samme smertefrie måte som man kunne med et modent system.

Det dette eksempelet viser, og som går igjen for de fleste av den typen krav, er at nye systemer er mye mer sårbare. Det er ikke bare pga risiko for feil og nedetid, men også fordi de står i fare for ikke å bli tatt i bruk. De står ofte for noe nytt og uvant for organisasjonen, og erstatter gjerne noe de har brukt i lenger tid og er trygge med, enten det er papirbaserte manuelle rutiner, eller systemer de mener kan være verdt å skifte ut. Det er ikke alltid at alle deler av organisasjonen er like overbevist om at det nye systemet trengs eller er verdt pengene. Problemer og utsettelser i starten kan i ytterste konsekvens føre til at hele systemet blir lagt i skuffen.

Hva med smidig?

Minimering av omfang samt små og hyppige utrullinger er mantraet i smidig utvikling. Dette står bra i stil med det vi prøver å formidle her. Krav fra ønskelistene vil jo øke omfang, og gjøre at man ikke kan rulle ut nye delversjoner så ofte som man ønsker. Dersom man likevel ønsker å legge til krav fra ønskelisten i et nytt system, vil smidig fremgangsmåte gjøre at dette ikke skaper de risikoer og evt problemer som nevnt da man isolerer endringen og minimerer omfanget av den.

Så ikke la dine oversette ønsker fra fortiden begrave de ferske systemene i porteføljen deres, da de først og fremst trenger en kjærlig og varsom hånd så de kan vokse til de systemene som takler de.