Guide - 12 kapitler - Sådan beskriver du dit webshop-projekt - guide til en god kravspecifikation

To ud af tre IT-projekter overskrider budget eller tidsplan. Den hyppigste årsag? Uklare krav. En fejl der fanges i planlægningen koster én gang at rette. Opdages den efter udviklingen er i gang, koster den 10 gange mere. Opdages den efter lancering, koster den 30-100 gange mere.

Den gode nyhed: du behøver ikke være teknisk for at skrive en god projektbeskrivelse. Du skal bare beskrive dit problem, dine regler og din ønskede oplevelse tydeligt nok til at en udenforstående forstår det.

Når du kontakter en udvikler med “jeg skal bruge X” i en mail, er det sjældent nok til at få en pris. Ikke fordi udvikleren er besværlig, men fordi den samme sætning kan betyde vidt forskellige opgaver.

Guiden har en parallel komplet tjekliste med alle konkrete kontrolpunkter, så du kan arbejde dig igennem punkt for punkt.

Nogle eksempler på sætninger der lyder simple men kan dække over timer eller ugers forskel i arbejde:

• “Jeg skal bruge en prisberegner” kan betyde et simpelt inputfelt - eller en avanceret konfigurator med regler, undtagelser og automatisk prisudregning.
• “Vi skal have integreret lagersystemet” kan betyde en daglig synkronisering - eller en real-time integration med fejlhåndtering og kø-system.
• “Checkout skal ændres” kan betyde en lille tekstændring - eller et helt nyt flow med nye felter og betalingsmetoder.
• “Designet skal opdateres” kan betyde en ny farve og font - eller en komplet omstrukturering af navigation og layout.

Jo bedre du beskriver hvad du har brug for, jo mere præcis en pris - og jo færre overraskelser undervejs.

1. Start med problemet - ikke løsningen

Den vigtigste ting du kan gøre er at forklare hvorfor du har brug for noget. Hvad fungerer ikke i dag, og hvad er konsekvensen?

De fleste starter med løsningen: “Jeg skal bruge en app der kan X.” Men udvikleren skal forstå problemet for at kunne foreslå den bedste løsning - som måske er en helt anden end den du havde i tankerne.

Svagt: “Jeg skal bruge en omregner til m²-priser.”

Stærkt: “Vores webshop tillader kun hele tal i mængdefeltet. Kunderne kan ikke bestille fx 12,32 m² - de kan kun skrive 12 eller 13. Det betyder at mange ringer ind i stedet for at bestille online, og vi mister de kunder der ikke gider ringe.”

Svagt: “Vi skal have integreret vores ERP.”

Stærkt: “Vi bruger 10 timer om ugen på at taste ordrer manuelt ind i lagersystemet. Det giver fejl i ca. 5 ordrer om måneden - forkerte varer sendt, forkert antal, eller varer der viser som på lager men er udsolgt.”

Spørg dig selv: Hvad er problemet? Hvem er berørt? Hvad er konsekvensen i tabt tid, penge eller kunder?

2. Beskriv hvad der sker i dag

Giv udvikleren et billede af din nuværende situation. Hvad har du, hvad virker, og hvad virker ikke?

Det gælder også tidligere forsøg. Hvis du har prøvet noget der ikke virkede - en app, en leverandør, en anden løsning - så sig det. Det sparer alle for tid.

For eksempel:

• “Vi har 450 produkter i Hostedshop. Lageret styres manuelt i et Excel-ark.”
• “Vores nuværende leverandør siger det ikke kan lade sig gøre i vores platform.”
• “Vi har prøvet appen X, men den kunne ikke håndtere vores prisstruktur.”
• “Vi kører i dag et tema der er tilpasset af et bureau for 2 år siden.”

Det lyder måske ubetydeligt, men det giver udvikleren kontekst til at foreslå den rigtige løsning - og undgå de samme blindgyder du allerede har ramt.

3. Beskriv hvad brugeren skal opleve

Forestil dig at du er kunden (eller medarbejderen der skal bruge løsningen). Beskriv trin-for-trin hvad der skal ske.

Det her er kernen i en god projektbeskrivelse. Du behøver ikke tænke teknisk - bare beskriv hvad brugeren gør, og hvad der sker.

Eksempel - prisberegner på produktside:

1. Kunden ser produktet med pris pr. m²
2. Kunden vælger bredde fra en dropdown
3. Kunden indtaster ønsket længde i cm
4. Prisen beregnes og vises automatisk
5. Kunden klikker “Læg i kurv”
6. I kurven står mål, m² og pris

Eksempel - automatisk lageropdatering:

1. Kunde bestiller i webshoppen
2. Ordren sendes automatisk til lagersystemet
3. Lageret pakker og markerer som sendt
4. Kunden får automatisk en mail med tracking-info
5. Lagerbeholdningen opdateres i webshoppen

Eksempel - nyt design på produktsider:

