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 DevOps. DevOps er de processer, der omhandler build, deploy, hosting 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 samarbejdspartnere. Her 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 softwareudviklingsprocessen. Undersø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?
