Onboarding af en freelance udvikler: 10 ting du skal have klar dag 1

Onboarding af en freelance udvikler går ud på at have adgange, en kontaktperson, et klart mål og den eksisterende dokumentation klar, før den første time bliver faktureret. Har du de 10 ting nedenfor på plads, går de første betalte timer til dit projekt i stedet for til at vente på et login. Listen er skrevet fra udviklerens side af bordet.

Den korte version: tjeklisten

Har du ikke fundet din udvikler endnu, så start med guiden til at hyre en udvikler.

Adgange: kode, drift, testmiljø og tjenester

1. Adgang til koden

Koden bør ligge i et repository (kodearkiv) på virksomhedens egen konto hos fx GitHub eller GitLab. Udvikleren får sin egen bruger, så du kan se hvem der har lavet hvad, og fjerne adgangen igen med ét klik. Ligger koden hos en tidligere udvikler eller et bureau, så få den flyttet før opstart. Baggrunden står i artiklen om hvem der ejer koden, og hvilke adgange du skal sikre dig.

2. Adgang til hosting og drift

Udvikleren skal kunne se hvordan systemet kører: hostingkontoen eller serveren, databasen, fejlloggen og den måde ny kode sættes i drift på. Giv så lidt adgang som muligt, men nok til at løse opgaven. Læseadgang til produktion er ofte nok i starten. Ved du ikke hvilke konti der findes, så lav listen sammen med udvikleren den første dag.

3. Et testmiljø med testdata

Et testmiljø (staging) er en kopi af systemet hvor udvikleren kan prøve ændringer af, uden at dine kunder mærker noget. Opret testbrugere i hver rolle, fx administrator, medarbejder og kunde. Brug testdata eller anonymiserede data frem for en kopi af den rigtige database. Findes der ikke et testmiljø, er det ofte en af de første opgaver at sætte et op, og de timer tjener sig typisk hurtigt hjem.

4. Tredjepartstjenester og nøgler

De fleste systemer taler med andre tjenester, fx betaling, e-mail og regnskab som e-conomic eller Dinero. Lav en liste, og invitér udvikleren som bruger hvor det kan lade sig gøre. Betalingsløsninger som Stripe har testmiljøer med testnøgler og testkort, så der ikke flyttes rigtige penge mens der udvikles.

Mennesker: hvem svarer, og hvor

5. En kontaktperson med mandat

Udpeg én person som udvikleren kan spørge, og som kan træffe beslutninger om det der bliver bygget. Personen behøver ikke være teknisk, men skal kende forretningen og svare inden for en arbejdsdag. Aftal også hvem der overtager ved ferie. Noget af det dyreste i et udviklingsforløb er dage hvor udvikleren venter på svar, eller gætter og må lave det om.

6. Kanal og rytme

Bestem hvor spørgsmål skal stilles: Slack, Teams eller mail. Bestem hvor opgaverne ligger, fx i Trello, Linear eller Jira, så I begge kan se status. Aftal en fast rytme, fx et kort statusmøde om ugen, og hvordan fejl meldes: hvad der skete, hvor, og gerne med et skærmbillede. Én kanal er bedre end tre, for spørgsmål spredt over mail, sms og telefon bliver glemt.

Mål og rammer for de første uger

7. Et mål for de første 2-4 uger

"Gør systemet bedre" er ikke et mål. "Kunderne skal kunne betale med kort i webshoppen inden 1. maj" er. Vælg den første leverance, beskriv hvornår den er færdig, og prioritér resten bagefter. Mit råd er at holde det første mål lille, så I hurtigt ser om samarbejdet fungerer. Har du ikke beskrevet projektet endnu, så brug min skabelon til en projektbeskrivelse.

8. Rammerne på skrift

Før første time skal I være enige om omfang, pris og timerapportering. Ved timepris aftaler I et loft pr. uge eller måned. Ved fast pris tjekker du hvad prisen dækker. Får udvikleren adgang til oplysninger om dine kunder eller medarbejdere, er udvikleren typisk databehandler for dig, og så skal I have en skriftlig databehandleraftale. Datatilsynet har skabeloner til databehandleraftaler du kan tage udgangspunkt i. Resten af aftalen kan du holde op mod min tjekliste til en kontrakt med en freelance udvikler.

Viden: dokumentation og historik

9. Den eksisterende dokumentation

Saml alt hvad der findes, i én mappe: kravspecifikationer, designs i fx Figma, en README (en kort vejledning sammen med koden) og beskrivelser af vigtige arbejdsgange. Send også det forældede, og skriv hvad du ved er forkert. Det viser stadig hvad tanken var. Findes der næsten intet, er en tjekliste til dokumentation af softwareprojekter et godt sted at starte, og udvikleren kan skrive det manglende undervejs.

10. Historikken og de kendte problemer

Den vigtigste viden står sjældent i et dokument. Hvorfor stoppede den tidligere udvikler? Hvilke dele af systemet tør ingen røre ved? Hvad klager kunderne over, og hvad er allerede forsøgt? Sæt en time af hvor en der kender systemet, viser det frem og forklarer hvorfor tingene er som de er. Så slipper udvikleren for at genopdage problemerne på din regning.

Sådan forløber de første dage

En god opstart følger typisk de samme fire trin:

1. 2-3 dage før start: aftalen er underskrevet, og adgangene er sendt, så udvikleren kan tjekke at de virker.
2. Dag 1, første time: et opstartsmøde med kontaktpersonen om målet, systemet og historikken.
3. Dag 1, resten af dagen: udvikleren får systemet til at køre på sin egen computer, læser koden og noterer spørgsmål.
4. Første uge: en lille, afgrænset opgave der går hele vejen fra ændring til test og drift.

Det sidste trin anbefaler jeg mest. En lille opgave der kommer helt i drift, afslører huller i adgange, testmiljø og samarbejde langt billigere end en stor opgave der går i stå efter tre uger.

Hvornår listen er for meget, og hvornår den ikke er nok

Skal en udvikler bruge fem timer på at rette en fejl på din hjemmeside, behøver du ikke alle 10 punkter. Adgang til koden og driften, en kontaktperson og en klar beskrivelse af opgaven er nok. Det gennemgår jeg i artiklen om at bruge en freelance udvikler til mindre opgaver.

Omvendt kan listen ikke erstatte en person i din virksomhed der ejer produktet. En freelancer som mig kan stille spørgsmålene, men ikke beslutte hvad din forretning har brug for. Kan du ikke afsætte en kontaktperson med tid og mandat, så overvej et bureau med en projektleder der kan tage noget af den rolle. Det koster mere, men det er billigere end en udvikler der bygger det forkerte.

Næste skridt

Gå tjeklisten igennem en uge før din udvikler starter. Det der mangler, kan I lave sammen i den første uge, men så ved I begge at de timer går til opstart. Er du stadig ved at vælge, så brug listen som en test: en god udvikler spørger selv efter de fleste punkter.

Hos mig har du direkte kontakt med den der skriver koden, og koden ligger i dit repository fra første dag. Se mine ydelser, og hvordan et samarbejde med mig foregår.

Ofte stillede spørgsmål

Skal jeg betale for udviklerens onboarding?+

Ja, som regel. Opstart er arbejde: udvikleren læser kode, sætter systemet op og stiller spørgsmål. Hvor lang tid det tager, afhænger af systemets størrelse og din forberedelse. Ved fast pris er opstarten normalt regnet med. Ved timepris kan du bede om et estimat på opstarten, før den går i gang.

Hvor lang tid går der, før en freelance udvikler er produktiv?+

Ved et lille, velorganiseret system kan udvikleren levere noget brugbart inden for de første dage. Ved et større system uden dokumentation kan der gå flere uger, før arbejdet kører i fuld fart. Det afhænger mest af kodens tilstand, dokumentationen og hvor hurtigt spørgsmål bliver besvaret.

Skal udvikleren have adgang til produktionsdatabasen?+

Ikke fra første dag, og ofte slet ikke. De fleste opgaver kan løses i et testmiljø med testdata. Nogle fejl viser sig dog kun i rigtige data, og så kan midlertidig læseadgang være nødvendig. Giv adgangen til en bestemt opgave, fjern den igen bagefter, og sørg for at databehandleraftalen er på plads hvis der er persondata.

Hvad gør jeg med adgangene når samarbejdet slutter?+

Fjern dem samme dag. Har udvikleren haft sin egen bruger alle steder, skal du blot slå brugerne fra i stedet for at skifte hver adgangskode. Skift dog de API-nøgler og fælles adgangskoder udvikleren har kendt. Gem listen over adgange fra opstarten, så kan den bruges som tjekliste ved afslutningen.