Prøv smerte-risiko vurderinger for vedlikeholdsarbeid!

Få begreper skaper like mye debatt som “teknisk gjeld”. Det er ett av flere typer vedlikeholdsarbeid vi må gjøre, men jeg tror mye av dramaet rundt begrepet bunner i noe ganske enkelt: Vi snakker forbi hverandre. Det må vi gjøre noe med! Vi vil ikke nå våre toppmål om vi ikke lykkes med riktig prioritering av vedlikeholdsarbeid.

Utviklere argumenterer gjerne med tekniske termer som ikke gir mening for folk uten teknologibakgrunn. Og det er et problem, fordi nettopp disse folkene — produktledere, designere, forretningsutviklere osv. — er sentrale i produktutvikling. Når de ikke forstår argumentene som presenteres, blir det vanskelig å prioritere. Det handler om å løfte diskusjonen fra et teknisk nivå, til et verdinivå: Hvilken effekt har innsatsen vår?

I denne artikkelen foreslår jeg et enkelt verktøy som gjør at vi kan snakke om vedlikeholdsarbeid på en måte som gir mening for alle.

Kontinuerlig vedlikeholdsarbeid er nødvendig

Jeg tror vi alle kan være enige om at produkter må vedlikeholdes. Utfordringen er hvor mye vi skal gjøre av det, og hvordan vi prioriterer det opp mot alt annet. Det finnes ingen fasit på hvor mye kapasitet et produktteam bør dedikere til vedlikeholdsarbeid. I noen tilfeller kan 20% være riktig, i andre tilfeller kan det kreve hele teamet over lang tid. I min erfaring er realiteten ofte at mengden vedlikeholdsarbeid som gjøres er ganske vilkårlig. Jeg mener vi trenger bedre måter å styre og prioritere det på.

Et produktteam er ansvarlig for å skape verdi, og følgelig mener jeg det er helt på sin plass at produktteamet rettferdiggjør tiden de bruker på vedlikeholdsarbeid: Vi skal ha myndiggjorte team, ikke full hjemme-alene-fest. Som med innovasjonsarbeid, ønsker vi et fokus på effekten man oppnår, ikke oppgavene som ferdigstilles. Denne effekten må kommuniseres på en måte som er forståelig på tvers av fagfelt og interessenter: Vi må kunne diskutere og vurdere ut fra de samme premissene.

Smerte-risiko vurderinger er et godt grunnlag for å diskutere vedlikeholdsoppgaver

I starten av 2024 tok et knippe kollegaer og jeg frem et rammeverk for vurderinger av vedlikeholdsarbeid. Vi landet på et format med to akser:

1. Risiko for produktet. Dette kan eksempelvis være importerte biblioteker med kjente sårbarheter som bør oppgraderes, kjernefunksjonalitet med bugs eller manuelle rutiner som resulterer i nedetid i produksjon.
2. Smerte for produktteamet i det daglige. Dette kan eksempelvis være rotete kodebaser, innviklet arkitektur, eller spagettikode.

Etter å ha benyttet dette rammeverket over en lengre periode, er våre erfaringer at det fungerer svært godt: Vi har enda ikke sett en vedlikeholdsoppgave som scorer lavt i smerte-risiko rammeverket, men som likevel er viktig. Det betyr ikke at dette rammeverket er en fasit som dekker absolutt alle tilfeller, men det er et godt utgangspunkt.

Et eksempel med en håndfull oppgaver viser rammeverket i praksis

La oss ta et eksempel med et produktteam som har identifisert fem vedlikeholdsoppgaver. På oppfordring fra produktlederen gjør tech lead en vurdering av oppgavene sammen med utviklerne, hvor smerte og risiko vurderes. De kommer frem til følgende:

