Software er i gang med at æde verden

I juni 2020 sendte min bank mig denne besked: 

Vi lukker alle kasser ved årsskiftet 

Efter grundige overvejelser og analyser har vi besluttet at lukke kassen i alle vores filialer fra og med den 31. december 2020. Lukningen sker fordi efterspørgslen de seneste år er faldet markant. Vi oplever at flere og flere foretrækker at ordne de daglige bankforretninger via net- og mobilbank eller ved at benytte vores ind- og udbetalingsautomater. 

Ovenstående eksempel viser meget godt, hvordan software kan erstatte hele erhvervsfunktioner, og det er ikke nogen ny trend. Marc Andreessen fra Netscape brugte allerede vendingen ”Software er i gang med at æde verden” tilbage i oktober 2000. Siden er det blevet fulgt op talrige gange af forskellige teknologi- og erhvervsledere, såsom Jeff Immelt, CEO hos General Electrics, eller Dieter Zetsche, CEO hos Daimler Benz.

Er din virksomhed ved at blive en software virksomhed? 

Man behøver ikke at have 280.000 ansatte eller indsamle og analysere billioner af datapunkter fra millioner af maskiner, før man kan have behov for at udvikle software til brug eller salg i ens virksomhed. Hos Novicell oplever vi, at flere og flere af vores kunder ser sig selv stå overfor problemstillinger, som er født af den proces, det er at udvikle software. 

Det kan være problemstillinger omkring: 

  • Konvertering af interne værktøjer til mobil- eller webapplikationer  
  • Udvikling af software, som leveres sammen med et fysisk produkt 
  • Allokering af kyndige produktfolk til it-projekter, som skal effektivisere produktionsprocesserne 
  • Tiltrækning og rekruttering af dygtige udviklere 
  • Diskussioner om betydningen for kunderne, hvis en applikation skal opgraderes 

Disse og mange andre problemstillinger er gode indikatorer på, at (dele af) din virksomhed er ved at blive en softwarevirksomhed, og at du sandsynligvis kan få glæde af at indrette budgetter, processer og infrastruktur på en måde, der tager hensyn til din (nye) status som software leverandør. Denne pointe vender jeg tilbage senere i blog posten. 

Først vil jeg gerne dele nogle eksempler på software, som jeg har set opstå og udvikle sig i forskellige virksomheder. Virksomheder, der som udgangspunkt ikke har været softwarevirksomheder. 

Alm. Brands yndlings.dk projekt 

Jeg deltog i udviklingen af yndlings.dk i 2017 og 2018. Det var et forsikringsprodukt, der startede som en idé om et anderledes forsikringsprodukt for unge baseret på en web-applikation. Vi sammensatte et team, som designede, udviklede og drev applikationen over en periode på 1½ år. Der var altså tale om et forsikringsselskab, der sammensatte et softwareudviklingsteam og hertil drev hele processen af softwareudvikling fra idé til drift. Softwaren understøttede produktet, som var en ungdomsforsikring, og hverken software eller produkt kunne eksistere alene. 

Koda's konsulent app 

Sammen med Kodas markedschef og deres abonnementskonsulenter har Novicell udviklet en mobilorienteret webapplikation, som bruges i konsulenternes daglige arbejde med at følge op på musikabonnementer hos erhvervsdrivende, der bruger musik i deres lokaler. Før udviklingen af appen løste konsulenterne opgaven gennem en kompleks proces, der skulle gennemføres fra deres computer på kontoret. Med den nye app kan konsulenterne tage deres telefon op af lommen og logge ind - så er de klar. Der er ikke noget forarbejde, og de kan gå i gang med det samme på den lokation, som de nu befinder sig. Applikationen giver dem desuden mulighed for at løse flere opgaver under aftaleopfølgningen, end de kunne før. Her er der tale om software, der effektiviserer og forbedrer en proces og dermed frigiver tid til andre opgaver. 

MIKE+ 

Mike+ er en integreret vandmodelleringsplatform udviklet af Dansk Hydraulisk Institut (DHI), som er en vandmodelleringsvirksomhed, der udsprang fra DTU i 1960'erne. Virksomheden levede længe af et fysisk simuleringsmiljø i form af et stort bølgebassin og konsulenter, men udvikler og sælger nu et dedikeret softwareprodukt, som bruges i vandplanlægning verden over. 

