Artikler · Egne systemer med AI · 5 min. læsning
Hvordan vælger I udvikler eller leverandør? Syv spørgsmål at stille
Det farligste ved at vælge en udvikler er ikke at vælge en dårlig. Det er at vælge en god, som I ikke kan komme af med, når personen er væk.
Af Martin Egesø · Udgivet
Kort svar
Stil de samme syv spørgsmål til alle udviklere og leverandører, I overvejer: hvem ejer koden, hvem kan overtage, hvad sker efter go-live, hvor ligger data, hvordan afprøves nye versioner, hvordan prissættes ændringer, og kan I se noget, der virker. Sammenlign svarene og ikke kun prisen. Stil gerne spørgsmålene til mig også.
I artiklen 8 afsnit
Det vigtigste
- Stil de samme syv spørgsmål til alle, I overvejer.
- Det vigtigste at få afklaret er ejerskab, overdragelse og hvad der sker efter go-live.
- Sammenlign svarene, ikke kun prisen.
- Bed om at se noget, der virker, før I beslutter jer.
Hvad vælger I egentlig?
Når I vælger en udvikler eller leverandør, vælger I tre ting på én gang: en person, der skal forstå jeres arbejde, et firma, der skal være der om to år, og et produkt, som I skal leve med. En leverandør kan være et firma, der bygger noget til jer, eller et firma, der sælger et færdigt system som abonnement. Er I ikke sikre på, om I skal købe, tilpasse eller bygge, så læs købe, tilpasse eller bygge.
Syv spørgsmål før I vælger
Modellen hedder Syv spørgsmål før I vælger. Den er min egen, ikke en standard. Tabellen viser spørgsmålene, hvad et godt svar kan lyde som, og hvad der bør give anledning til eftertanke. Svarene er eksempler.
| Spørgsmål | Et godt svar lyder som | Giver anledning til eftertanke |
|---|---|---|
| 1. Hvem ejer koden og dokumentationen? | "I ejer koden, og I får adgang til den og til dokumentationen" | Uklare svar, eller at koden kun ligger hos udvikleren |
| 2. Hvem kan overtage, hvis du stopper? | "Dokumentationen gør det muligt for en anden at overtage" | "Det er kun mig, der forstår det" |
| 3. Hvad sker der efter go-live? | En klar aftale om fejlrettelser, drift og videreudvikling | Ingen aftale, eller først at tale om det, når der er et problem |
| 4. Hvilke data og tjenester indgår, og hvor ligger de? | En liste over tjenester med region og kontoejer. Se seks ting | Svar som "det klarer vi" uden detaljer |
| 5. Hvordan afprøves en ny version? | Et testmiljø adskilt fra produktion og en rutine for, hvad der testes | Ændringer, der rulles direkte ud til brugerne |
| 6. Hvordan prissættes ændringer? | En klar måde at vurdere og prissætte ændringer på, før de bygges | Ændringer, der opgøres først bagefter |
| 7. Kan jeg se noget, der virker? | En kort demo eller et eksempel, I selv kan prøve | Kun præsentationer og referencer, ingen demo |
Stil spørgsmålene på samme måde til alle. Det gør det muligt at sammenligne svarene, og det er ofte i det uklare svar, forskellen viser sig. Stil dem gerne til mig også, jeg svarer på dem nederst i artiklen.
Hvad skal I have klar, før I spørger?
En udvikler kan kun give et godt tilbud, hvis I kan beskrive, hvad I vil have. Skriv derfor først de fem svar i almindeligt sprog. Det gør også tilbuddene sammenlignelige, fordi alle byder på det samme. Er løsningen et lille forløb, så beskriv, hvad første version skal kunne.
Sådan sammenligner I tilbud
Et tænkt eksempel
Tre tilbud på den samme opgave: A er billigst, men siger ikke noget om ejerskab, dokumentation eller tiden efter go-live. B og C er dyrere og svarer klart på de tre punkter. Alle detaljer er tænkte.
| Tilbud A | Tilbud B | Tilbud C | |
|---|---|---|---|
| Pris | Lavest | Midt | Højest |
| Ejerskab af koden | Uklart | I ejer den | I ejer den |
| Dokumentation | Ikke med | Med | Med |
| Efter go-live | Ikke nævnt | Aftale om fejlrettelser | Aftale om drift og videreudvikling |
Det billigste tilbud er ikke nødvendigvis det dyreste i længden, men heller ikke det billigste. Forskellen viser sig i det, tilbuddet ikke nævner. Spørg derfor altid: Hvad er med, og hvad koster ekstra?
Hvad sker der, hvis I vælger uden at spørge?
Vælger I uden at spørge, opdager I først, hvem der ejer koden, og hvem der kan rette fejl, når noget går galt, eller når udvikleren forsvinder. Så bliver skiftet dyrt og langsomt, fordi viden og adgang sidder hos én. Se hvad der skal leve videre efter go-live, og hvad I skal dokumentere.
Hvordan kan jeg hjælpe?
Jeg svarer på de syv spørgsmål sådan: Dokumentation, test og overdragelse aftaler vi fra start, og jeg viser noget, der virker, undervejs. Se mine systemer og løsninger. Jeg giver ikke juridisk rådgivning og garanterer ikke compliance. Når løsningen kører, kan SPOR samle ejerskab, dokumentation og leverandører ét sted.
Hvad kan I gøre nu?
Gør dette:
- Skriv de fem svar om jeres behov, så alle byder på det samme.
- Stil de syv spørgsmål skriftligt til to eller tre kandidater.
- Bed om at se noget, der virker.
- Aftal ejerskab af kode og dokumentation, før I starter.
Kort sagt: Spørgsmålene er vigtigere end prisen, og de kan stilles til alle, også til mig. Et næste skridt er, at køre et lille udviklingsforløb.
Ofte stillede spørgsmål
Hvordan vælger jeg en udvikler?
Stil de samme spørgsmål til alle, I overvejer: hvem ejer koden, hvem kan overtage, hvad sker efter go-live, hvor ligger data, hvordan afprøves nye versioner, hvordan prissættes ændringer, og kan I se noget, der virker. Sammenlign svarene, ikke kun prisen.
Skal jeg vælge den billigste leverandør?
Prisen er kun en del af billedet. Et lavt tilbud kan skjule, at dokumentation, test og overdragelse ikke er med. Spørg, hvad tilbuddet indeholder, og hvad der koster ekstra, før I sammenligner.
Hvem ejer koden, når en udvikler har bygget en løsning?
Det afhænger af aftalen. Aftal skriftligt, hvem der ejer koden, og at I får adgang til kildekode og dokumentation. Er I i tvivl om de juridiske detaljer, så tal med en jurist.
Hvordan ved jeg, om en udvikler kan levere?
Bed om at se noget, der virker, og tal med en tidligere kunde, hvis det er muligt. Spørg også, hvordan udvikleren arbejder med små skridt og korte demoer, så I kan se fremdrift undervejs.
Artiklen er generel vejledning og ikke juridisk rådgivning. Udgivet .