1. Kunden lander på produktsiden
2. Øverst ses et stort produktbillede med galleri
3. Til højre ses pris, varianter og “Læg i kurv”
4. Under billedet er der faner: Beskrivelse, Specifikationer, Anmeldelser
5. Nederst vises relaterede produkter

Spørg dig selv: Hvad ser brugeren først? Hvad gør de? Hvad skal de se som resultat? Hvad sker bagefter - i kurven, ved checkout, på ordrebekræftelsen, internt hos dig?

4. Forklar reglerne

Hver webshop har forretningsregler. De er måske så naturlige for dig at du glemmer at nævne dem. Men udvikleren kender dem ikke - og gætter forkert hvis de ikke er beskrevet.

Skriv reglerne ned som de er. Du behøver ikke tænke på om det er teknisk muligt - det er udviklerens job.

Typiske regler du bør beskrive:

• Pris: Hvordan beregnes prisen? Pr. stk., pr. m², pr. kg, pr. kasse? Inkl. eller ekskl. moms?
• Minimumsbestilling: Skal kunden købe mindst X antal?
• Mængderabat: Er der rabat ved større mængder? Hvordan er den struktureret?
• Kundepriser: Har forskellige kundegrupper forskellige priser?
• Lager: Hvornår er noget “udsolgt”? Kan man bestille varer der ikke er på lager?
• Fragt: Er der gratis fragt over X kr.? Særlig fragt for store/tunge varer?
• Returnering: Hvad er reglerne for retur?
• Rabatkoder: Kan de kombineres? Gælder de ovenpå andre rabatter?

Hvis du sælger produkter med varianter (farver, størrelser, materialer), beskriv hvilke varianter der findes og om de påvirker prisen.

5. Giv konkrete eksempler med tal

Eksempler med rigtige tal er mere værd end en halv sides forklaring. De afslører misforståelser med det samme - og giver udvikleren noget konkret at bygge ud fra.

Eksempel - prisberegner:

Tæppe koster 249 kr/m². Kunden vælger 300 cm bred, 420 cm lang. Det er 3,00 × 4,20 = 12,6 m² × 249 kr = 3.137,40 kr.

Eksempel - kasseberegning:

Gulv sælges i kasser à 2,18 m². Kunden skal bruge 15 m². 15 / 2,18 = 6,88 kasser → rund op til 7 kasser × 589 kr = 4.123 kr.

Eksempel - mængderabat:

Under 10 stk: 99 kr/stk. 10-49 stk: 89 kr/stk. 50+ stk: 79 kr/stk. Kunde bestiller 25 stk = 25 × 89 kr = 2.225 kr.

Eksempel - fragtberegning:

Under 500 kr: 49 kr fragt. Over 500 kr: gratis. Over 30 kg: 149 kr uanset ordrestørrelse.

Giv mindst 2-3 eksempler der dækker de mest typiske situationer. Inkludér gerne et eksempel med et “mærkeligt” scenarie - fx et ulige tal, en stor mængde, eller en minimumsbestilling.

6. Hvad kan gå galt?

Det her er der de dyreste fejl opstår. Når noget usædvanligt sker og det ikke er beskrevet, gætter udvikleren. Og gætter ofte forkert - fordi det der er oplagt for dig, er usynligt for en der ikke kender din forretning.

Du behøver ikke have svar på alt. Men tænk scenarierne igennem og skriv dem ned - så kan udvikleren spørge ind til de vigtigste.

Universelle scenarier der gælder de fleste projekter:

Du kan udfylde tabellen, eller bare skrive dem som en liste med noter. Pointen er at de er tænkt igennem - ikke at de er perfekt formuleret.

7. Find eksempler og tag skærmbilleder

Billeder og links siger mere end tekst. Hvis du har set en anden webshop der gør noget lignende det du vil have, så del det.

Sådan gør du:

1. Find 1-3 webshops med noget lignende
2. Tag skærmbilleder af de relevante sider
3. Markér gerne med pile eller cirkler hvad du mener
4. Beskriv hvad du kan lide - og hvad du ville gøre anderledes

Det gælder også for ting i din egen shop. Tag et skærmbillede af din produktside og skriv “her skal det ændres” med en pil. Det er langt nemmere at forstå end en tekst-beskrivelse.

Eksempler er relevante for alle projekttyper: en anden shops checkout, et konkurrents produktfilter, et ERP-systems ordrevisning, eller bare en skitse du har tegnet på papir og fotograferet.

8. Beskriv dit tekniske setup

Udvikleren skal vide hvad der allerede er på plads, og hvad der ikke kan ændres. Kender du ikke svarene? Spørg din nuværende leverandør - det er helt ok.

Besvar disse:

