Prøveopgaver og betalte testforløb: hvad virker når du hyrer en udvikler?

En prøveopgave til en udvikler giver kun et brugbart billede når den er betalt, afgrænset og ligner det arbejde I faktisk skal lave sammen. Min anbefaling er et kort betalt forløb, fx et forprojekt eller en lille rigtig opgave fra din liste, frem for en gratis test som kan løses på en aften.

Jeg sælger selv forprojekter til fast pris, så læs med det forbehold. Jeg skriver også hvornår en prøveopgave er spild af tid for jer begge.

Den korte version: hvilken test passer til din situation?

Min beslutningsregel er enkel. Skal du have bygget noget nyt, så start med et forprojekt. Har du allerede et system, så start med en lille betalt opgave eller en kodegennemgang. En gratis prøveopgave er sjældent det rigtige svar.

Prøveopgaven er kun ét trin i at vælge en udvikler. Resten af processen, fra behov til kontrakt, står i min guide til at hyre en udvikler.

Hvorfor gratis tests sjældent virker

En gratis prøveopgave ligner en billig måde at mindske risikoen på. I praksis giver den tit et dårligere grundlag for at vælge end ingen test. Der er fire grunde.

Den første er at de erfarne siger nej. En freelancer med en fyldt kalender har ikke en aften til overs til ubetalt arbejde for en kunde der måske vælger en anden. Du risikerer altså at teste dem der har mest tid, og ikke dem der er bedst.

Den anden er at testen måler det forkerte. De fleste gratis tests er små og isolerede, fx en lille app fra bunden eller en afgrænset kodeopgave. Den slags viser om personen kan kode. Den viser ikke om de kan arbejde i din kode med dine uklare krav, og det er der projekter går galt.

Den tredje er at indsatsen bliver skæv. Enten bruger udvikleren to timer og afleverer noget hurtigt, og så har du lært meget lidt. Eller også bruger de tre dage gratis, og så har du valgt efter hvem der har mest tid at give væk.

Den fjerde er ejerskabet. Er prøveopgaven en rigtig del af dit produkt, får du arbejde uden en aftale, og så har du formentlig ikke rettighederne til det. Det er en gråzone som ingen af jer har glæde af.

Der er én form for gratis vurdering som jeg synes er rimelig: et møde hvor udvikleren stiller spørgsmål til dit projekt og fortæller hvordan de ville gribe det an. Det er ikke en prøveopgave. Det er en normal del af at give et tilbud. Har du både hørt hvordan udvikleren tænker og set tidligere arbejde, har du allerede meget at gå ud fra. Hvordan du vurderer det tidligere arbejde uden selv at kunne kode, har jeg skrevet om i guiden til at vurdere en udviklers portfolio.

Hvad du kun ser i en betalt opgave

Et første møde viser om I kan tale sammen. En betalt opgave viser hvordan det er at arbejde sammen, og det er to forskellige ting. Det er også derfor nogle virksomheder bruger betalte forløb når de ansætter. Automattic, firmaet bag WordPress.com, har fx et betalt prøveforløb som fast trin i ansættelsesprocessen, hvor kandidaten arbejder på rigtige opgaver.

Når du hyrer en udvikler til et projekt, gælder den samme logik. Hold øje med de her ting i løbet af forløbet:

• Hvilke spørgsmål udvikleren stiller før start. En god udvikler spørger om formål, brugere og hvad der ikke er med. Ingen spørgsmål er et advarselstegn.
• Hvordan estimatet ser ud. Får du et interval hvor de største usikkerheder er nævnt, eller ét tal uden forbehold?
• Om du hører fra udvikleren uden at spørge, også når noget går langsommere end planlagt.
• Hvad der sker når du ændrer noget undervejs. Siger udvikleren hvad ændringen koster i tid, eller forsvinder den bare ind i timerne?
• Hvordan afleveringen ser ud. Ligger koden i dit repository (kodearkiv), og er der en kort note om hvad der er lavet, hvordan det er testet og hvad der bevidst ikke er med?
• Om udvikleren siger fra. En der foreslår en enklere løsning eller siger nej til en dårlig idé, er mere værd end en der siger ja til alt.

Ingen af de ting kan du se i et CV eller til et interview. Det er også dem der afgør om et projekt på flere måneder holder budgettet.

Forprojektet: den test jeg selv anbefaler

