Nearshore betyder, at udviklerne sidder i et land tæt på jer, ofte i samme eller næsten samme tidszone. Offshore betyder, at de sidder længere væk, med flere timers forskel. I begge tilfælde flytter I arbejdet med at bygge, mens arbejdet med at beslutte og kontrollere bliver hjemme og som regel vokser. Modellen lykkes for virksomheder, der har en stærk ejer af produktet, klare beskrivelser og en fast rytme. Den kører typisk af sporet, når ledelsen håber, at leverandøren selv kan udfylde hullerne.
Hvad der ændrer sig, når teamet ikke sidder ved siden af
I et lille team på samme kontor retter misforståelser sig selv i løbet af en kop kaffe. Afstand fjerner den mekanisme. Det, der før blev sagt ved skrivebordet, skal nu skrives ned, og det, der er uklart i beskrivelsen, bliver bygget, som udvikleren gætter. Sprog og kultur spiller også ind. Nogle steder siger man sjældent nej til en kunde, så et “ja” kan betyde “vi har hørt dig”. Spørg derfor efter, hvad der konkret bliver leveret og hvornår, og lad være med at nøjes med en stemning af enighed.
Afstanden kræver kort sagt mere ledelse pr. udvikler. Regn den tid med, når I sammenligner tilbud. En billigere time hjælper kun, hvis nogen har overskud til at styre den.
Rollen, der skal blive hjemme
Den vigtigste rolle er produktejeren, på engelsk product owner: personen, der afgør, hvad der skal bygges næste gang, og hvornår noget er godt nok. Rollen kan ikke sendes ud af huset, for den kræver kendskab til kunderne og mandat til at vælge. Hos en lille virksomhed er det ofte stifteren, der må stå for den, og det tager mere tid, end de fleste regner med. Har ingen tiden, er det et stærkt tegn på, at I ikke er klar.
Følgende hører også hjemme hos jer:
- Ejerskabet af konti og kode. Kodelager, cloud og nøgler hører til hos jer. Se listen over konti og adgange.
- De store tekniske beslutninger. Arkitektur og teknologivalg skal besluttes af nogen på jeres side og skrives ned, fx som i skriv de tekniske beslutninger ned.
- Godkendelsen. Den, der bestiller, siger god for leverancen.
- Forståelsen af produktet. Mindst én hos jer skal kunne forklare, hvordan produktet er skruet sammen.
Tre krav, der afgør udfaldet
Specifikationen. En opgavebeskrivelse skal give mening for en person, som aldrig har mødt jeres kunder. Skriv, hvem brugeren er, hvad vedkommende skal kunne, og hvordan I ser, at det virker. Skitser og eksempler slår lange tekster. Det hele behøver ikke stå klart fra start. Det, der sættes i gang i denne omgang, skal.
Kodegennemgangen. Kodegennemgang (code review) betyder, at hver ændring bliver læst af endnu en udvikler, inden den indgår i produktet. Aftal, at det sker hver gang, og afklar, hvem der gør det. Kan I, bør en person på jeres side stikprøveagtigt kunne se, at det sker. Den vigtigste kontrol er, at gennemgangen faktisk finder sted, og at den kan ses på kodeplatformen.
Tilstedeværelsen. Tidsforskel og distance løses med en aftalt rytme: en kort daglig kontakt, en fast demonstration af det, der er bygget, og et overlap i arbejdstiden, hvor begge sider svarer. Et fysisk møde, når samarbejdet starter, og derefter med faste mellemrum, gør meget for tilliden og er noget af det første, der bliver sparet væk.
Spørgsmål til tilbuddet
Stil disse spørgsmål, før I skriver under:
- Hvem er de navngivne udviklere, og hvor længe er de på opgaven?
- Hvordan håndteres udskiftning af folk, og hvem betaler for oplæringen?
- Hvem er vores tekniske kontaktperson, og taler vedkommende sproget godt nok til at sige fra?
- Hvor ofte kan vi se fungerende software?
- Hvor ligger koden, og hvilke maskiner arbejder udviklerne på?
- Må vi tale med en kunde, der har arbejdet med samme team i over et år?
Udskiftning af udviklere er en omkostning, der let overses. Viden går med, når folk stopper, så bed om, at dokumentation og overdragelse indgår i det daglige arbejde. Hvad I generelt kan forlange af en leverandør på sikkerhedsområdet, gennemgår ciso-as-a-service.dk i en artikel om aftalen.
Kundedata fortjener en særskilt beslutning. Lad så vidt muligt udviklerne arbejde med opdigtede testdata, se persondata i produktet. Skal folk uden for EU kunne se rigtige kundedata, er det et spørgsmål til advokat, før arbejdet starter.
Sådan begynder I
Start med en afgrænset opgave, som kan bedømmes efter få uger, og som ikke rører hele produktet. Hold øje med tre ting: stiller teamet gode spørgsmål, kommer dårlige nyheder tidligt, og svarer det leverede til det aftalte? Først derefter giver det mening at lægge mere ud. Styringen bagefter er beskrevet i sådan styrer I en udviklingsleverandør.
Overvejer I modellen, så skriv først ned, hvem der hos jer bliver produktejer, og hvor mange timer om ugen vedkommende har. Kan I ikke svare, er det dér, I skal begynde.
Det skal I lade være med
- At vælge alene efter timeprisen · regn jeres egen ledelsestid og oplæring med.
- At sende produktejerskabet ud af huset · uden en ejer hos jer bygger leverandøren efter bedste gæt.
- At starte med hele produktet · begynd med noget, der kan bedømmes hurtigt.
- At opgive de fysiske møder · de er billigere end en lang misforståelse.
Det skal I kræve af den eksterne
- ☐ En klar beskrivelse af, hvad der skal blive hjemme, og hvem der ejer det.
- ☐ En prøveopgave med kriterier fastlagt på forhånd.
- ☐ Faste krav til kodegennemgang, test og dokumentation.
- ☐ En rytme for møder og demonstrationer, som begge sider kan holde.
- ☐ Vurdering af leverandører uden økonomisk interesse i valget.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Freelancer, bureau eller eget team til første version · Hvornår er en leverance færdig?
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT
