Artikler · Egne systemer med AI · 6 min. læsning
Fra behov til første version: sådan kører et lille udviklingsforløb
Mange tror, at udvikling starter, når udvikleren begynder at kode. Den starter, når I kan forklare, hvad der skal ske i hverdagen, og hvem der skal bruge det.
Af Martin Egesø · Udgivet
Kort svar
Et lille udviklingsforløb går fra behov til første version i fem trin: forstå behovet og arbejdsgangen, afgræns første version, byg med korte demoer, prøv det af med rigtige brugere og aflever med dokumentation. Før I går videre til næste trin, skal ét krav være opfyldt. Det er jeres arbejdsgang og jeres brugere, der afgør, om det lykkes, ikke teknologien.
I artiklen 8 afsnit
Det vigtigste
- Et lille udviklingsforløb har fem trin: behov, afgrænsning, bygning, prøvedrift og aflevering.
- Hvert trin har ét krav, der skal være opfyldt, før I går videre.
- I skal selv levere en beskrivelse af arbejdsgangen, en person, der kan svare, nogle få rigtige brugere og adgang til systemer og data.
- Det farligste i et lille forløb er ikke teknikken, men at første version bliver ved med at vokse.
Hvad er et lille udviklingsforløb?
Et lille udviklingsforløb er et afgrænset arbejde, hvor en udvikler bygger en løsning til et konkret behov, for eksempel en integration, et internt værktøj eller en automatisering. Målet er en første version: den mindste udgave af løsningen, som nogen kan bruge i rigtig drift og lære af. Den er ikke en prototype, der blot viser, hvordan det kunne se ud, og den er ikke den færdige løsning med alle ønsker.
Forløbet er ikke et projekt, der først kan overskues, når det er slut. Hvert trin giver et resultat, I kan se og tage stilling til. Er I endnu ikke sikre på, om I skal bygge, så hjælper artiklen om at købe, tilpasse eller bygge.
Fem trin fra behov til første version
Modellen hedder Første version i fem trin. Det er min egen måde at holde et forløb enkelt på, ikke en standard. Tabellen viser trinene og det ene krav, der skal være opfyldt, før I går videre.
| Trin | Hvad sker der | Før I går videre, skal dette være sandt | Resultat |
|---|---|---|---|
| 1. Behov | Arbejdsgangen og problemet beskrives, helst sammen med dem, der udfører arbejdet | I kan forklare, hvad der starter arbejdsgangen, hvem der rører den, og hvor tiden eller fejlene opstår | En kort beskrivelse af arbejdsgangen. Se kortlægning |
| 2. Afgrænsning | I vælger, hvad første version skal kunne, og hvad der venter | I har sagt nej til noget, og I har skrevet det ned | En liste over, hvad der er med, og hvad der ikke er |
| 3. Bygning | Udvikleren bygger i små skridt og viser det undervejs | En bruger har set noget, der virker, ikke kun en beskrivelse | Korte demoer og rettelser |
| 4. Prøvedrift | Rigtige brugere prøver løsningen med rigtige opgaver | De, der skal bruge den, har prøvet den og sagt, hvad der ikke passer | En liste over rettelser, der skal med, og dem, der kan vente |
| 5. Aflevering | Løsningen sættes i drift og dokumenteres | Der er en ejer, og nogen kan overtage, hvis udvikleren er væk | Kørende løsning og dokumentation. Se dokumentation |
Den vigtigste regel er, at I ikke springer et trin over, fordi det føles langsomt. Mangler I trin 1, bygger udvikleren på et gæt. Mangler I trin 2, vokser løsningen, mens den bygges. Mangler I trin 4, opdager brugerne fejlene først i drift. Hvad arbejdsgangen koster i dag, og dermed hvad forløbet skal kunne betale sig mod, står i artiklen om hvad manuel administration koster.
Hvad skal I selv levere?
I skal levere fem ting. Tabellen viser dem og hvorfor.
| Det skal I levere | Hvorfor |
|---|---|
| En beskrivelse af arbejdsgangen | Udvikleren kan ikke bygge noget, der passer, hvis arbejdsgangen kun findes i hovedet på dem, der udfører den |
| En person, der kan svare | Spørgsmål, der bliver liggende, bremser forløbet mere end selve udviklingen |
| Nogle få rigtige brugere | De skal prøve løsningen undervejs og sige ærligt, hvad der ikke passer |
| Adgang til systemer og data | Løsningen skal kobles på de systemer, den skal bruge. Afklar tidligt, hvem der kan give adgang |
| En beslutning om, hvad der ikke skal med | Første version bliver kun brugbar, hvis nogen tør vælge fra |
Det er ikke et stort tidsforbrug hver dag, men det skal være en, der har tid og beslutningskraft. Kan ingen hos jer svare inden for et par dage, bliver forløbet langsomt, uanset hvor dygtig udvikleren er.
Hvor går det typisk galt?
Tre ting går typisk galt i små forløb:
- Første version vokser. "Kan den ikke også lige…" lyder uskyldigt, men hver tilføjelse flytter datoen og gør løsningen sværere at overskue. Skriv ønskerne på en liste til version to.
- Brugerne ser det først til sidst. Hvis de rigtige brugere ikke har prøvet noget undervejs, kommer rettelserne, når det er dyrest.
- Ingen ejer løsningen bagefter. Når udvikleren er færdig, er der ingen, der ved, hvordan den hænger sammen. Se hvad der skal leve videre efter go-live.
Er løsningen en AI-funktion, kommer der et ekstra spørgsmål: Hvordan går den fra en demo, der virker, til noget, I kan drive? Det handler fra AI-prototype til drift om.
Hvad sker der, hvis I ikke afgrænser?
Uden afgrænsning og trin bliver "bare lige en ting mere" til en løsning, ingen kan overskue, vedligeholde eller sige nej til. Udgiften er ikke en enkelt stor regning, men en stigende pris for hver ændring, fordi ingen længere ved, hvad en ændring påvirker. Tiden, I brugte på den manuelle arbejdsgang, bliver ikke sparet, men flyttet over i en løsning, der er svær at bruge.
Hvordan kan jeg hjælpe?
Jeg arbejder i denne rækkefølge: forstå processen → udvikle løsningen → integrere den → hjælpe med drift og videreudvikling. Udgangspunktet er, hvad systemerne skal gøre for jeres arbejde, ikke teknologien. Brug, data, adgang og relevante krav er en del af arbejdet hele vejen.
Se, om løsningen er en AI-agent, en automatisering eller en integration, og læs om mine systemer og løsninger. Jeg giver ikke juridisk rådgivning og garanterer ikke compliance. Når løsningen er i drift, kan et register som SPOR bevare overblikket over, hvad der kører, og hvem der ejer det.
Hvad kan I gøre nu?
Gør dette:
- Skriv arbejdsgangen ned på én side: hvad starter den, hvem rører den, hvilke systemer indgår, og hvor går tiden.
- Vælg, hvad første version skal kunne. Skriv det, I siger nej til, ned.
- Find en person, der kan svare inden for få dage, og to til tre rigtige brugere.
- Aftal, hvem der ejer løsningen, når den er leveret.
Kort sagt: Et lille forløb lykkes, når I kan forklare behovet, tør afgrænse, lader brugerne prøve det og ved, hvem der ejer det bagefter.
Ofte stillede spørgsmål
Hvor lang tid tager et lille udviklingsforløb?
Det afhænger af, hvor stor første version er, og hvor hurtigt I kan svare og afprøve. Spørg derfor ikke først om tid, men om afgrænsningen: Hvad skal første version kunne, og hvad venter til senere? Jo tydeligere svar, jo mere præcist kan en udvikler vurdere forløbet.
Hvad skal jeg som kunde levere?
Tre ting: en beskrivelse af arbejdsgangen, en person, der kan svare på spørgsmål undervejs, og en håndfuld rigtige brugere, der vil prøve løsningen af. Dertil adgang til de systemer og data, løsningen skal bruge.
Hvad er en første version?
En første version er den mindste udgave af løsningen, som nogen kan bruge i rigtig drift og lære af. Den er ikke en prototype, der kun viser, hvordan det kunne se ud, og den er ikke den færdige løsning med alle ønsker.
Skal jeg have en kravspecifikation, før en udvikler går i gang?
Ikke en tyk en. Men I skal kunne beskrive, hvad der starter arbejdsgangen, hvem der rører den, hvilke systemer der indgår, og hvad der skal være sandt, når den er færdig. Det er et bedre udgangspunkt end en lang liste af funktioner.
Om forfatteren
Martin Egesø er rådgiver og udvikler. Han hjælper virksomheder med at få mere ud af deres systemer og AI-værktøjer og bygger nye løsninger, når standarden ikke passer, med styr på brug, data og ansvar. Han driver MLE Gruppo ApS i Randers.
Mere om MartinArtiklen er generel vejledning og ikke juridisk rådgivning. Udgivet .