Skal du have bygget noget nyt, fx en kundeportal, et SaaS-produkt eller et internt system, er et forprojekt efter min mening den bedste prøveopgave. Det kaldes også en discovery-fase. Det er et kort, betalt forløb til fast pris hvor du og udvikleren afklarer hvad der skal bygges før nogen skriver kode til selve produktet.

Et forprojekt ender typisk med:

• en beskrivelse af formål, brugere og de vigtigste arbejdsgange
• en prioriteret liste over funktioner til første version, og hvad der kan vente
• en teknisk plan: hvilke systemer der skal tales med, hvor data ligger, og hvordan løsningen skal hostes
• de største risici, fx en integration hvor dokumentationen er tynd
• et estimat pr. fase som du kan budgettere efter

Er der én teknisk usikkerhed der kan vælte projektet, kan forprojektet også indeholde en lille prototype der afprøver netop den. Så ved I om det kan lade sig gøre før budgettet er lagt.

To ting gør forprojektet til en god test. Det er nyttigt uanset hvad du beslutter bagefter. Ejer du planen, kan en anden udvikler også bygge efter den. Og du ser præcis det du skal bruge for at vælge: hvordan udvikleren spørger, prioriterer, vurderer risiko og formulerer sig på skrift. Det er de samme egenskaber der bestemmer om resten af projektet holder.

Jeg starter selv større projekter med et forprojekt til fast pris, og i projektet bagefter ejer kunden koden fra første dag. Hvad sådan et forløb typisk koster, og hvorfor det som regel tjener sig hjem, gennemgår jeg i indlægget om hvad en discovery-fase koster.

Sådan afgrænser du et betalt testforløb i seks trin

De seks trin nedenfor gælder for alle tre typer betalte tests: forprojektet, den lille opgave og kodegennemgangen. Ingen af dem kræver teknisk viden.

1. Vælg en opgave du har brug for alligevel

Den bedste test er arbejde du ville have betalt for under alle omstændigheder. Har du et system i drift, så tag en opgave fra din liste som kan afsluttes på få dage og godkendes af én person: en ny eksport, en integration med et dokumenteret API eller en håndfuld fejlrettelser. Hvordan du afgrænser den slags, står i min guide til at bruge en udvikler til mindre opgaver.

Undgå opgaver der er opfundet til lejligheden. Dem lægger hverken du eller udvikleren rigtig energi i, og resultatet ender i en skuffe.

2. Sæt en fast ramme for tid og pris

Aftal en fast pris eller en timepris med et loft, og aftal en slutdato. Et testforløb bør kunne afsluttes på højst et par uger i kalendertid. Trækker det længere ud, er det ikke en test længere, men starten på projektet.

Regnestykket er enkelt: timer gange timepris. Med en eksempel-timepris på 900 kr. ekskl. moms koster 15 timer 13.500 kr., og 40 timer koster 36.000 kr. Det er et regneeksempel og ikke en markedspris. Hold beløbet op mod det projekt du skal i gang med. En lille andel af budgettet for at teste samarbejdet er en billig forsikring.

3. Skriv ned hvad du vil vurdere før I starter

Vælg 3-5 ting du vil se efter, fx kvaliteten af spørgsmålene, om estimatet holdt, hvor ofte du hørte fra udvikleren uden at spørge, og hvor brugbar afleveringen var. Skriver du dem ned på forhånd, vurderer du på det der betyder noget, og ikke kun på om du kunne lide personen.

Fortæl gerne udvikleren hvad du ser efter. Det er ikke snyd. Det er sådan et rigtigt samarbejde også fungerer.

4. Aftal leverancen og ejerskabet på skrift

Skriv hvad du får: et dokument, kode i dit eget repository eller en note om status. Skriv også at du ejer det der bliver lavet, og at du må bruge det hos en anden udvikler. En aftale på en side er nok til en test, men den skal findes. Hvad den egentlige aftale bør indeholde senere, står i min tjekliste til kontrakten med en freelance udvikler.

Tænk dig også om før udvikleren får adgang til rigtige kundedata. Brug testdata hvis det overhovedet kan lade sig gøre. Behandler udvikleren persondata på dine vegne, skal der som regel en databehandleraftale på plads, også i en kort test.

5. Arbejd sammen som I ville gøre i det rigtige projekt

Brug den samme kontaktperson, den samme kanal og den samme mødeform som du forventer i projektet. Én person hos dig skal kunne svare på spørgsmål inden for en dag. Overvåger du hvert skridt, tester du ikke om udvikleren kan arbejde selvstændigt, og det er netop det du betaler for.