Tre eksempler på software fra hver af de softwaretyper, som vi ser udvikle sig i virksomheder: 

  • Software som en integreret del af dit produkt, der forbedrer og understøtter produktet 
  • Software lavet for at digitalisere og effektivisere dine processer 
  • Software som produkt i sig selv 

Uanset hvilke af disse typer af software en virksomhed involverer sig i, vil det medføre nogle behov for nye personer, ressourcer, færdigheder, processer og infrastrukturelementer. Som så mange andre forandringsprocesser er der også her udfordringer og opgaver, der skal løses. 

Hvad har virksomheden så brug for? 

En virksomhed, der selv producerer og udvikler software har brug for at opbygge rutiner og processer i en hel række af discipliner: 

  • Produktstrategi: Hvad er det for behov, som produkterne skal dække? Hvordan er det planen, at de kommer til at gøre det? Hvilke produkter skal der satses på, og i hvilken rækkefølge? 
  • Produktledelse: Hvad skal udvikles og forbedres på de software-produkter, der arbejdes på i virksomheden? 
  • Produktudvikling: Den egentlige udvikling af de produkter, som virksomheden arbejder på. 
  • Produktdistribution: Distribution af softwareproduktet til de interne eller eksterne brugere af softwaren. 
  • Produktmonitorering: Hvordan performer softwaren i brug? Oplever brugerne fejl i deres brug af produktet? Er det hurtigt nok? Er det tilgængeligt, når det skal være tilgængeligt? 

Hver af disse discipliner afføder behov og udfordringer, som skal imødegås og løftes - helst af medarbejdere med erfaring og viden på området. Lad os kigge nærmere på behovene i de forskellige discipliner: 

Produktstrategi 

Som nævnt er produktstrategien selve styrepinden til udvælgelse af produktudviklingsopgaver og prioritering af disse opgaver. Der er brug for en funktion, som har overblik over, hvilke produkter der kan arbejdes med og som forstår og medvirker til formuleringen af produktvisioner og mål med udviklingen, så man har mulighed for at formulere initiativer. 

De formulerede initiativer kan så placeres i et "product roadmap", som grundlæggende er en liste af funktioner og tilpasninger, der skal udvikles for at bringe produktet hen, hvor man ønsker det. Listen er udarbejdet på baggrund af samtaler med produktets stakeholders og har en defineret vision og målsætning.  

Et roadmap er ikke statisk. Det er et levende dokument, som kontinuerligt opdateres og revideres. Personer, som kan være kandidater til styringen af disse dokumenter, kan være medarbejdere med ansvar for forretningsudvikling og produktudvikling på forskellige niveauer i virksomheden. 

Produktledelse 

Når et produkt har en formuleret strategi, er det produktledelsens ansvar at sørge for, at strategien bliver udført. Opgaver, der løses i produktledelsen, fungerer som bindeled mellem produktstrategien og produktudviklingen ved, at produktledelsen oversætter strategiens roadmap til aktuelle opgaver, som løses i produktudviklingen. Produktledelsen fungerer også som informationskilde for de ansvarlige for produktstrategien, når det drejer sig om produktets aktuelle performance og evt. muligheder eller problemer, som udviklingen afdækker. 

Produktledelsen, der deltager i udviklingen af produktet, sikrer udviklingens overensstemmelse med visionen. De er ligeledes med i afgørelsen af tvivlsspørgsmål i selve udviklingen, overvågning og opfølgning mht. produktets performance samt opsamling af ideer til videreudvikling og meget andet. Produktledelsesfunktionen skal vide alt om produktet og har ansvaret for at tage de rigtige beslutninger for produktudviklingen dag til dag. En produktleder skal være en person med indgående kendskab til det forretningsområde, som produktet eksisterer i. Derudover skal vedkommende kunne facilitere beslutningsprocessen i produktudviklingen. 

Produktudvikling 

Produktudviklingen indeholder de funktioner, det er mest normalt at forbinde med softwareudvikling: UX/Design og programmering. Det er dog vigtigt ikke at undervurdere de processer, som skal understøtte selve udviklingen fx indsamling af data, idégenerering, arkitektur både på enterprise-, platforms- og løsningsniveau, projektstyring, samarbejdsværktøjer, test, DevOps og hosting. 