1. Teamets deploy-rutiner er ikke automatisert. Utrulling til produksjon skjer manuelt. Oppgaven vurderes som høy smerte og høy risiko: Det er krevende å utføre og lett å gjøre feil når man skal rulle ut ny kode, som betyr at utviklerne vegrer seg for å gjøre det i det hele tatt. I stedet for å rulle ut koden løpende samler man heller opp til større releaser, hvor hele teamet bidrar i produksjonssettingen. Videre har det høy risiko for produktet, fordi produksjonssettinger ofte fører til nedetid, og mangel på kontinuerlig leveranse gjør at mengden endringer man legger ut er stor. Dette fører til mange bugs i produksjon.
2. En av kodefilene har svært mange kodelinjer. Oppgaven vurderes som lav smerte og medium risiko: Utviklerne har god kontroll på fila selv om den er stor, grunnet lang historikk. Oppgaven vurderes likevel som medium risiko, fordi man anerkjenner at teammedlemmer vil byttes ut over tid. Fremtidige medlemmer vil fort vegre seg for å gjøre endringer i denne fila.
3. Arkitekturen i en av applikasjonene er fullstendig spagetti. Endringer som skal gjøres knekker tester på mange forskjellige steder, og det er vanskelig å forstå hvordan flyten henger sammen. Oppgaven vurderes som høy smerte og høy risiko: Det er krevende og vondt å gjøre endringer, og endringer som gjøres medfører gjerne bugs i produksjon. Utvikling av nye funksjoner er både kostbart og risikofylt, og utviklerne trives svært dårlig med å jobbe med denne applikasjonen.
4. Re-naming av klassenavn og variabler i hele kodebasen for å følge den nye kodestandarden. Oppgaven vurderes som lav smerte og lav risiko: Det er en nice-to-have som kan endres over tid uten at det påvirker hverken utviklerhverdagen eller produktet nevneverdig.
5. Oppgradering av frontendrammeverk. Oppgaven vurderes som lav smerte og lav risiko: Det er ingen kjente sårbarheter, og det er ingenting i teamets backlog som tilsier at man trenger den nye funksjonaliteten. Utviklerne ønsker å vente til neste versjon og vurdere en oppgradering da.

Etter smerte-risiko vurderingene legger teamet inn oppgavene i koordinatsystemet:

Ved å legge til omfangsvurderinger ser man helheten i vedlikeholdsarbeidet

Smerte-risiko vurderingene gir oss muligheten til å diskutere på felles grunnlag, samt utfordre på nytten av de foreslåtte oppgavene. Når vi skal prioritere, må vi også kunne si noe om omfanget. En oppgave med lav smerte og lav risiko kan være bitteliten å gjennomføre. Slike lavthengende frukter er ofte verdt å plukke. Tilsvarende kan en oppgave med høy smerte og høy risiko være såpass omfattende at det blir en større, strategisk prioritering å gå løs på den.

I sum gir disse vurderingene oss en god kost-nytte forståelse. Det gjør at vi kan prioritere vedlikehold opp mot innovasjon, fordi vi vurderer oppgavene etter de samme premissene.

Tilbake til eksempelet vårt, så gjør teknologene en omfangsvurdering av de fem vedlikeholdsoppgavene. De benytter seg av T-shirt estimation. Teamet sitter igjen med følgende helhetsbilde av vedlikeholdsarbeidet sitt:

Å lykkes med produktutvikling over tid krever at man finner den rette balansen mellom vedlikeholdsarbeid og innovasjonsarbeid

Begrepet teknisk gjeld inneholder ordet gjeld av en grunn: Ved å ikke adressere problemet, vokser mengden arbeid som kreves over tid. Det er naivt å tro at man kan lukke øynene og ikke gjøre noe vedlikeholdsarbeid. Likevel er min erfaring at det ofte nedprioriteres. Jeg tror det delvis henger sammen med hvor vanskelig det er å kommunisere rundt vedlikeholdsarbeid.

Å gjøre for lite vedlikeholdsarbeid fører til at gjelden hoper seg opp. Det finnes mange eksempler på moderningsprogrammer som stammer fra en enorm mengde teknisk gjeld. De blir kjempedyre, og setter føringer for alt virksomheten foretar seg. Noen ganger er det riktige valget å pause innovasjonsarbeidet for å ta unna vedlikeholdsarbeid.

Å gjøre for mye vedlikeholdsarbeid fører til en reduksjon i verdiskaping: Kapasiteten som kunne vært benyttet til innovasjonsarbeid går i stedet med til “gold plating” av de tekniske løsningene. Noen ganger er det riktige valget å prioritere innovasjonsarbeid, selv om det øker den tekniske gjelden.

Jeg opplever stadig at disse ytterpunktene settes opp mot hverandre i en falsk dikotomi: Utviklerne peker på at man risikerer en gigantjobb i fremtiden, mens beslutningstakerne bekymrer seg for at man kaster bort verdifull tid som kunne vært brukt til å innovere. Det finnes en middelvei, men den forutsetter at vi forstår hverandre.

Mitt håp er at smerte-risiko rammeverket skaper denne felles forståelsen, og at vi finner den riktige balansegangen.