6. Hold et kort evalueringsmøde og beslut dig hurtigt

Afslut med et møde på en halv time hvor I gennemgår resultatet, og hvor du spørger hvad udvikleren ville gøre anderledes i et rigtigt projekt. Beslut dig inden for en uge eller to, og sig det ærligt hvis du vælger en anden. En god udvikler har planlagt efter jeres forløb, og en hurtig besked er god stil.

Hvornår du ikke behøver en prøveopgave

En prøveopgave er ikke altid den bedste brug af pengene. Spring den over eller gør den mindre i de her situationer:

• Hele opgaven er lille. Er projektet på 20-30 timer, er opgaven i sig selv testen. Et ekstra testforløb gør det bare dyrere.
• Du kender en der har fået bygget noget lignende af udvikleren. En reference fra en du stoler på, siger ofte mere end en test. Brug de rigtige spørgsmål til en udviklers tidligere kunder, så får du mest ud af samtalen.
• Systemet står stille lige nu. Et akut nedbrud er ikke tidspunktet for en test. Ring til den der kender systemet, og find en ny udvikler når krisen er overstået.
• Du overvejer at teste fem udviklere på én gang. Betalte tests til fem personer er dyrt, og du kan ikke følge ordentligt med i dem alle. Skær listen ned til en eller to med portfolio, referencer og et møde, og test så kun dem.
• Du har ikke budget til en betalt test. Så er det et tegn på at projektet skal gøres mindre før det sættes i gang, ikke at testen skal være gratis.

Og en ærlig grænse fra min side: jeg arbejder med Laravel, PHP og JavaScript (React og Next.js). Er dit system bygget i noget andet, bliver en prøveopgave hos mig en dyr læreproces for dig, og den skal du ikke betale for. Så er du bedre tjent med en udvikler der kender teknologien i forvejen.

Næste skridt

Gå listen igennem før du sætter et testforløb i gang med en udvikler. Den sikrer at du får et svar du kan bruge, også hvis samarbejdet ikke fortsætter.

Vil du se hvordan jeg selv prissætter forprojekter og de projekter der følger efter, så står det åbent på min prisside. Har du ikke fundet dine kandidater endnu, så find en eller to først og kom tilbage hertil når du har en kort liste.

Ofte stillede spørgsmål

Skal jeg betale fuld pris for en prøveopgave?+

Ja, som udgangspunkt. En prøveopgave er rigtigt arbejde, og en udvikler der giver stor rabat på testen, skal hente pengene et andet sted. Det vigtige er ikke prisen pr. time, men at rammen er fast, så du kender det højeste beløb på forhånd. Vil du betale mindre, så gør opgaven mindre i stedet for at presse prisen.

Hvad gør jeg hvis prøveopgaven går dårligt?+

Så har testen gjort sit arbejde: du fandt ud af det for et lille beløb i stedet for midt i et stort projekt. Betal som aftalt, få det lavede afleveret med en note om status, og fortæl kort udvikleren hvorfor du ikke fortsætter. Var opgaven nyttig i sig selv, kan en anden udvikler bygge videre på den.

Kan jeg bruge et forprojekt fra én udvikler hos en anden?+

Ja, hvis det står i jeres aftale at du ejer resultatet. Det er en af de vigtigste grunde til at vælge et forprojekt som test. Spørg før du siger ja, for nogle udviklere og bureauer beholder rettighederne til planer og estimater. En plan du ikke må bruge andre steder, binder dig til den der har lavet den.

Hvad hvis udvikleren afviser at lave en prøveopgave?+

Siger udvikleren nej til en gratis test, er det helt normalt. Spørg om de vil tage en lille betalt opgave eller et forprojekt i stedet. Siger de også nej til en afgrænset betalt start, så spørg hvorfor. Det kan handle om kapacitet, men det kan også være et tegn på at de kun vil binde dig til et stort projekt fra dag ét.

Kan en udvikler ikke bare løse prøveopgaven med AI?+

Jo, og det er en grund mere til at droppe små kodetests. En isoleret opgave kan i dag ofte løses hurtigt med AI-værktøjer, så resultatet siger lidt om personen bag. Det er langt sværere at snyde sig igennem et forløb hvor udvikleren skal stille spørgsmål, estimere, arbejde i din eksisterende kode og forklare sine valg. Spørg gerne hvordan de bruger AI i deres arbejde.