Succesfuld produktudvikling forudsætter derudover en effektiv infrastruktur til at understøtte produktudviklingen i form af: 

  • God overlevering og samarbejde fra produktledelsen. Det er vigtigt, at produktledelsen er til stede i produktudviklingen, og at der er forståelse og enighed omkring produktets visioner og mål. 
  • Kontinuerlig adgang til monitoreringsdata omkring applikationen, der udvikles. Det sikrer, at udviklingsteamet kan få feedback på de ændringer, som de implementerer, og dertil bruge data i problemløsning og idegenerering. 
  • Klare og veldesignede arkitektur guidelines. Udviklingsteamet har brug for en god teknologisk ramme at udvikle produktet i. Det gælder både på makroplan, hvor der en klar strategi på systemniveau (enterprisearkitektur), og på mikroplan, hvor der er behov for, at teamet har erfarne softwarearkitekter, som kan forme løsningen (løsningsarkitektur). 
  • Klare projektplaner som opbygges og administreres i værktøjer, som understøtter udviklingsarbejdet. Typisk i form af projektstyringsværktøjer med backlog, epics og tasks som er veldefinerede. Det kan bruges som kommunikationsværktøj i forbindelse med udvikling af softwarens features. 
  • Effektive processer omkring test, devops og hosting. Det dækker over klare aftaler omkring teststrategier, og hvad der skal til for, at en feature kan betragtes som færdig. Det gælder også gode værktøjer på området, som sikrer hurtige feedback-loops og minimering af den tid, teamet skal bruge på at håndtere DevOpsDevOps er de processer, der omhandler builddeployhosting og monitorering af softwaren. 

Med denne infrastruktur på plads kan man sammensætte et produktudviklingsteam, der består af produktleder, projektleder/scrummaster, UX-personer, designere, programmører og driftsfolk m.m.  – altså et tværfagligt udviklingsteam. Det er min erfaring, at tværfaglige teams, som selv er i stand til at vurdere konsekvenser og tage beslutninger kommer hurtigere i mål, end teams, der er afhængige af forhold og processer uden for produktsfæren. 

Produktdistribution

Nogle af de mest almindelige problemer ved opstarten af udvikling og distribuering af software omhandler softwareversioner og opgradering af eksisterende løsninger. Det er vigtigt, at man som softwareleverandør har taget stilling til, hvordan man vil håndtere nye versioner og opgradering af allerede distribueret software. Det gælder uanset, om der er tale om softwarepakker, der sælges som færdig software, Software as a Service (SaaS) løsninger, eller software, som bruges internt i virksomheden. 

Der skal være en formuleret strategi for versionering og opgradering, så forbrugere af softwaren ved, hvad de skal forholde sig til, og en udrulningsstrategi, som understøtter den. Ellers ender man hurtigt i situationer, hvor opgradering eller problemløsning bliver umuligt, fordi en aftagers situationen blokerer for en andens aftagers muligheder, eller hvor man bruger uforholdsmæssigt meget tid på at understøtte gamle versioner af ens software. 

Et eksempel på versioneringsproblemer er håndtering af ændringer i API’er, som forbruges af eksterne samarbejdspartnereHer er fokus på, hvordan man kan sikre en opdateringen og ændring af sine API’er samtidig med, at samarbejdspartnerne er orienteret, om følgerne af ændringerne og kan tilpasse deres klienter i et tempo, som passer. 

Produktmonitorering

Som allerede nævnt, har monitorering betydning for udviklingsteamet, da det fungerer som en feedback kilde for problemløsning og monitorering. Det er altså en infrastruktur, der medvirker til forbedring af softwarens kvalitet, men det er i mange sammenhænge også en nødvendighed, når det gælder dokumentation for, at softwaren leverer den aftalte ydelse i den aftalte kvalitet dvs. en integreret del af produktet. 

Mange steder dukker monitorering først op på radaren, når man i en periode har forladt sig på, at ens brugere og supportformularen på hjemmesiden fungerer som monitoreringsværktøj. Det vil sige, at fejl og mangler kun bliver opdaget ved, at kunder oplever problemer og indberetter deres problemer til supportfunktionen. Det fører til frustrerede kunder, tyndslidte kundeforhold og langsommelig og besværlig indsamling af data om virksomhedens applikation. 

Lavthængende frugter i 2021 

