Ekstern CTO - Kravspecifikation til webshop-projekt - den komplette tjekliste
Alle punkter du skal have med i din projektbeskrivelse inden du kontakter en udvikler. Virker til alle typer webshop-opgaver. Krydser gemmes lokalt.
- Forfatter
- Kasper Stück
- Dato
- Laesetid
- 8 min
- Niveau
- Begynder
Denne tjekliste er bygget til at hjælpe dig med at samle en komplet projektbeskrivelse inden du kontakter en udvikler. Dine krydser gemmes lokalt i din browser, så du kan arbejde dig igennem listen over flere dage.
Det gælder uanset hvad dit projekt er: en ny funktion, en integration, en designændring, en migrering eller noget helt andet. Punkterne er universelle fordi de handler om kommunikation, ikke om teknologi.
Top tip
Læs den tilhørende guide til kravspecifikation af webshop-projekter parallelt med tjeklisten. Guiden forklarer hvert punkt i dybden med eksempler, så du forstår hvorfor det er vigtigt.
Du behøver ikke have svar på alt. En ufuldstændig beskrivelse med konkrete eksempler er bedre end ingen beskrivelse. Men jo flere punkter du kan dække, jo mere præcis en pris - og jo færre overraskelser undervejs.
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.
Tjekliste
0 af 43 fuldfoert
Problemet og baggrunden
Start her. Uden et klart problem ender projektet med at løse det forkerte.
- Hvad fungerer ikke? Hvad mangler? Hvad er besværligt? Vær konkret - 'mister salg fordi kunder ikke kan bestille decimaler' er bedre end 'shoppen virker ikke ordentligt'.
- Er det dine kunder, dine medarbejdere, dig selv - eller alle tre? Udvikleren prioriterer anderledes afhængigt af hvem der rammes.
- Tabt salg, spildtid, fejl i ordrer, utilfredse kunder, manuelle workarounds. Gerne med tal: '10 timer om ugen på manuel indtastning' eller '5 fejlleveringer om måneden'.
- Apps, leverandører, workarounds, andre løsninger der ikke virkede. Det sparer udvikleren for at foreslå noget du allerede har afvist.
Nuværende situation
Udvikleren skal forstå hvad du har i dag - ellers bygger de noget der ikke passer.
- Shopify, Hostedshop, WooCommerce, Magento, DanDomain, custom? Kender du ikke svaret, spørg din nuværende leverandør.
- Hvilke systemer bruger du i dag? Eller styrer du alt manuelt? Begge dele er relevant information.
- QuickPay, Stripe, Nets, Shopify Payments, Klarna, MobilePay - hvilke bruger du?
- Alt der allerede er installeret eller tilpasset. Også ting lavet af en tidligere leverandør. Udvikleren skal vide hvad der kan påvirkes.
- Bureau, freelancer, medarbejder? Ændringer skal koordineres, så udvikleren skal vide hvem der rører hvad.
- e-mærket, cookie-samtykke, GDPR, handelsbetingelser, tilgængelighed, aldersverifikation. Du behøver ikke kende alle regler - men nævn hvad du ved.
Brugerrejsen
Beskriv trin-for-trin hvad kunden eller medarbejderen skal opleve. Det er kernen i en god projektbeskrivelse.
- Hvilken side lander de på? Hvad er det første de ser?
- Klikke, vælge, indtaste, uploade? Beskriv hvert trin i rækkefølge.
- En pris, en bekræftelse, en opdateret kurv, en statusbesked?
- I kurven, ved checkout, på ordrebekræftelsen, i en mail, internt hos dig. Tænk hele flowet igennem.
Regler, logik og eksempler
Dine forretningsregler er naturlige for dig, men usynlige for udvikleren. Skriv dem ned - og giv konkrete eksempler med tal.
- Pr. stk., pr. m², pr. kg, pr. kasse, pr. løbende meter? Inkl. eller ekskl. moms? Faste priser eller beregnet ud fra input?
- Hvis forskellige produkter fungerer forskelligt (fx ruller vs. kasser vs. stykvis), beskriv hver type for sig.
- Er der minimum? Rabatgrænser? Særlige priser for bestemte kundegrupper (B2B)?
- Gratis fragt over X kr.? Returregler? Kan rabatkoder kombineres?
- Fx: 'Tæppe 249 kr/m², 300×420 cm = 12,6 m² = 3.137,40 kr.' Eksempler afslører misforståelser med det samme.
- Et ulige tal, en stor mængde, et grænsetilfælde. Det er her fejl oftest opstår.
Hvad kan gå galt?
Når noget usædvanligt sker og det ikke er beskrevet, gætter udvikleren. Du behøver ikke have alle svar, men tænk scenarierne igennem.
- 0, bogstaver, negative tal, tomme felter, dobbeltklik. Skal der vises en fejlbesked? Skal input blokeres?
- Skjules de? Vises de med 'udsolgt'? Kan kunden tilmelde sig en venteliste?
- Hvad med priser der var beregnet? Rabatkoder der blev brugt? Delvis returnering?
- Lager-API, betalingsgateway, ERP. Skal ordrer sættes i kø? Skal kunden få besked?
- Langt de fleste webshop-kunder handler fra mobil. Beskriv hvis der er noget der skal fungere anderledes på en lille skærm.
- Skal rabatkoder virke ovenpå beregnede priser? Kan de kombineres med udsalg?
Eksempler, skærmbilleder og inspiration
Billeder og links siger mere end tekst. Find inspiration og vis hvad du mener.
- Link til dem. Beskriv hvad du kan lide - og hvad du ville gøre anderledes.
- Markér med pile eller cirkler hvad der skal ændres. Læg dem ind i dokumentet - ikke som separate filer.
- Vis det ønskede resultat visuelt. En skitse tegnet på papir og fotograferet er også fint.
Drift, deadline og prioritering
Den praktiske ramme der afgør hvordan løsningen bygges og leveres.
- Dig, en medarbejder, et bureau? Det påvirker hvordan løsningen bygges - en løsning kun udvikleren kan ændre er billigere at bygge men dyrere at leve med.
- Tilføje produkter med den nye funktion? Ændre priser? Justere regler? Eller er det en 'sæt op én gang og lad det køre'-løsning?
- Skal der laves en kort vejledning? Skal udvikleren demonstrere løsningen?
- Sæsonstart, kampagne, ny kollektion, investor-præsentation. Også 'ingen hast' er nyttig information.
- Selv et bredt interval (fx 10.000-25.000 kr.) hjælper udvikleren med at foreslå en løsning der passer. Uden budget-ramme risikerer du et tilbud der er langt over eller under hvad du havde i tankerne.
- Er det dig der siger ja? Eller skal en chef, partner eller bestyrelse godkende? Det påvirker tidsplanen.
- Kan du give udvikleren adgang til platformen? Til lagersystemet? Til det design der skal ændres?
- Uden disse funktioner giver projektet ikke mening. Det er dem der løser kerneproblemet.
- Vigtige forbedringer der gør løsningen bedre, men som ikke blokerer for lancering.
- Nice-to-have funktioner. Inkludér dem så udvikleren kan estimere dem separat.
- Hvis du har valgt noget fra, skriv det. Det forhindrer at udvikleren bygger noget du aldrig bad om.
- Produkttekster, billeder, logoer, data-filer. Hvem leverer hvad, og hvornår? Manglende indhold er den hyppigste årsag til forsinkelser.
- Hvad skal være opfyldt for at du godkender? Fx 'en kunde kan gennemføre et køb fra mobil uden fejl' eller 'lageret opdateres automatisk inden 5 minutter'.
- Hvem gennemgår løsningen for fejl? Hvor lang tid er der til test? En uge med test inden go-live er bedre end at opdage problemer med rigtige kunder.
Fremgang gemmes lokalt i din browser.
