I 2018 var det ein del trygdemottakarar som ikkje fekk trekt skatt av dagpengane. Reglane sa at det skulle trekkjast 50 prosent av dagpengar som overskreid ei beløpsgrense på skattekortet, men dette skjedde ikkje. Feilen vart oppdaga, og 4000 dagpengemottakarar fekk høgare skattetrekk resten av året.

Dataprogrammet som les inn skattekortet, fekk ikkje med seg denne beløpsgrensa, og det førte til at programmet som rekna ut utbetaling og skatt, ikkje brukte noka grense. Kanskje var det berre ei programlinje, ein instruksjon, som mangla i innlesingsprogrammet. Men denne mangelen hadde konsekvensar for mange menneske.

Feil i programvare kostar oss milliardar kvart år. Ikkje berre Nav, men globale aktørar som Microsoft og Google og små lokale IT-verksemder lagar alle programvare som gjer feil, og vi brukarar må handtere dette som best vi kan. Nokre feil er berre irriterande, andre gjer at samfunnsavgjerande IT-tenester stoppar opp. Feil kan til og med føre til dødsfall.

At Nav kjem i søkjelyset når dei har IT-problem, er kanskje ikkje så rart. Dei forvaltar store delar av statsbudsjettet, tenestene deira vedkjem oss alle, og det er ein offentleg organisasjon med store krav til å vere open. Og media følgjer med når problem oppstår. Men Nav er ikkje verre enn andre når det gjeld kvalitet på IT-tenestene, snarare tvert imot.

Det er eit ønske at det offentlege Noreg skal gjerast så digitalt som mogleg. Stat og kommune ønskjer ikkje å lønne folk for å sitje og rekne ut dagpengar og skatt, eller vurdere om folk har rett på ulike former for trygd. Dette er rutinearbeid som må kunne handterast av programvare.

Men det er ikkje så enkelt å få det til. Datamaskiner er nemleg svært dårlege til å omsetje reglar og krav som kjem frå Stortinget og departementa, til fungerande rekneprosessar. Dette må systemutviklarar gjere. Og dei er heller ikkje alltid i stand til å gjere dette slik det er tenkt. Av og til fordi dei gjer feil, men oftast fordi det ikkje er klart kva som er ønskt.

På 90-talet og før det var det slik at dei som utvikla datasystem, følgde ein såkalla fossefallsprosess. Først samla dei inn ei mengd oppgåver dei ville at systemet skulle kunne gjere. Så analyserte dei desse for å omsetje dei til meir presise teknologiske krav. Vidare måtte dei lage ei overordna utforming av systemet, utføre sjølve programmeringa, teste systemet og til slutt overføre det til produksjon. IT-systema skulle fungere i mange år med dei same funksjonane.

Slik stabilitet er ikkje realistisk i dag, om han nokon gong har vore det. Etter mange erfaringar med feil i systemutviklinga og rask teknologisk utvikling vart det klart at systemutvikling må gå føre seg på ein annan måte. Krava til eit nytt system er ofte ganske uklare og vanskelege å tyde.

Systemeigarane endrar ofte på krava, eller dei kjem med nye krav når dei vert merksame på nye, spennande teknologiar. Systema vert ikkje lenger sette på som statiske einingar; dei må kunne endrast raskt når omverda ønskjer det.

Den tilnærminga som dominerer no, vert kalla smidig (eller agil) utvikling. Utviklarar og dei som eig IT-systemet, formulerer krava saman og prioriterer kva som skal gjerast innan ein kort tidshorisont på kanskje berre to veker eller ein månad. Utviklarane arbeider tett saman i mindre lag, kanskje seks–åtte personar, og dei deler arbeidsoppgåvene seg imellom.

Dei diskuterer heile tida korleis krav skal forståast og følgjast opp. Utviklarane som arbeider med dei same delane av eit system, sit saman, dei har korte daglege oppdateringsmøte og samarbeider når dei ser på spesielt vanskelege problem. Når dei er usikre på kva eit krav eigentleg inneber, har dei lett tilgang til ein ekspert som kan svare på spørsmål.

For å sikre kvaliteten på programmet lagar dei automatiske testar. Det vil seie program som sjekkar om IT-systemet gjer det ein ønskjer. Så fort dei har stadfesta at noko fungerer, vert det automatisk integrert i dei IT-systema som er i faktisk bruk, «i produksjon», som ein seier.

Scrum er ein populær prosjektstyringsteknikk som vektlegg smidige arbeidsmåtar. Namnet spelar på det intense samarbeidet internt i laget når motstandarane i ein rugbykamp skal prøve å vinne ballen i ein scrum-situasjon.

Nokre system er så store at ein har mange team som har ansvar for ulike delar av systemet, men ofte er det samanhengar mellom delsystema som må handterast. Det bør for eksempel ikkje vere slik at ei endring i ein del av systemet medfører feil i ein annan del av systemet. For å sikre dette er det viktig med kommunikasjon på tvers av dei ulike teama, ikkje berre innanfor kvart team.

Dei siste åra er det ikkje berre systemutviklarane som er med i slike samarbeidsprosessar. Også dei som skal drifte det ferdige systemet, må vere med. Dei skal jo mellom anna ha ansvaret for at maskinene som skal køyre prosessane, verkar, gjere køyringar til rett tid og halde databasane ved like. Ein brukar ofte termen DevOps (Development/Operations) for å få fram at IT-systema utviklar seg i eit samspel mellom utvikling av nye funksjonar og sikker drift.

I vår fekk Nav eit krav frå politikarane om at dei skulle sørgje for utbetaling av feriepengar til dei som hadde fått dagpengar i 2020. Det greidde dei, men dei hadde neppe fått det til med ein fossefallsmodell for systemutvikling. Smidige metodar gjorde at IT-organisasjonen kunne snu seg raskt, prioritere annleis og sørgje for at mange fekk dei feriepengane som politikarane hadde lova.

Utan systemutvikling stoppar Noreg.

Bjørnar Tessem og Lars Nyre