Sådan bruger du en freelance udvikler til mindre opgaver (10-50 timer)
Sådan bruger du en udvikler til mindre opgaver på 10-50 timer: afgræns opgaven, sæt et loft over timerne, og vælg mellem fast pris og klippekort.
Freelance full-stack udvikler
- Udgivet
- Læsetid
- 11 min.
Indhold i indlægget8
En udvikler til mindre opgaver giver dig mest for pengene når opgaven er afgrænset, kan beskrives på en side og afleveres som én samlet ændring. Opgaver på 10-50 timer, fx en integration, en ny rapport i dit administrationssystem eller en liste med fejlrettelser, kan sagtens løses af en freelancer, men kun hvis I aftaler omfang, et loft over timerne og hvad færdig betyder før arbejdet går i gang.
Jeg tager selv opgaver af den størrelse på eksisterende systemer, så læs med det forbehold. Jeg skriver også hvornår du hellere skal gå en anden vej.
Den korte version: hvad passer til 10-50 timer?
| Opgave | Passer det? | Det afgør det |
|---|---|---|
| Integration til et system med et dokumenteret API, fx regnskab, betaling eller CRM | Ofte | Om API'et er veldokumenteret og om der findes en testkonto |
| Ny rapport, eksport eller side i et eksisterende administrationssystem | Ja | Om data allerede findes i databasen |
| Fejlrettelser fra en prioriteret liste | Ja, med et loft | Fejl kan sjældent prissættes før de er fundet |
| Opgradering af framework, fx til en nyere Laravel-version | Nogle gange | Hvor mange versioner der skal springes over og om der findes automatiske tests |
| Lille internt værktøj eller prototype | Nogle gange | Kun hvis omfanget er meget smalt og brugerne er få |
| Gør systemet hurtigere, uden et konkret mål | Ikke uden afgrænsning | Start med en kort analyse der finder de største problemer |
| Et nyt produkt eller en MVP | Nej | Det er et projekt med faser, ikke en opgave |
Min tommelfingerregel: kan du beskrive resultatet på en side, og kan én person hos dig godkende det på en eftermiddag, passer opgaven sandsynligvis til 10-50 timer. Kræver den flere beslutningsmøder, design fra bunden eller ændringer i flere systemer på én gang, er det et projekt, og så gælder andre spilleregler. Dem gennemgår jeg i guiden til at hyre en udvikler som dækker hele forløbet fra behov til kontrakt.
Hvorfor små opgaver koster mere end timerne antyder
På en opgave på 20 timer vejer de faste omkostninger ved at komme i gang langt tungere end på et projekt på 300 timer.
Første gang en udvikler skal arbejde i din kode, går der typisk tid med at få adgang, sætte projektet op på sin egen maskine og forstå hvordan tingene hænger sammen. Den tid er nogenlunde den samme uanset om opgaven er stor eller lille. På et stort projekt forsvinder den i helheden. På en opgave på 15 timer kan den udgøre en mærkbar del af regningen.
Det samme gælder kommunikation. Et opstartsmøde, et par afklarende spørgsmål og en gennemgang til sidst fylder ikke meget i et forløb over flere måneder. På en lille opgave er det en reel post.
Det betyder tre ting for dig:
- Jo bedre forberedt du er, jo flere af de betalte timer går til selve opgaven.
- Det kan betale sig at samle flere små ønsker i én opgave frem for at sende dem af sted ét ad gangen.
- Når en udvikler først kender din kode, bliver de næste opgaver billigere. Det er et godt argument for at blive hos den samme hvis samarbejdet fungerer.
Er koden skrevet af en anden udvikler som ikke længere er med, så regn med mere opstartstid. Og ligger koden ikke et sted hvor du selv har adgang, er det det første problem der skal løses. Min guide til at skifte udvikler midt i et projekt gennemgår hvordan du får adgange og overblik på plads, og meget af den gælder også her.
Sådan griber du en opgave på 10-50 timer an
De seks trin nedenfor holder de fleste små opgaver på sporet. Ingen af dem kræver teknisk viden, og de fleste handler om at fjerne gætteri før timerne begynder at løbe.
1. Beskriv resultatet, ikke løsningen
Skriv hvad der skal være anderledes når opgaven er løst, og for hvem. "Når en ordre er betalt, skal der automatisk oprettes en faktura i regnskabssystemet med kundens CVR-nummer" er en god beskrivelse. "Lav en integration" er ikke.
Skriv også hvad der ikke er med, fx kreditnotaer eller gamle ordrer. Det er ofte den linje der sparer flest timer, fordi den fjerner antagelser. En side er nok. Vedhæft gerne skærmbilleder af den nuværende arbejdsgang og et par eksempler på rigtige data.
2. Giv adgang og kontekst fra start
Udvikleren skal som minimum have adgang til dit repository (kodearkivet), et testmiljø og en beskrivelse af hvordan systemet sættes i drift. Findes der et staging-miljø (en kopi af systemet hvor man kan teste uden risiko), så sig det. Findes det ikke, kan det være første del af opgaven.
Fortæl også hvem der har bygget systemet og om de kan svare på spørgsmål. Hver adgang der mangler på dag ét, koster ventetid, og ventetid på en lille opgave betyder tit at den bliver skubbet til næste uge.
3. Bed om et interval og et loft
Et seriøst estimat på en lille opgave er et interval, fx 14-20 timer, og ikke ét tal. Bed udvikleren skrive hvad der trækker mod den høje ende. Aftal derefter et loft hvor arbejdet stopper og I tager stilling før der bruges flere timer.
Er opgaven for uklar til at estimere, så betal for 1-3 timers afklaring først. Det er billigere end et estimat der er gættet.
4. Aftal hvad færdig betyder
Skriv 3-5 punkter der skal være opfyldt før du godkender opgaven. For eksempel: virker i testmiljøet, er afprøvet af dig med rigtige data, er sat i drift, og der er skrevet en kort note. Aftal også hvem der sætter ændringen i drift og hvornår. En fredag eftermiddag er sjældent et godt tidspunkt.
5. Hold kommunikationen samlet
Små opgaver går i stå når udvikleren venter på svar eller når tre personer hos dig har hver sin mening. Udpeg én person der kan træffe beslutninger, og aftal en fast rytme, fx en kort skriftlig status hver anden dag. Daglige møder er for meget til en opgave på 20 timer.
6. Kræv en aflevering der kan bruges bagefter
En god aflevering består af koden i dit eget repository, typisk som en pull request (en samlet ændring der kan gennemgås før den lægges ind), og en kort note: hvad er ændret og hvorfor, hvordan er det testet, og hvad er bevidst ikke lavet. Den note er det der gør næste opgave billigere, også hvis det er en anden udvikler der skal lave den.
Sørg for at aftalen siger at du ejer koden, også på en opgave på 15 timer. Hvad aftalen ellers bør indeholde, står i min tjekliste til kontrakten med en freelance udvikler.
Fast pris, timepris med loft eller klippekort?
Der er tre almindelige måder at afregne en lille opgave på. Ingen af dem er altid bedst. Det afhænger mest af hvor godt opgaven kan beskrives på forhånd.
| Fast pris | Timepris med loft | Klippekort | |
|---|---|---|---|
| Bedst til | En klart beskrevet opgave i kode som udvikleren kender | Fejlrettelser og opgaver med ukendte dele | Mange små opgaver over tid på samme system |
| Du kender på forhånd | Den præcise pris | Den højeste pris | Timeprisen og antallet af købte timer |
| Din risiko | At der ligger en buffer i prisen | At loftet nås før opgaven er færdig | At timerne ikke bliver brugt eller udløber |
| Kræver af dig | En præcis beskrivelse før start | Hurtige beslutninger når loftet nærmer sig | En fast kontaktperson og en løbende opgaveliste |
| Faldgrube | Ændringer undervejs bliver til ekstraarbejde | Uden loft er regningen åben | Uklare regler for hvordan små rettelser afregnes |
Regnestykket er enkelt: timer gange timepris. Med en timepris på 900 kr. ekskl. moms som eksempel koster 10 timer 9.000 kr., og 50 timer koster 45.000 kr. Det er et regneeksempel og ikke en markedspris. Hvad erfarne freelancere faktisk tager, kan du se i min gennemgang af timepriser for freelance udviklere i Danmark.
Ved fast pris betaler du for at udvikleren bærer risikoen. Det er rimeligt, men det betyder også at prisen ofte ligger i den høje ende af et estimat. Timepris med loft bliver som regel billigst når opgaven går som planlagt, og du har stadig en grænse.
Vil du have prisen ned, så skær i omfanget i stedet for at presse timeprisen. Hvordan du gør det uden at gå på kompromis med kvaliteten, har jeg skrevet om i guiden til at forhandle med en udvikler.
Hvornår et klippekort er fornuftigt
Et klippekort er en pulje timer du køber på forhånd og bruger efterhånden. Det passer godt når:
- dit system er i drift, og der løbende opstår små ønsker og fejl
- du vil bruge den samme udvikler, så opstartstiden kun betales én gang
- du hellere vil have et fast budget end et nyt tilbud på hver lille ændring
Til én enkelt opgave passer det dårligt. Der binder du penge i timer du måske ikke får brug for, og du får ikke glæde af at udvikleren kender systemet bagefter.
Læs betingelserne før du køber. Spørg om timerne udløber og hvor små enheder der afregnes i. Et kvarter, en halv time eller en hel time pr. opgave gør stor forskel når der er tale om mange små rettelser. Spørg også hvor hurtigt udvikleren svarer og om du får en løbende oversigt over forbruget. Uden den oversigt bliver klippekortet en ren tillidssag, og det behøver det ikke at være.
Et klippekort er heller ikke det samme som en serviceaftale. Klippekortet betaler for timer. En serviceaftale dækker typisk også at nogen holder øje med systemet, opdaterer det og svarer inden for en aftalt tid. Har du et system der skal køre stabilt hver dag, er det ofte en serviceaftale du har brug for.
Hvornår du ikke skal bruge en freelancer til små opgaver
Der er situationer hvor en ekstern udvikler er det forkerte valg, også når opgaven er lille:
- Du har allerede en udvikler eller et team der kender koden. Opstartstiden for en ny person kan æde en stor del af opgaven.
- Systemet står stille lige nu. Et akut nedbrud kræver en der allerede har adgang og kender systemet. Har du ikke en aftale om det, er det dét du skal have på plads når krisen er overstået.
- Opgaven kan løses uden kode. Mange problemer i fx Shopify, WordPress eller et standard-CRM klares med en indstilling, en eksisterende udvidelse eller leverandørens support. Spørg dem først.
- Opgaven tager få timer i kode som udvikleren ikke kender. Så får du mere ud af at samle flere ønsker indtil der er nok til at opstarten betaler sig.
- Systemet er bygget i en teknologi som udvikleren ikke arbejder med til daglig. Jeg arbejder med Laravel, PHP og JavaScript (React og Next.js). Er dit system bygget i noget andet, får du mere for pengene hos en der kender det.
Den sidste er også min egen grænse. En lille opgave i en ukendt teknologi bliver hurtigt til en dyr læreproces, og den bør du ikke betale for.
Næste skridt
Gå listen igennem før du sender en lille opgave til en udvikler. Den tager ti minutter og sparer ofte de første betalte timer.
Inden du sender opgaven
- Resultatet er beskrevet på højst en side, inklusive hvad der ikke er med.
- Adgangene er klar: repository, testmiljø og kontakt til den tidligere udvikler, hvis der er en.
- Du har bedt om et interval og et loft og ikke kun ét tal.
- Kriterierne for færdig er skrevet ned i 3-5 punkter.
- Én person hos dig træffer beslutningerne og kan svare inden for en dag.
- Afleveringen er aftalt: kode i dit repository, en kort note og en aftale om hvem der sætter i drift.
- Aftalen siger at du ejer koden.
Har du løbende små opgaver på et system i drift, kan du se hvordan jeg arbejder med vedligehold og videreudvikling af eksisterende systemer. Er det første gang du køber udvikling, så start med de spørgsmål du bør stille en udvikler før du hyrer.
Ofte stillede spørgsmål
Skal jeg betale for et estimat på en lille opgave?
Det afhænger af hvor meget udvikleren skal undersøge. Et groft skøn ud fra en god beskrivelse er ofte gratis. Kræver estimatet at udvikleren læser koden eller afprøver et API, er det rimeligt at betale for et par timers afklaring. Du får et mere præcist tal, og afklaringen er sjældent spildt fordi den samme viden bruges når opgaven løses.
Hvad er den mindste opgave det kan betale sig at give til en freelancer?
Min tommelfingerregel er at en opgave i en ukendt kodebase skal være stor nok til at opstarten ikke fylder det meste af regningen. Det er sjældent tilfældet med opgaver på et par timer. Kender udvikleren allerede koden, kan selv meget små opgaver være god økonomi. Har du kun én lille ting, så vent og saml flere ønsker.
Kan jeg bruge en lille opgave til at teste en udvikler?
Ja, en betalt opgave på 10-20 timer er en af de bedste måder at teste et samarbejde på før du sætter et større projekt i gang. Du ser hvordan udvikleren estimerer, kommunikerer og afleverer. Vælg en opgave der er nyttig i sig selv. Så er pengene ikke spildt hvis I ikke fortsætter. Gratis prøveopgaver siger mindre fordi de sjældent ligner rigtigt arbejde.
Hvad sker der hvis opgaven viser sig at være større end estimeret?
Har I aftalt et loft, stopper udvikleren før loftet er nået og forklarer hvorfor. Så har du tre muligheder: godkend flere timer, skær noget fra opgaven, eller stop og få det lavede afleveret med en note om status. Det vigtige er at beslutningen er din og at den bliver truffet før timerne er brugt.