Produkttankegangen som en vej til billigere og bedre offentlig software?
Mange offentlige softwareløsninger kæmper med forsinkelser, høje omkostninger, og dårlig brugervenlighed. Forklaringen skal findes i en forældet tilgang til udbud, som umuliggør anvendelsen af de metoder og tilgange, som moderne softwareudvikling bygger på. De bedste softwareudviklingsorganisationer udnytter de hurtige softwareudviklingscykler til netop at leverer værdi hurtigt, begrænse omkostningerne, og sikrer begejstrede brugere. Læs mere om de tre uundgåelige Uer her.
For at komme i udbud med de meget store og omkostningsfulde IT-projekter, vælger offentlige institutioner og styrelser, at udvikle meget detaljerede kravspecifikationer, som de store IT-leverandører kan byde ind på. Kravspecifikationerne er oftest produceret som skrivebordsopgaver - uden kontakt til brugerne, med begrænset forståelse for de teknologiske muligheder, og typisk også uden anvendelse af prototyper og brugertest. Og i værste fald kørt gennem en af de store sprogmodeller, så kravspecifikationen ser tip, top ”professionelt” ud. Dette er præcist det omvendte af, hvad god softwareudviklingspraksis dikterer.
Problemet gøres værre af at leverandørerne er organiseret til at servicere udbudsmodellen. Det betyder, at de relativt sikkert kan byde lavt på projekterne i forvisning om, at ændringerne til projekterne kan takseres højt. Ændringer, som i produktmodellen er en positiv indikation af, at vi tester og leverer software til rigtige bruger, bliver i udbudsmodellen til en negativ, omkostningsfuld praksis.
Et udbud vendt på hovedet - kan vi lære noget fra de bedste?
Fra et softwareproduktperspektiv skal der være styr på de tre uundgåelige Uer for at offentlige softwareløsninger også kan anvende erfaringerne fra de bedste softwareprojekter. Vi må stille følgende spørgsmål:
- Hvordan skaber vi Udsyn i en offentlige kontekst? Hvordan skaber vi enighed om målgruppen, tidshorisonten, og den overordnede tilgang til softwareløsningen?
- Hvordan giver vi tid og ressourcer til udforskningsarbejdet og udgår kravspecifikationen, som vi kender fra vandfaldsprojekterne?
- Hvordan organiserer vi udviklingen, så vi kan få korte udviklingscykler, optimerer feedback fra brugerne og iterativt bruge data til at forbedre løsningen?
Udsyn i en offentlig kontekst
Behovet for radikal innovation i en offentlige sammenhæng er typisk mindre end i den private sektor. I udgangspunktet er softwareudvikling derfor mindre risikofyldt i en offentlige kontekst sammenlignet med en privat. Udfordringen for offentlige myndigheder er typisk adgangen til dygtige softwarekyndige strateger, som kan udvikle et udsyn, som giver mening for den givne myndighed. Ikke desto mindre er det vigtigt, at der er enighed i den enkelte styrelse op gennem det politiske lag, hvilke problemer man ønsker at løse for hvilke brugere af software. En sådan konsensus gør det muligt at lave en produktstrategi for den pågældende styrelse med et klar fokus på følgende spørgsmål:
a) Hvilke kunde- og brugergrupper henvender løsning sig til?
b) Hvad er den økonomiske model? Nye indtægter, effektiviseringer, bedre bæredygtighed?
c) Hvad er tidshorisonten for løsningen? Vedvarende eller tidsbegrænset?
d) Hvordan skal løsningen tage højde for afhængighed af lovgivning, bestemte tekniske platforme, eller eksisterende løsninger?
Svarene på disse spørgsmål kombineret med domæne-specifikke overvejelser skal forankres hos beslutningstagerne, alt fra styrelser over kommuner og regioner til politikerne, inden vi kan starte udforskningsarbejdet.
Udforskning minimerer risiko og skaber samarbejdet
Udforskningsarbejdet skippes oftest i offentlige udviklingsprojekter. Kravene genereres ved skrivebordet fremfor gennem prototype og kundetests. Dette er en fundamental fejl, som koster det offentlige dyrt i både tid og penge.
I stedet for at udbyde softwareudvikling baseret på færdige kravspecifikationer, bør offentlige organisationer udbyde udforskningsarbejde. Her ligger svaret på, hvordan vi kan vende udbudsmodellen på hovedet og skabe de forudsætninger, der skal til for at anvende moderne produktudviklingsmetoder i det offentlige.
Det offentlige kan med stor fordel anvende principper fra Set-Based Concurrent Engineering (SBCE), som Toyota udviklede for at optimere deres produktudvikling. SBCE betyder, at man i stedet for at vælge én løsning tidligt i processen, arbejder med flere løsningsforslag parallelt og gradvist eliminerer de mindre attraktive muligheder baseret på læring og data.
Konkret kunne dette organiseres som 3-4 parallelle udforskningsprojekter, hvor forskellige leverandør-team får til opgave at f.eks.:
- Undersøge brugerbehovene gennem interviews og workshops
- Teste forskellige tekniske tilgange med små tekniske prototyper
- Validere antagelser om integration med eller refaktorering af eksisterende systemer
- Afprøve forskellige brugergrænseflader og arbejdsgange
Denne tilgang giver flere fordele: a) risikominimering - ved at have flere løsninger i spil samtidig, reduceres risikoen for at ende med en løsning, der ikke virker eller ikke møder brugernes behov, b) bedre leverandørvalg - udforskningsfasen giver den offentlige instans mulighed for at vurdere leverandørernes evne til faktisk problemløsning fremfor blot deres evne til at skrive tilbud, c) øget læring og innovation -Parallelle tilgange skaber konkurrence om de bedste ideer og løsninger, og d) stærkere partnerskaber - Udforskningsfasen skaber grundlag for et mere ligeværdigt samarbejde mellem den offentlige organisation og leverandørerne, baseret på fælles forståelse af problemet og løsningsretningen.
Efter udforskningsfasen kan den mest lovende tilgang udvælges til videre udvikling - eller elementer fra flere tilgange kan kombineres til en endnu bedre løsning.
Korte udviklingscykler i produktudvikling
Når udforskningsfasen har identificeret den rigtige retning og de rigtige udviklingspartnere, skal selve udviklingen organiseres med korte iterationer og konstant brugerfeedback. Teknisk set skal der være styr på DevOps og arkitekturen, men også på tilgangen til produktledelse.
For at muliggøre korte udviklingscykler må det offentlige også ændre sine finansierings- og kontraktformer. I stedet for at basere finansieringen på estimeret arbejde på baggrund af kravspecifikationen, skal fokus være på antallet af produktgrupper, som i grove træk er påkrævet for at levere den overordnede løsning. Arbejdet organiseres derefter med klare mål og ønskede resultater, hvormed produktcheferne kan måle på om resultaterne opnås. Fokus flytter fra kravene til værdien af den software, som bliver leveret til rigtige brugere.
En vej frem: Fra projekter til produkter
Den fundamentale ændring, som det offentlige skal foretage, er at skifte fra at tænke i projekter til at tænke i produkter. Et projekt har en start og en slutning. Et produkt har en mission og udvikler sig kontinuerligt for bedre at opfylde denne mission.
Når det offentlige tænker i produkter, kommer der:
- mere fokus på Udsyn og Udforskning: Fordi vi ved, at den store tunge kravspecifikation vil koste dyrt over tid, investeres der mere i at forstå problemet og teste løsninger tidligt og kontinuerligt. Vi flytter investeringerne frem i værdikæden og bruger flere penge på at tænke langsomt for at handle hurtigt.
- hurtigere og mere brugervenlig Udvikling: Fordi der er etableret strukturer til kontinuerlig læring og forbedring, kan systemerne udvikle sig i takt med ændrede behov. Software kommer ud og lever i brugernes hænder efter uger fremfor år.
- Bedre bæredygtighed: Både økonomisk og teknisk, fordi ændringerne af softwareløsningen er tænkt ind i selve designet, og udviklingen er sat op til kontinuerligt at øge værdien af løsningen for brugeren og borgeren.
Overgangen til produkttænkning kræver mod til at ændre etablerede processer og strukturer. Men gevinsten er betydelig: Det offentlige kan få adgang til de samme fordele, som de bedste private softwareorganisationer allerede høster - hurtigere levering, lavere omkostninger og begejstrede brugere.
Den vej frem, som denne blog skitserer, er ikke teoretisk. Det er baseret på veldokumenterede principper fra produktledelse og agil udvikling, som allerede har vist deres værdi i praksis. Nu handler det om at have modet til at anvende dem i en offentlig kontekst.
