Projektbeskrivelse til en udvikler: sådan får du brugbare tilbud (skabelon)
Sådan skriver du en projektbeskrivelse til en udvikler på 1-2 sider: skabelon, udfyldt eksempel og det en udvikler skal bruge for at give et brugbart tilbud.
Freelance full-stack udvikler
- Udgivet
- Læsetid
- 12 min.
Indhold i indlægget9
En god projektbeskrivelse til en udvikler fylder 1-2 sider og svarer på det udvikleren skal bruge for at estimere: hvilket problem der skal løses, for hvem, hvad første version skal kunne, hvad der findes i forvejen og hvilket budget og hvilken tidsramme du har. Det er ikke en kravspecifikation, men et kort beslutningsgrundlag der gør tilbuddene sammenlignelige. Nedenfor får du en skabelon du kan kopiere og et udfyldt eksempel.
Jeg giver selv tilbud ud fra den slags beskrivelser, så skabelonen er bygget på det jeg har brug for når jeg skal sætte et interval på et projekt. Jeg skriver også hvornår en kort beskrivelse ikke er nok.
Den korte version: det skal din projektbeskrivelse kunne
| Spørgsmål | Kort svar |
|---|---|
| Hvor lang skal den være? | 1-2 sider. Bliver den længere, er det typisk fordi den beskriver løsninger frem for behov. |
| Hvem skriver den? | Dig, på almindeligt dansk. Den kræver ingen teknisk viden. |
| Hvad skal med? | Baggrund, problem og mål, brugere, første version, det der findes i forvejen, krav, budget og tid, beslutninger og hvad du vil have tilbage. |
| Hvad skal ikke med? | Teknologivalg du ikke kan begrunde, detaljeret design og alle de ønsker du har til de næste fem år. |
| Hvem skal have den? | 2-4 udviklere eller bureauer. Alle får den samme version. |
| Hvad får du tilbage? | Et prisinterval, de antagelser det bygger på, hvad der ikke er med og et forslag til første skridt. |
Min tommelfingerregel: en udvikler der læser din beskrivelse, skal kunne forklare projektet tilbage til dig med egne ord og højst have en håndfuld spørgsmål. Kan vedkommende det, er beskrivelsen god nok til et interval.
Projektbeskrivelsen er første trin i min guide til at hyre en udvikler, som tager dig hele vejen fra behov til kontrakt. Er opgaven lille, fx en enkelt integration eller en række fejlrettelser, er en halv side ofte nok. Hvordan du griber de opgaver an, står i guiden til at bruge en udvikler til mindre opgaver.
Projektbeskrivelse, kravspecifikation eller forprojekt?
Tre dokumenter bliver ofte blandet sammen, og det er dyrt at bruge det forkerte.
| Projektbeskrivelse | Kravspecifikation | Forprojekt | |
|---|---|---|---|
| Omfang | 1-2 sider | Mange sider, ofte med hvert krav nummereret for sig | Et kort forløb med møder og et skriftligt resultat |
| Hvem laver det | Dig | Dig, en konsulent eller en udvikler | Dig og udvikleren sammen |
| Det får du | Et prisinterval og en fornemmelse af om udvikleren forstår opgaven | Et grundlag for at indhente faste priser på præcis det samme | En afgrænset første version, de vigtigste tekniske beslutninger og en fast pris eller et snævert estimat |
| Det koster | Din egen tid, typisk et par timer | Mange timer, internt eller hos en konsulent | Et betalt forløb |
| Passer til | Første kontakt med udviklere | Offentlige udbud og store projekter med flere leverandører | Større projekter hvor du vil have en fast pris |
Til de fleste projekter i SMV'er og startups er projektbeskrivelsen det rigtige sted at starte. En kravspecifikation (et detaljeret dokument der beskriver alle krav til systemet) er nødvendig når du skal i offentligt udbud, eller når flere leverandører skal byde på præcis det samme. Skal du skrive en, har jeg en separat guide med skabelon til en kravspecifikation.
Ulempen ved at starte med en kravspecifikation er at du træffer mange beslutninger før du har talt med nogen der skal bygge systemet. Nogle af de dyreste krav kunne være blevet løst enklere hvis udvikleren havde været med fra start.
Jeg arbejder selv sådan her: en kort projektbeskrivelse giver et groft interval og en snak om hvorvidt jeg er den rigtige til opgaven. Ved større projekter følger et betalt forprojekt til fast pris, hvor du og jeg sammen afgrænser første version. Først derefter kommer en fast pris på selve udviklingen. Projektbeskrivelsen bruger du altså til at vælge hvem du vil tale videre med. Den endelige pris kommer senere.
Skabelonen: ni afsnit du kan kopiere
Kopiér skabelonen ind i et dokument og udfyld den. Skriv kort, gerne i punktform. Kender du ikke svaret på et afsnit endnu, så skriv at det er uafklaret, og sæt det under åbne spørgsmål. Det er mere nyttigt for udvikleren end et gæt.
PROJEKTBESKRIVELSE: [arbejdstitel]
Kontakt: [navn, rolle, e-mail] Dato: [dato]
1. Baggrund
Hvem er I, hvad laver I, og hvorfor skal projektet laves nu?
2. Problem og mål
Hvad fungerer dårligt i dag?
Hvad er anderledes når projektet er lykkedes, og hvordan måler I det?
3. Brugere
Hvem skal bruge løsningen, hvor mange er de, og hvilke roller har de?
4. Første version
Skal med: 5-10 punkter i formen "En [bruger] kan ..."
Kan vente: det I gerne vil have senere
5. Det der findes i forvejen
Systemer, data, integrationer, eksisterende kode, design, domæne
6. Krav og rammer
Persondata, sprog, enheder, tilgængelighed, hosting, branchekrav
7. Budget og tid
Budgetinterval ekskl. moms. Deadline, og hvorfor den ligger der.
8. Beslutninger og samarbejde
Hvem beslutter? Hvor meget tid har I? Hvem står for drift bagefter?
9. Det vil jeg gerne have tilbage
Prisinterval, antagelser, fravalg, forslag til første skridt. Svarfrist.
Åbne spørgsmål: [det I ikke ved endnu]
Hvad jeg kigger efter når jeg skal estimere
Når jeg læser en projektbeskrivelse, leder jeg efter de ting der flytter prisen mest. Det er sjældent antallet af skærmbilleder. Det er oftere de her:
- hvor mange brugerroller der er og hvem der må se og ændre hvad
- integrationer, især til systemer uden et veldokumenteret API eller et testmiljø
- data der skal flyttes fra et gammelt system og ryddes op undervejs
- betaling, abonnementer og fakturering
- hvor meget administratorerne selv skal kunne ændre uden en udvikler
- krav til tilgængelighed, sprog og sikkerhed
- deadlines der ikke kan flyttes
Mangler et af punkterne i beskrivelsen, bliver mit interval bredere fordi jeg skal regne med begge muligheder. Et bredt interval er et ærligt udtryk for hvor meget der stadig er uafklaret. Vær mere skeptisk over for et præcist tal på et projekt der kun er beskrevet i fem linjer.
Min tilgang er at stille de spørgsmål der betyder mest for prisen før jeg giver et interval. Får du slet ingen spørgsmål fra en udvikler, så overvej om beskrivelsen er blevet læst grundigt.
Sådan udfylder du de ni afsnit
Skriv til en udvikler der ikke kender din branche. Det der er selvfølgeligt for dig, er det sjældent for en udenforstående.
1. Baggrund
Et par linjer om virksomheden: hvad I laver, hvor mange I er og hvem jeres kunder er. Skriv også hvorfor projektet skal laves nu. "Vores største kunde kræver det fra næste år" og "vores gamle system bliver ikke længere opdateret" fører til forskellige løsninger, og udvikleren skal kende årsagen for at foreslå den rigtige.
2. Problem og mål
Beskriv hvad der fungerer dårligt i dag, gerne med en konkret arbejdsgang. "Ordrer kommer ind på mail og bliver tastet manuelt ind i økonomisystemet, cirka 40 om ugen" siger mere end "vi skal digitalisere". Skriv derefter hvordan du kan se at projektet er lykkedes, fx færre manuelle trin eller at kunderne selv kan finde deres fakturaer. Et klart mål gør det også nemmere at sige nej til funktioner der ikke hjælper.
3. Brugere
Skriv hvem der skal bruge løsningen og hvor mange de er. Antallet af roller betyder typisk mere for prisen end antallet af brugere. Et system hvor kunder, medarbejdere og administratorer ser hver sit, kræver mere arbejde end et hvor alle ser det samme. Nævn også om brugerne sidder ved en computer eller mest bruger telefonen.
4. Første version: skal med og kan vente
Det her er det vigtigste afsnit. Skriv 5-10 punkter i formen "En kunde kan se sine ordrer og downloade fakturaer". Formen tvinger dig til at beskrive hvad brugeren skal kunne, ikke hvordan det skal se ud.
Lav derefter en liste over det der kan vente. Den fortæller udvikleren hvor systemet skal kunne vokse hen, og den gør det tydeligt hvad der ikke er med i prisen. Er du i tvivl om noget hører til første version, så spørg dig selv om det kan klares manuelt i en periode. Er svaret ja, kan det som regel vente.
5. Det der findes i forvejen
List de systemer løsningen skal arbejde sammen med, fx økonomisystem, CRM, webshop eller betalingsløsning. Skriv om de har et API (en dokumenteret måde for systemer at udveksle data på), eller at du ikke ved det. Nævn også data der skal flyttes fra et gammelt system, eksisterende kode, design eller en designguide, og hvem der ejer domæne og hosting. Integrationer og dataflytning er typisk der hvor et estimat er mest usikkert, så de skal frem fra start.
6. Krav og rammer
Skriv de krav der ikke er til forhandling. Det kan være at løsningen behandler persondata og derfor skal overholde GDPR, at data skal ligge i EU, at den skal findes på flere sprog, eller at den skal leve op til krav om tilgængelighed. Har din branche særlige regler, så nævn dem. Krav der først dukker op midt i projektet, er dyrere at bygge ind end dem der er kendt fra start.
7. Budget og tid
Det er fristende at holde budgettet tilbage fordi du frygter at udvikleren så bare bruger det hele. I praksis giver det dårligere tilbud. Uden et budget gætter hver udvikler på dit ambitionsniveau, og du ender med ét tilbud på en enkel løsning og ét på en stor.
Skriv et interval ekskl. moms, fx 150.000-250.000 kr., og skriv din deadline og hvorfor den ligger der. En messe i marts er en fast deadline. "Helst før sommerferien" er et ønske, og det skal udvikleren vide. Ligger budgettet langt fra det opgaven kræver, er det bedre at høre det nu end efter tre møder. Så kan I skære i omfanget i stedet for i kvaliteten, som jeg beskriver i guiden til at forhandle med en udvikler.
8. Beslutninger og samarbejde
Skriv hvem der træffer beslutningerne og hvor meget tid vedkommende kan bruge på projektet om ugen. En udvikler der venter på svar, koster penge, og en beslutningstager med to timer om måneden er en reel risiko for tidsplanen. Skriv også hvem der skal stå for drift, opdateringer og videreudvikling efter lanceringen. Det påvirker både teknologivalget og hvem du bør vælge.
9. Det vil du have tilbage
Slut af med at skrive hvad du vil have tilbage og hvornår. Når alle svarer på de samme punkter, bliver tilbuddene langt nemmere at sammenligne. Bed om:
- et prisinterval for første version og hvad der trækker mod den høje ende
- de antagelser prisen bygger på
- hvad der ikke er med, fx hosting, drift, design eller dataflytning
- et forslag til første skridt, fx et forprojekt eller en mindre første fase
- hvem der konkret skal lave arbejdet
Giv en svarfrist på 1-2 uger. En udvikler der læser grundigt og tænker sig om, har som regel også andre projekter i gang.
Et udfyldt eksempel
Et forkortet eksempel. Virksomheden og tallene er opdigtede, men opbygningen følger skabelonen.
| Afsnit | Det står der |
|---|---|
| Baggrund | VVS-firma med 25 ansatte og omkring 600 erhvervskunder, mest boligforeninger og ejendomsadministratorer. Vores største kunde har bedt om bedre overblik over serviceopgaver. |
| Problem og mål | Kunderne ringer og skriver for at få status på opgaver og kopier af fakturaer. Målet er at halvere de henvendelser inden for et år. |
| Brugere | Kunder med 2-5 kontaktpersoner hver, 3 medarbejdere på kontoret og 1 administrator. Kunderne bruger mest computer. |
| Første version, skal med | En kunde kan logge ind og se åbne og afsluttede opgaver. En kunde kan downloade fakturaer. En kunde kan oprette en serviceanmodning med billeder. Kontoret kan se og fordele anmodninger. |
| Kan vente | App til montørerne, online betaling og automatiske påmindelser om service. |
| Det der findes | Fakturaer i e-conomic. Opgaver i et sagsstyringssystem hvor vi ikke ved om der findes et API. Logo og farver, men intet design. |
| Krav og rammer | Persondata om kundernes kontaktpersoner. Kun dansk. Skal fungere på mobil. |
| Budget og tid | 150.000-250.000 kr. ekskl. moms til første version. Lancering gerne inden oktober, men det er ikke en fast deadline. |
| Beslutninger | Direktøren beslutter, kontorchefen er daglig kontakt med 3 timer om ugen. Ingen IT-afdeling, så vi ønsker en aftale om drift. |
| Det vil vi have tilbage | Prisinterval, antagelser, hvad der ikke er med, forslag til første fase og hvem der laver arbejdet. Svar inden 14 dage. |
Læg mærke til linjen om sagsstyringssystemet. Den er det største usikkerhedspunkt i hele beskrivelsen, og den er skrevet ærligt. Har systemet et brugbart API, er integrationen en overskuelig opgave. Har det ikke, skal opgaverne måske overføres på en helt anden måde, og det kan flytte prisen mærkbart. En god udvikler spørger ind til netop det punkt før der kommer et tal på papiret.
Læg også mærke til hvad der står under "kan vente". Uden den linje ville nogle udviklere regne en montørapp med i prisen, og andre ville ikke.
Fejl der giver ubrugelige tilbud
De fleste tilbud der ikke kan sammenlignes, starter med en uklar beskrivelse. Ud over et manglende budget er det typisk de her fejl:
- Du beskriver løsningen i stedet for problemet. Et færdigtegnet skærmbillede låser udvikleren fast på din idé, også når der findes en billigere vej til samme mål.
- Du henviser til en kendt app. "Som Airbnb, bare til udlejning af værktøj" siger noget om idéen, men ikke om hvilke dele af Airbnb du har brug for i første version. Det er de dele der koster.
- Ønskelisten har ingen prioritering. Står alt som lige vigtigt, prissætter udvikleren det hele, og du får et tal der skræmmer.
- Du vælger teknologi uden begrundelse. "Det skal laves i React" er fint hvis dit team kan vedligeholde det. Ellers er det udviklerens opgave at foreslå og din at få forklaret.
- Du skjuler usikkerhed. Skriv hellere "vi ved ikke om systemet har et API" end ingenting.
Hvornår du ikke skal sende beskrivelsen til en freelancer som mig
- Skal du i offentligt udbud, gælder udbudsreglerne. Så har du brug for en kravspecifikation og typisk juridisk rådgivning.
- Kan opgaven løses med et standardsystem, fx en webshopplatform eller et færdigt bookingsystem, så undersøg det først. Det er som regel billigere end at få noget udviklet.
- Kræver projektet et helt team fra første dag, er et bureau ofte et bedre valg end én udvikler.
- Er systemet bygget i en teknologi jeg ikke arbejder med, får du mere ud af en der kender den. Jeg arbejder med Laravel, PHP og JavaScript med React og Next.js.
Næste skridt
Gå listen igennem før du sender beskrivelsen af sted.
Før du sender projektbeskrivelsen
- Højst 2 sider, skrevet så en udenforstående kan forstå det.
- Problemet og målet er beskrevet før løsningen.
- Første version er delt op i "skal med" og "kan vente".
- Systemer og data som løsningen skal arbejde sammen med, er nævnt, også dem du er usikker på.
- Budgetinterval og deadline står der, med en begrundelse for deadlinen.
- Én beslutningstager er udpeget og har tid til projektet.
- Du har skrevet hvad du vil have tilbage og en svarfrist.
- Alle udviklere får samme version.
Send beskrivelsen til 2-4 udviklere. Har du ikke nogen i tankerne, har jeg samlet de steder hvor du kan finde en udvikler og hvad hvert sted er godt til. Når tilbuddene er kommet, kan du bruge spørgsmålene til en udvikler før du hyrer til at vælge mellem dem.
Vil du vide hvordan jeg prissætter før du sender noget, kan du læse om forprojekt og fast pris på min side om priser.
Ofte stillede spørgsmål
Hvad gør jeg hvis jeg ikke kender mit budget?
Start med hvad problemet koster dig i dag, fx timer brugt på manuelt arbejde eller kunder du mister, og hvad det er værd at løse det. Det giver et loft. Du kan også bede udviklerne om et groft interval for to niveauer: en enkel første version og en mere komplet løsning. Så ser du hvad forskellen koster før du lægger dig fast.
Skal jeg vedhæfte skitser eller skærmbilleder?
Ja, gerne, men skriv at de er eksempler og ikke krav. En skitse på papir eller et skærmbillede af et system du kan lide, gør det nemmere at forstå hvad du mener. Problemet opstår når skitsen bliver læst som en bestilling. Så prissætter udvikleren præcis det du har tegnet, også de dele der kunne løses enklere.
Skal jeg betale for at få et tilbud?
Et groft interval ud fra en projektbeskrivelse er som regel gratis. Kræver en mere præcis pris at udvikleren analyserer dine systemer, læser eksisterende kode eller afklarer første version sammen med dig, er det normalt et betalt forløb. Det er rimeligt fordi arbejdet tager tid, og resultatet kan du bruge uanset hvem der ender med at bygge løsningen.
Skal udvikleren skrive under på en NDA før jeg sender beskrivelsen?
Sjældent. En projektbeskrivelse på 1-2 sider indeholder typisk ikke noget der kræver beskyttelse, og selve idéen er sjældent det værdifulde. Har du forretningshemmeligheder, så hold detaljerne ude af den første version og del dem først når du har valgt en eller to udviklere og har en aftale om fortrolighed på plads.