Når AI gør udviklerne hurtigere – kan resten af organisationen følge med?
AI fra en projektleders perspektiv – om udviklingshastighed, flaskehalse og den samlede værdikæde.
Af Henrik Handberg Westermann · IT Project Lead med 23 års erfaring i projektledelse
Udgivet på LinkedIn
Fra hurtigere kode til hurtigere leverancer
I mange år har en af de tilbagevendende udfordringer i softwareudvikling været ønsket om større udviklingskapacitet. Forretningen har flere idéer, behov og ønsker, end udviklingsorganisationen kan nå at realisere.
Vi har prioriteret, planlagt og forsøgt at få mest mulig værdi ud af de ressourcer, vi havde til rådighed.
Nu er AI begyndt at ændre forudsætningerne.
AI-assisteret udvikling giver mulighed for at producere kode hurtigere, automatisere dele af arbejdet og potentielt øge udviklingskapaciteten markant.
Men det rejser et spørgsmål, som jeg finder mindst lige så interessant som selve teknologien:
Betyder hurtigere udvikling nødvendigvis, at vi også kan levere flere færdige løsninger?
Softwareudvikling handler ikke kun om at skrive kode. Det handler om en samlet proces, der begynder med et forretningsbehov og først slutter, når løsningen er kvalitetssikret, godkendt, sat i produktion og skaber værdi.
Hvis vi kun accelererer én del af den proces, risikerer vi blot at flytte flaskehalsen.
Flaskehalse er ikke noget nyt
Når vi øger kapaciteten ét sted i udviklingsprocessen, kan flaskehalsen flytte sig til et andet. Det betyder, at vi ikke nødvendigvis får flere løsninger ud til forretningen, selvom en del af processen bliver hurtigere.
Et helt konkret eksempel stammer fra min seneste stilling som IT Project Lead. Her oplevede vi, at UX/design i en periode var en begrænsende faktor. Udviklerne måtte indimellem vente på, at det nødvendige design blev færdigt.
Da vi øgede designkapaciteten med en dedikeret UX-designer på fuld tid, ændrede situationen sig. Pludselig var designopgaverne klar, før udviklerne havde kapacitet til at implementere dem.
Vi havde løst én udfordring, men ikke nødvendigvis øget antallet af færdige leverancer tilsvarende.
Flaskehalsen havde ganske enkelt flyttet sig.
Det er et grundlæggende vilkår i processer, hvor flere specialiserede funktioner skal arbejde sammen om at skabe et samlet resultat.
Og det er netop derfor, AI er så interessant.
Hvis AI kan øge produktiviteten markant inden for design, udvikling og andre funktioner, kan flaskehalsene flytte sig hurtigere, end organisationen er vant til.
Spørgsmålet er derfor ikke kun, hvor meget AI kan øge produktiviteten i den enkelte funktion, men hvordan vi sikrer, at den samlede værdikæde følger med.
Når det bliver for nemt at udvikle
I AI Academy udvikler jeg en AI-agent, Delivery & Dependency Agent, der skal give IT-projektledere overblik over projekter, leverancer, afhængigheder, ressourcer og risici.
Jeg bruger ChatGPT til krav, analyse og sparring og Codex til kodeudviklingen.
AI gør det nemt at omsætte nye idéer til funktionalitet. Men når det bliver let at bygge mere, bliver det også fristende at tilføje funktioner, der ikke er nødvendige.
I arbejdet med agenten måtte jeg derfor vende tilbage til det oprindelige formål og prioritere, hvad løsningen faktisk skulle kunne.
Det understreger to gamle principper: KISS – Keep It Simple, Stupid – og Less is more.
De har altid været relevante, men AI gør dem ikke mindre aktuelle. Tværtimod.
For når vi kan udvikle næsten lige så hurtigt, som vi får nye idéer, bliver evnen til at prioritere og vælge fra mindst lige så vigtig som evnen til at udvikle.
At vi kan bygge noget, er ikke ensbetydende med, at vi bør gøre det.
Her har jeg også oplevet en begrænsning ved AI som sparringspartner. Den kan være effektiv til at omsætte ønsker til funktionalitet, men udfordrer ikke nødvendigvis af sig selv, om en ny funktion overhovedet bør udvikles.
Når udviklingshastigheden stiger, kan der samtidig blive mindre tid til den faglige sparring mellem udviklere. AI kan være en effektiv sparringspartner, men erstatter ikke nødvendigvis den kritiske dialog mellem kolleger, der kender løsningerne, afhængighederne og forretningen. Hvis vi mister den dialog i jagten på højere hastighed, risikerer vi at udvikle hurtigere uden nødvendigvis at udvikle bedre.
Det ansvar ligger fortsat hos os, der definerer behovene og prioriterer løsningen.
Godt forarbejde er stadig fundamentet
Godt forarbejde er afgørende for et vellykket projekt. Hvis vi ikke har forstået forretningens behov, risikerer vi at udvikle den forkerte løsning – uanset hvor hurtigt vi kan skrive koden.
Det begynder med en grundlæggende forståelse af målgruppens behov – uanset om målgruppen er kunder, kollegaer eller andre brugere af løsningen.
Det er disse behov, der skal være styrende for de valg, vi træffer. Både når vi definerer selve løsningen, planlægger vejen frem mod den og vælger de teknologier, der skal understøtte den.
Klare forretningsmål, tydelige krav, realistiske prioriteringer og en fælles forståelse mellem forretning og udvikling er derfor afgørende. Men de skal alle tage afsæt i den værdi, vi ønsker at skabe for målgruppen.
Det ændrer AI ikke på.
Tværtimod kan behovet for grundigt forarbejde blive endnu større.
Når AI gør det lettere at gå direkte fra idé til kode, kan vi blive fristet til at springe for hurtigt over analyse, afklaring og planlægning. Ikke fordi disse aktiviteter er blevet mindre vigtige, men fordi det er blevet så nemt at komme i gang med udviklingen.
Når vi kan omsætte krav til kode langt hurtigere, kan vi også hurtigere udvikle den forkerte løsning, hvis vi ikke har forstået målgruppens behov tilstrækkeligt.
Den tid, vi sparer på udviklingen, kan hurtigt blive brugt på efterfølgende rettelser, afklaringer og gentagne testforløb.
Derfor tror jeg ikke, at AI gør den indledende analyse, kravspecifikation og prioritering mindre vigtig. Jeg tror snarere, at vi skal være endnu mere disciplinerede.
Og vi skal bruge AI som mere end en effektiv udførende ressource. Vi skal også stille krav til den som kritisk sparringspartner, der hjælper os med at udfordre antagelser, afdække uklarheder og holde fokus på det, der skaber reel værdi.
Det er målgruppens behov, der skal definere løsningen – ikke teknologiens muligheder. Teknisk korrekt er ikke nødvendigvis forretningsmæssigt korrekt
En anden erfaring fra arbejdet med min AI-agent handler om testdata og verificering.
Fordi projektet er en prototype uden integration til virkelige virksomhedssystemer, arbejder jeg med fiktive projekter, opgaver og afhængigheder.
Det fungerer fint til at teste, om funktionaliteten teknisk opfører sig efter de definerede regler.
Men det er vanskeligere at vurdere, om agentens konklusioner og anbefalinger er rigtige, når jeg ikke kender de projekter og sammenhænge, den arbejder med.
Hvis testdata i stedet afspejlede kendte projektforløb med forventede resultater, ville det være betydeligt lettere at gennemskue fejl og uhensigtsmæssigheder.
Det er en problemstilling, jeg kender særdeles godt fra mit samarbejde med udviklere gennem årene.
Jeg har ofte oplevet, at udviklerne har bedt mig og forretningen om at verificere løsninger. Ikke nødvendigvis fordi der var tvivl om den tekniske implementering, men fordi de ikke altid havde adgang til repræsentative data eller det indgående forretningskendskab, der skulle til for at vurdere, om resultatet var korrekt.
Det samme gør sig gældende ved AI-assisteret udvikling.
Automatiserede tests kan være bestået, og løsningen kan umiddelbart se overbevisende ud. Men det dokumenterer ikke i sig selv, at løsningen understøtter de faktiske behov og arbejdsgange.
Teknisk korrekt er ikke nødvendigvis det samme som forretningsmæssigt korrekt.
Derfor forsvinder behovet for tæt samarbejde mellem udviklere, projektledelse og forretning ikke med AI. Det kan tværtimod blive endnu vigtigere.
Når udviklingshastigheden stiger, flytter presset sig
Forestil dig en udviklingsorganisation, der med AI bliver i stand til at færdiggøre væsentligt flere udviklingsopgaver inden for samme periode.
Umiddelbart lyder det som en stor gevinst – måske ligefrem det, vi alle sammen har drømt om og set frem til i årevis: At kunne udvikle og levere langt mere på kortere tid.
Men hvad sker der, hvis kapaciteten i de øvrige dele af udviklingsprocessen er uændret?
Allerede inden udviklingen går i gang, kan UX/design være en begrænsning, hvis der ikke er kapacitet til at klargøre flere opgaver. Og når udviklerne bliver hurtigere, vil flere opgaver potentielt nå QA og UAT tidligere og i større antal på samme tid.
Det kan skabe kø, længere ventetider og flere samtidige afklaringer.
Selvom udviklerne arbejder hurtigere, kan den samlede gennemløbstid derfor forblive uændret eller i værste fald blive længere.
AI kan naturligvis også hjælpe med design, testautomatisering, udarbejdelse af testcases og andre dele af kvalitetssikringen. Men det ændrer ikke ved, at en løsning fortsat skal vurderes i forhold til forretningens behov.
Og her opstår en udfordring, som jeg finder særlig interessant.
I mange virksomheder er forretningens deltagelse i udviklingsprojekter ikke organiseret som en dedikeret fuldtidsfunktion.
Product Owners, faglige specialister og nøglebrugere har ofte andre opgaver, som de skal løse samtidig.
De skal prioritere udviklingsønsker, afklare spørgsmål, træffe beslutninger, teste funktionalitet og godkende løsninger, mens den daglige forretning fortsætter.
Og her ligger en væsentlig udfordring: Den daglige drift vil som udgangspunkt altid have førsteprioritet. Når ressourcerne er pressede, vil udvikling af nye løsninger og funktioner derfor ofte blive nedprioriteret til fordel for de opgaver, der er nødvendige for at holde forretningen kørende.
Det betyder, at selvom AI gør udviklerne i stand til at levere hurtigere, er det langt fra sikkert, at forretningen kan frigøre den nødvendige kapacitet til at følge med.
Hvis udviklingskapaciteten stiger markant, skal forretningens kapacitet til at understøtte processen potentielt stige tilsvarende.
Det kan kræve ændrede arbejdsgange, tydeligere ansvar, hurtigere beslutningsprocesser og flere ressourcer til blandt andet UAT.
Jeg har selv oplevet, hvordan øget kapacitet inden for UX/design ændrede behovet for samarbejde mellem IT og forretningen.
En del af arbejdet med at drive den indledende behovsafklaring og konkretisering af opgaverne blev flyttet til IT, så vi kunne sikre fremdrift uden konstant at være afhængige af forretningens tilgængelighed.
Det betød dog ikke, at forretningen mistede ejerskabet. Gennem løbende dialog, afklaringer og demoer sikrede vi, at løsningerne fortsat blev udviklet i tæt samarbejde med forretningen, som også havde den endelige beslutningsret.
Det var en praktisk måde at tilpasse samarbejdet til ændrede kapacitetsforhold. Og måske er det netop den slags organisatoriske tilpasninger, der bliver endnu vigtigere, når AI øger udviklingshastigheden.
Erfaringen understregede for mig, hvor vigtigt det er med klare processer, tydelige roller og en entydig ansvarsfordeling.
Når udviklingskapaciteten øges, bliver det endnu vigtigere at vide, hvem der driver opgaverne fremad, hvem der skal involveres, og hvem der har mandat til at træffe beslutninger.
AI ændrer ikke på behovet for god projektledelse og governance. Tværtimod kan højere udviklingshastighed gøre begge dele endnu vigtigere.
Forretningen kan ikke blot efterspørge højere udviklingshastighed. Den skal også være parat til selv at understøtte den.
Automatisering, kvalitet og deployment – når hastigheden øges
I en udviklingsorganisation, jeg tidligere har arbejdet i, byggede vi automatiske tests, som udviklerne kunne bruge løbende under udviklingen. Det gjorde det muligt at opdage og rette fejl tidligere, inden opgaverne blev sendt videre til QA.
Men automatiske tests erstatter ikke den øvrige kvalitetssikring. Hos os skulle alle kodeændringer gennem code review, QA og UAT. Uden undtagelse. Vi styrede også selv build og deployment, så vi havde kontrol over, hvornår ny kode blev lagt i produktion.
Når AI gør det muligt at færdiggøre flere udviklingsopgaver på kortere tid, øges presset ikke kun på QA og UAT, men også på release- og deploymentprocessen.
Flere færdige opgaver betyder, at vi enten skal kunne gennemføre flere deployments eller samle flere ændringer i den enkelte release. Begge dele stiller krav til processen.
Hyppigere deployments kræver en effektiv og gerne mere automatiseret proces. Større releases kan omvendt øge kompleksiteten og gøre det vanskeligere at identificere fejl eller rulle ændringer tilbage.
Automatisering gennem eksempelvis CI/CD kan reducere det manuelle arbejde, men fjerner ikke nødvendigvis behovet for koordinering, kvalitetssikring og kontrol.
Pointen er enkel: Vi skal bruge automatisering til at arbejde smartere og hurtigere – men ikke på bekostning af kvaliteten eller kontrollen over det, vi leverer.
Skal AI skabe flere leverancer eller lavere omkostninger?
Det bringer os frem til et strategisk spørgsmål.
Hvis AI gør det muligt at øge udviklingskapaciteten markant, men resten af organisationen ikke kan følge med, hvordan skal virksomheden så realisere gevinsten?
Én mulighed er at styrke hele værdikæden.
Det kan betyde investeringer i UX/design, QA, UAT, Product Ownership, forretningsanalyse, release management og de øvrige funktioner, der er nødvendige for at omsætte udviklingskapacitet til færdige løsninger.
I det scenarie kan AI blive en løftestang for flere leverancer, kortere time-to-market og større forretningsværdi.
En anden mulighed er at fastholde omtrent samme samlede leverancekapacitet og i stedet tilpasse udviklingsressourcerne til den mængde arbejde, organisationen kan håndtere.
Her realiseres gevinsten primært gennem lavere udviklingsomkostninger.
Begge muligheder kan være forretningsmæssigt fornuftige. Og i praksis kan en kombination også være relevant.
Men de repræsenterer forskellige ambitioner.
Der er forskel på at bruge AI til at skabe mere værdi og til at producere den samme værdi billigere.
Derfor mener jeg, at virksomheder bør være bevidste om, hvilken gevinst de ønsker, og om deres organisation er indrettet til at realisere den.
Ellers risikerer vi at optimere udviklingsafdelingen uden at forbedre den samlede leveranceevne.
Det vigtigste er stadig den samlede leverance
Succesfuld softwareudvikling handler ikke kun om teknologi eller udviklernes hastighed. Det handler om at få mennesker, kompetencer og ressourcer til at spille sammen, så vi får de rigtige løsninger ud til brugerne.
AI giver os mulighed for at udvikle hurtigere end nogensinde før. Men udfordringen er ikke at vælge mellem hastighed og kvalitet. Den er at udnytte den øgede udviklingskapacitet uden at miste kontrollen over kvaliteten og den samlede leverance.
Jeg har oplevet, hvordan en øget designkapacitet kunne flytte flaskehalsen til udviklingen. I min seneste stilling fik udviklerne også adgang til AI-assisteret kodeudvikling gennem Claude, hvilket gav mig mulighed for at følge teknologiens indtog i en etableret udviklingsorganisation.
Sammen med mine aktuelle erfaringer fra AI Academy har det styrket min opmærksomhed på, hvordan hurtigere implementering stiller større krav til behovsafklaring, prioritering og kvalitetssikring.
AI giver os interessante muligheder for at ændre softwareudviklingen.
Men vi skal passe på med at forveksle højere produktivitet i ét led med højere produktivitet i hele værdikæden.
Vi skal ikke kun spørge, hvor hurtigt vi kan udvikle. Vi skal spørge, hvor hurtigt vi kan levere færdige løsninger, der skaber reel værdi.
Og det efterlader mig med en tese, som jeg har mine egne tanker om, men som jeg er nysgerrig på at høre andres perspektiver på:
Kan det vise sig at være lettere at skalere den tekniske udviklingskapacitet med AI end at skalere forretningens evne til at specificere, prioritere, teste og godkende løsninger?
Jeg har en klar formodning om svaret, men tror ikke, det er sort-hvidt. Det vil formentlig afhænge af den enkelte virksomheds organisering, processer og evne til at tilpasse sig.
Hvis det viser sig at være tilfældet, kan den største udfordring ved AI i softwareudvikling vise sig at ligge et helt andet sted end hos udviklerne.
Hvordan oplever I det i jeres organisation? Og hvis I allerede oplever, at AI øger udviklingshastigheden, hvordan arbejder I så med at sikre, at resten af organisationen kan følge med?