• Hvilken webshop-platform? (Shopify, Hostedshop, WooCommerce, Magento, custom?)
• Lagersystem, ERP eller regnskabsprogram? (Og hvilket?)
• Betalingsløsning? (QuickPay, Stripe, Nets, Shopify Payments?)
• Er der eksisterende integrationer, apps eller plugins?
• Er der et bestemt tema eller design installeret?
• Er der tilpasninger lavet af en tidligere leverandør?
• Kan du give login/adgang til platformen?

Giv også udvikleren kontekst om hvem der ellers arbejder med shoppen. Er der et bureau der vedligeholder temaet? En freelancer der håndterer annoncering? Det er vigtigt at vide, så ændringer ikke ødelægger noget eksisterende.

Nævn også hvis der er lovkrav eller compliance der er relevante. Skal shoppen overholde e-mærkets krav? Er der cookie-samtykke der skal håndteres? Sælger du aldersrelaterede produkter? Har du handelsbetingelser der skal integreres i checkout? Du behøver ikke kende alle reglerne - men nævn det du ved, så udvikleren kan tage højde for det.

9. Hvad skal der ske bagefter?

Et projekt slutter ikke ved lancering. Fortæl hvem der skal stå for den daglige drift - det påvirker hvordan løsningen bygges.

Besvar disse:

• Hvem skal bruge løsningen til daglig? (dig, en medarbejder, et bureau?)
• Skal du selv kunne tilføje, redigere eller justere ting bagefter?
• Er der noget der ændrer sig løbende? (priser, produkter, regler?)
• Skal medarbejdere instrueres i at bruge det?
• Hvem kontakter du hvis noget går i stykker?

Det gør en reel forskel. En løsning kun udvikleren kan ændre er billigere at bygge - men dyrere at leve med. Omvendt koster det mere at bygge noget du selv kan vedligeholde, men det betaler sig hurtigt.

Tænk også over om der er indhold eller materialer du skal levere. Skal du skrive produkttekster, levere billeder, skaffe logoer eller forberede data i et bestemt format? Den hyppigste årsag til forsinkelser i webshop-projekter er at indholdet ikke er klar. Aftal tidligt hvem der leverer hvad - og hvornår.

10. Prioritér: SKAL, BØR, KAN

Alt kan ikke være lige vigtigt. Opdel dine ønsker i tre kategorier:

Det er helt ok at starte med SKAL-listen og udvide senere. Et projekt der leverer det vigtigste rigtigt er langt bedre end et projekt der forsøger alt på én gang og ender halvfærdigt.

Husk også at nævne hvad der ikke skal med. Hvis du bevidst har valgt noget fra, så skriv det. Det forhindrer at udvikleren bygger noget du aldrig bad om.

Tænk også over hvornår projektet er “færdigt”. Hvad skal være opfyldt for at du godkender leverancen? Det behøver ikke være teknisk - det kan være så simpelt som “en kunde kan gennemføre et køb fra mobil uden fejl” eller “lagerbeholdningen opdateres automatisk inden for 5 minutter”. Klare acceptkriterier forhindrer uenighed om hvornår noget er leveret.

Aftal også hvem der tester løsningen inden den går live, og hvor lang tid der er til at finde fejl. En uge med test inden lancering er bedre end at opdage problemer med rigtige kunder.

Praktisk: Sådan sender du det

1. Saml det i ét dokument. Word, Google Docs, Notion - ligegyldigt. Ikke spredt over 8 mails og 3 telefonsamtaler. Dokumentet er sandheden.

2. Læg skærmbilleder ind i dokumentet. Ikke som separate filer der bliver væk i en mappe.

3. Send det samlet. Udvikleren skal kunne læse hele beskrivelsen fra start til slut i ét hug.

4. Forvent spørgsmål. En god udvikler stiller opklarende spørgsmål. Det er et godt tegn - det betyder de har læst det og tænker med. Tilføj svarene til dokumentet.

5. Giv deadline og budget-interval. Det behøver ikke være præcist, men “inden august” og “10.000-20.000 kr.” giver udvikleren noget at arbejde ud fra.

6. Nævn hvem der beslutter. Er det dig der siger ja til løsningen, eller skal en chef, partner eller bestyrelse godkende? Det påvirker processen.

Husk

• Du behøver ikke skrive alt perfekt. En ufuldstændig beskrivelse med konkrete eksempler er bedre end en “perfekt” tekst uden detaljer.

• Skriv hvad du VED. Og skriv ærligt hvad du IKKE ved. Begge dele er nyttige.

• Jo bedre beskrivelse, jo bedre pris. En vag beskrivelse giver enten en høj pris (udvikleren sikrer sig) eller en lav pris der eksploderer i tillæg undervejs.

Brug tjeklisten som kontrolpunkt inden du sender - den sikrer at du har fået det hele med.

Har du brug for hjælp til at formulere krav eller kvalitetssikre en projektbeskrivelse? Som ekstern CTO hjælper jeg webshop-ejere med at få styr på kravene inden de kontakter leverandører - så tilbuddet matcher virkeligheden.