McKinsey og Microsoft gennemførte i 2020 undersøgelsen "Developer Velocity: How Software fuels business performance". Developer velocity er et udtryk, der beskriver produktiviteten i softwareudviklingsprocessenUndersøgelsen beskæftiger sig med 13 områder, som har betydning for produktiviteten. Det konkluderes, at 4 af de 13 områder har markant højere betydning end de andre: 

  • Tooling 
    Planlægnings-, samarbejds-, udviklings og DevOps-værktøjer har ekstremt stor betydning for teamets produktivitet. Min erfaring er, at kvaliteten af disse værktøjer har ekstremt stor betydning for teamets daglige trivsel og deres muligheder for en effektiv løsning af deres opgaver. Det kan sjældent betale sig at begrænse udviklingsteams i deres valg af værktøjer. Hvis nogle overordnede forhold alligevel gør det nødvendigt, er det ekstremt vigtigt at sikre, at teamets medlemmer har mulighed for at tilegne sig viden om værktøjerne og indrette værktøjerne med henblik på at skabe autonomi i teamet. 
     
  • Produktledelse 
    Produktledelsesevner og produkt-telemetri, dvs. oplysninger om softwarens performance i den virkelige verden, er de underemner under produktledelse, der slår tydeligst ud. Produktledelsesevnerne har særlig stor betydning, fordi de afgør kvaliteten af beslutninger om produktets retning og prioritering af opgaver. Produktlederen betyder med andre ord enormt meget for udviklingsteamets forståelse af opgaven og dermed for dets mulighed for at levere et godt stykke arbejde. Mht. til telemetrien er det min erfaring, at den er en central faktor i produktledelse, fordi det tilvejebringer den information, som produktledelsen skal bruge for at forstå problemer, få idéer og træffe beslutninger. 
     
  • Kultur 
    Et udviklingsteams kultur handler om de normer, overbevisninger og vaner, som former teamets individuelle medlemmers sociale opførsel. Det er vigtigt, at der er en god kultur omkring samarbejde, vidensdeling og vilje til konstant forbedring for teamets performance. Ifølge undersøgelsen er det særligt vigtigt med en "Psychological safety", som i danske termer nok vil oversættes til tillid. Ud fra min erfaring betyder teamets tillid til hinanden utrolig meget for performance. 
     
  • Talent management 
    Dette element omfatter incitamentsstrukturer, udvikling af individuelle evner, rekruttering m.m. Alle disse elementer findes traditionelt set i HR-afdelingen. Det kan være fristende at holde disse processer udenfor udviklingsteamet for at sikre, at teamet bruger mest muligt tid på selve udviklingen af produktet. Jeg vil dog opfordre til, at disse opgaver opfattes som services, der kan tilbydes til teamet. Det giver dem nemlig mulighed for at have indflydelse på elementer, der kan være vigtige for den enkelte. 

Det er ikke overraskende, at disse områder har betydning for et udviklingsteams performance, men for mange er det måske overraskende at se, hvordan disse områder har væsentligt større betydning end fx Code Reviews, Test Driven Development, Context Switching og ikke mindst Agile ceremonier. Områder, hvor der er brugt mange kræfter på at udvikle de seneste årtier. 

Ud fra mine erfaringer vil jeg vurdere, at de elementer, der er størst potentiale i Danmark i disse år, er: 

  • DevOps tools og processer (Tooling) 
  • Samarbejdsværktøjer og processer (Produktledelse) 
  • Inkorporering af produktledelsen i udviklingsteamet og telemetri (Produktledelse)
  • Arbejde med teamets kultur, særligt omkring kontinuerlig forbedring (Kultur) 

Det er de områder, som jeg har brugt mest tid på at arbejde med i de udviklingsteams, jeg har drevet gennem de sidste 20 år. 

Vil du høre mere om det at være softwareudgiver? 

Jeg haft afholdt webinaret "Tag magten over webplatformen i din virksomhed!" d. 11. februar 2021. Her går jeg i dybden med, hvad det vil sige at være software udgiver, og hvilke krav det stiller til din virksomhed. 

På webinaret dykker jeg blandt andet ned i følgende spørgsmål:   

  • Hvad kan du selv løse med egne ressourcer?  
  • Hvad kan du med fordel benytte eksterne leverandører til?   
  • Hvordan kan din virksomhed fastholde kontrol med intern softwareudvikling, når du inddrager eksterne leverandører?   

Se webinaret