Ansætte offshore-udviklere: sådan gør I det rigtigt

Det kan spare både tid og penge at ansætte offshore-udviklere, men kun hvis I gør det rigtigt. Når det går galt, skyldes det sjældent, at udviklerne ikke kan kode. Det skyldes, at opgaven var uklar, at ingen testede samarbejdet, før kontrakten blev skrevet under, eller at koden endte et sted, I ikke selv har adgang til. Her er en praktisk gennemgang fra første opgavebeskrivelse til den første måned i drift.

Fem ting at tage med

• Beskriv arbejdet, før I beskriver personen. Rolle, opgaver og fælles arbejdstid kommer før CV’er.
• Vælg spor: freelancer, bureau eller et dedikeret team. De kræver hver sin mængde ledelse fra jer.
• Test samarbejdet i praksis med en kort, betalt prøveperiode på en rigtig opgave.
• Koden skal ligge i jeres eget repository fra dag ét, og rettighederne skal stå i kontrakten.
• Den første måned afgør resten. Planlæg onboarding lige så grundigt som udvælgelsen.

Start med arbejdet, ikke med CV’et

Det første spørgsmål er ikke, hvilket land I skal kigge i, men hvad udvikleren skal lave. Skriv tre til fem konkrete opgaver ned, som personen skal løse i de første måneder, og hvilke systemer de berører. Det gør det langt nemmere at vurdere kandidater, og det afslører hurtigt, om I mangler en senior, der kan tage beslutninger, eller en udvikler, der kan levere på en plan, som allerede ligger fast.

Beslut også, hvor mange timers fælles arbejdstid I har brug for. Islamabad er tre til fire timer foran Danmark, og Kairo er én time foran. Med et par timers overlap hver dag kan man holde et dagligt møde og svare på spørgsmål samme dag. Kræver opgaven, at udvikleren sidder med i jeres møder hele dagen, er offshore sandsynligvis det forkerte valg. Forskellen på nearshore og offshore har vi gennemgået i artiklen om nearshore eller offshore for danske virksomheder.

Freelancer, bureau eller dedikeret team

Der er tre almindelige måder at ansætte offshore-udviklere på, og de passer til forskellige situationer:

• Freelancer. Fleksibelt og hurtigt til en afgrænset opgave. Til gengæld står I selv for udvælgelse, kvalitetssikring og planlægning, og der er ingen backup, hvis personen bliver syg eller siger op.
• Bureau med projektansvar. I køber et resultat i stedet for timer. Godt, når opgaven kan beskrives præcist, men dyrt at ændre undervejs.
• Dedikeret team. Udviklerne arbejder kun for jer og indgår i jeres egen proces, mens leverandøren står for ansættelse, udstyr og erstatning. Det passer bedst til løbende udvikling.

Hvordan et dedikeret udviklingsteam fungerer i hverdagen, og hvem der styrer hvad, kan I læse i vores guide til et eksternt udviklingsteam.

Sådan vurderer I kandidaterne

Et CV og en liste over teknologier siger meget lidt. Det, der virker, er at se personen arbejde:

• Gennemgå rigtig kode. Bed om et eksempel, kandidaten selv har skrevet, og lad jeres egen udvikler stille spørgsmål til det.
• Lav en kort parprogrammering. En time på en lille, realistisk opgave i jeres eget miljø viser mere end en lang kodetest.
• Test kommunikationen. Kan kandidaten forklare en løsning på engelsk, stille opklarende spørgsmål og sige fra, når noget er uklart? Det betyder mere end flydende sprog.
• Tal med referencer. Helst nogle, der har arbejdet med udvikleren i mindst et halvt år.

Afslut med en betalt prøveperiode på to til fire uger med en rigtig opgave fra jeres backlog. Det er den mest pålidelige test, og en seriøs leverandør siger ja til den.

Kontrakt, rettigheder og data

Inden nogen skriver en linje kode, skal kontrakten være på plads. Den bør som minimum dække:

• At alle rettigheder til koden overgår til jer, efterhånden som den bliver skrevet.
• Fortrolighed for både udviklere og leverandør.
• En databehandleraftale, hvis udviklerne får adgang til personoplysninger, og hvilke data de i givet fald må se.
• Opsigelsesvarsel og en plan for overdragelse, hvis samarbejdet stopper.

Lige så vigtigt er det praktiske: koden ligger i jeres eget repository, udviklerne får personlige konti, som I kan lukke igen, og ingen arbejder direkte i produktionen. Overtager I kode, som en anden leverandør har skrevet, kan en kodeaudit vise, hvad I faktisk står med, før det nye team bygger videre.

De første 30 dage

Mange samarbejder går skævt i den første måned, fordi den nye udvikler bliver sat til at vente på adgang og svar. Planlæg derfor:

• Én fast kontaktperson hos jer, som svarer samme dag.
• Adgang til kode, testmiljø og opgavestyring klar på første dag.
• Små opgaver i første uge, der når helt ud i drift, så hele vejen fra kode til release bliver afprøvet.
• Et dagligt møde i den fælles arbejdstid og en kort status hver uge.

Advarselstegn, når I skal ansætte offshore-udviklere

• En timepris, der ligger langt under alle andre. Forskellen bliver som regel betalt senere.
• Leverandøren vil ikke lade jer møde de udviklere, der rent faktisk skal arbejde for jer.
• De seniorer, I mødte i salgsfasen, forsvinder, når arbejdet går i gang.
• Koden ligger kun hos leverandøren, og I får den først ved projektets afslutning.
• Et nej til en prøveperiode, eller en kontrakt uden klar overdragelse.

Sådan arbejder vi

Embrace-IT Technologies har kontorer i Danmark, London, Islamabad og Kairo. Når I vil leje offshore-udviklere hos os, foreslår vi navngivne udviklere, som I selv interviewer. Udviklerne arbejder i jeres repository og jeres værktøjer, og I kan starte med en prøveperiode. Skal hele opgaven løses af os, er outsourcing af softwareudvikling den model, der passer bedst. Når systemet er i drift, kan det fortsætte i en aftale om løbende vedligeholdelse.

Ofte stillede spørgsmål

Inden I beslutter

Skriv de første opgaver ned, beslut hvor meget fælles arbejdstid I har brug for, og vælg det spor, der passer til jeres egen kapacitet til ledelse. Mød kandidaterne, test dem på en rigtig opgave, og hav kontrakten og jeres repository klar, før arbejdet begynder. Så er det at ansætte offshore-udviklere en kontrolleret beslutning og ikke et sats.