Webudvikling
Sådan vælger du en webudvikler til din lille virksomhed
Få en praktisk metode til at vurdere webudviklere, sammenligne tilbud og aftale ansvar, adgang, test og hjælp efter lancering.
- Forfatter
- Mathias Kjær Pedersen, MKP Digital
- Udgivet
- Udgivet
- Læsetid
- 10 min. læsetid
Vælg en webudvikler, som kan forstå den opgave, hjemmesiden skal løse, og omsætte den til en tydelig leverance. Den rette kandidat kan vise relevant arbejde, forklare sine valg i almindeligt sprog og skrive ned, hvad der er med, hvad der ikke er med, og hvad der sker efter lanceringen.
Vælg ikke ud fra portfolio eller pris alene. Et flot eksempel fortæller ikke, hvilken del udvikleren stod for, og to tilbud kan dække vidt forskellige opgaver. Se i stedet efter sammenhæng mellem dit behov, personens erfaring, arbejdsformen og den aftale, du får.
Afklar opgaven før du vurderer kandidater
Du behøver ikke have en færdig kravspecifikation. Du skal dog kunne forklare, hvilken forretningsopgave hjemmesiden skal støtte. Det kan være at skaffe kvalificerede henvendelser, gøre booking enkel, sælge varer eller give eksisterende kunder adgang til bestemte oplysninger.
Skriv et kort oplæg med disse oplysninger.
- Hvem hjemmesiden er til
- Hvad den vigtigste besøgende skal kunne gøre
- Hvilket indhold og materiale der allerede findes
- Hvilke funktioner der er nødvendige ved lancering
- Hvad der kan vente til en senere version
- Hvem hos virksomheden der kan træffe beslutninger og godkende indhold
- Kendte rammer for budget og lanceringsdato
Hvis indholdet og funktionerne stadig er uklare, kan guiden om hvad en lille virksomheds hjemmeside bør indeholde hjælpe med at skille behov fra ønsker.
En udvikler må gerne hjælpe med at afklare opgaven. Tilbuddet bør så vise, hvilke antagelser prisen og tidsplanen bygger på. Ellers bliver et tidligt pristal let opfattet som et løfte, selv om væsentlige dele af arbejdet endnu er ukendte.
Vælg den rigtige type leverandør først
Ordet webudvikler dækker over forskellige profiler. Nogle arbejder primært med websites i en bestemt platform. Andre bygger integrationer, kundeportaler eller specialudviklede systemer. En dygtig specialist kan derfor være et dårligt match til en opgave uden for vedkommendes område.
En standardplatform kan være tilstrækkelig, når virksomheden har få stabile sider, almindelige formularer og ingen særlige arbejdsgange. I den situation kan det rigtige valg være en platformspecialist eller at bygge siden selv. Specialudvikling er mere relevant, når en konkret funktion, integration eller arbejdsgang ikke kan løses forsvarligt med en standardskabelon og eksisterende tjenester.
Opgavens størrelse afgør også, om én person kan løfte den, eller om flere fagligheder skal arbejde samtidigt. Brug sammenligningen af freelance webudvikler og webbureau, hvis du først skal vælge leverandørmodel.
Bed om beviser der ligner din opgave
Se efter projekter med en relevant type opgave eller kompleksitet. Brancheerfaring kan være nyttig, men er ikke altid nødvendig. En udvikler, som kan forklare et lignende bookingflow, en indholdstung hjemmeside eller en integration, kan være mere relevant end en kandidat med mange pæne forsider fra din branche.
Bed kandidaten gennemgå et eller to konkrete projekter og forklare følgende.
- Hvad kunden skulle opnå
- Hvilken del kandidaten selv havde ansvar for
- Hvilke begrænsninger projektet havde
- Hvorfor løsningen blev valgt
- Hvordan siden blev testet og afleveret
- Hvad kandidaten ville gøre anderledes i dag
Spørg kun efter målbare resultater, når kandidaten faktisk havde adgang til data og må dele dem. Et udsagn om flere henvendelser eller bedre synlighed er ikke dokumentation i sig selv. Et ærligt svar kan være, at leverandøren byggede og testede løsningen, mens kunden selv målte forretningseffekten.
Åbn de viste websites på både telefon og computer. Prøv navigation og centrale handlinger, men send ikke testdata gennem en anden virksomheds formular. Husk også, at et website kan være ændret efter den oprindelige levering. Brug derfor gennemgangen som et udgangspunkt for spørgsmål, ikke som et endeligt kvalitetsbevis.
Brug den første samtale som en arbejdsprøve
En god indledende samtale gør usikkerheder synlige. Udvikleren bør spørge til kunder, indhold, arbejdsgange, ansvar og drift, før teknologien bliver gjort til svaret.
Stil de samme spørgsmål til alle kandidater.
- Hvad mener du er den vigtigste opgave i projektet
- Hvilke dele bør løses med en standardfunktion frem for specialudvikling
- Hvad mangler du at vide for at kunne give en holdbar pris og tidsplan
- Hvem skal skrive, levere og godkende indholdet
- Hvordan opdager vi tidligt, hvis løsningen er på vej i en forkert retning
- Hvem udfører arbejdet, og bruges der underleverandører
- Hvordan ser kommunikationen ud fra opstart til lancering
Vurder ikke kun, om svarene lyder tekniske. Vurder, om de er konkrete, forståelige og knyttet til din opgave. En kandidat, der er enig i alle ønsker uden at nævne konsekvenser, giver ikke nødvendigvis den bedste rådgivning.
Sammenlign samme leverance
Bed om et skriftligt tilbud, der opdeler arbejdet. Et samlet beløb er kun sammenligneligt, når tilbuddene omfatter de samme dele.
Kontrollér blandt andet disse punkter.
- Afklaring, informationsstruktur og design
- Antal sidetyper og aftalte funktioner
- Tekst, billeder, oversættelse og indtastning af indhold
- Mobilvisning og relevante browsere
- Grundlæggende teknisk SEO og metadata
- Tilgængelighedsmål og test
- Formularer, integrationer og dataflytning
- Hosting, domæne, licenser og andre løbende udgifter
- Antal korrekturrunder og godkendelser
- Lancering, oplæring, dokumentation og overdragelse
- Fejlrettelser, support og videreudvikling efter lancering
Guiden om prisen på en hjemmeside til en lille virksomhed gennemgår, hvordan du sammenligner førsteårsudgifter og finder forskelle mellem tilbud.
Et dyrere tilbud kan være det bedste valg, hvis det indeholder nødvendigt arbejde, som de andre har udeladt. Et billigere tilbud kan være helt rigtigt, hvis opgaven reelt er mindre. Bed leverandøren gøre fravalg og ekstraudgifter synlige, så du ikke skal gætte.
Få ansvar og ændringer på skrift
Aftalen skal passe til projektets størrelse, men selv en mindre hjemmeside har brug for klare rammer. Få følgende forhold beskrevet, før arbejdet begynder.
- Leverancer og tydelige afgrænsninger
- Milepæle, kundens frister og afhængigheder
- Pris, betalingsplan og eventuelle løbende udgifter
- Hvordan nye ønsker og ændringer bliver vurderet og godkendt
- Hvilke brugsrettigheder, filer og adgange virksomheden modtager
- Hvem der retter fejl, i hvilken periode og på hvilke vilkår
- Hvordan aftalen kan afsluttes, og hvad en overdragelse omfatter
Hvis du også skal vælge betalingsmodel, gennemgår guiden om fast pris og timepris på webprojekter, hvornår et kendt omfang eller reelle ubekendte gør den ene model mere passende.
Få juridisk rådgivning, hvis rettigheder, persondata, ansvar eller opsigelse har væsentlig betydning for virksomheden. En udviklers forklaring kan hjælpe dig med at forstå den tekniske leverance, men den erstatter ikke juridisk vurdering af kontrakten.
Bevar kontrol over domæne og centrale konti
Virksomheden bør have kontrol over sit domæne og de konti, der er nødvendige for at drive eller flytte hjemmesiden. En leverandør kan godt administrere dem i det daglige uden at være den eneste, der kan logge ind eller godkende en overførsel.
ICANN beskriver registranten som den person eller virksomhed, der indgår aftalen med registratoren og administrerer domænets indstillinger. Kontrollér derfor, hvem der står som registrant, hvordan domænet fornyes, og hvem der kan flytte det. Se ICANNs information til domæneregistranter.
Lav en konkret liste over domæne, hosting, kode, CMS, analyseværktøjer, Search Console, e-mailtjenester og andre tredjepartskonti. Aftal, hvem der ejer aftalen med hver tjeneste, hvem der betaler, og hvilke adgange leverandøren får. Fjern adgange, der ikke længere er nødvendige, når samarbejdet slutter.
Hvis leverandøren behandler personoplysninger på virksomhedens vegne, skal roller, underleverandører og det nødvendige aftalegrundlag afklares. Datatilsynet understreger, at den dataansvarlige skal kende relevante underdatabehandlere og fortsat har ansvar gennem leverandørkæden. Se Datatilsynets afgørelse og vejledning om databehandlere. Få konkret rådgivning om den løsning, du køber.
Definér kvalitet som noget der kan kontrolleres
Ord som hurtig, brugervenlig og søgemaskineoptimeret er for brede til at fungere som acceptkriterier. Beskriv i stedet de vigtigste brugerrejser og den test, der skal vise, om de virker.
En enkel testplan kan omfatte følgende.
- Den vigtigste handling gennemføres på en almindelig telefon og computer
- Navigation, links og formularer bliver prøvet med realistiske testdata
- Fejlbeskeder og bekræftelser er forståelige
- Centrale funktioner kan bruges med tastatur
- Vigtigt indhold er læsbart ved relevante skærmstørrelser
- Metadata, deling og indeksering kontrolleres efter den aftalte SEO-opgave
- Ansvar for fejl og godkendelse er placeret før lanceringen
W3C anbefaler, at tilgængelighedsmål indgår i indkøb og accepttest, og at ansvar bliver fordelt tydeligt. Aftal derfor niveau, testform og eventuelle undtagelser i stedet for kun at skrive, at siden skal være tilgængelig. Se W3Cs plan for webtilgængelighed.
Vær kritisk over for SEO-løfter
En webudvikler kan arbejde med tekniske forudsætninger som struktur, metadata, mobilvisning og indeksering. Det giver ikke kontrol over en bestemt placering i søgeresultaterne.
Google skriver direkte, at ingen kan garantere en førsteplads, og anbefaler, at leverandøren forklarer sine ændringer og begrundelser. Vær derfor skeptisk over for garanterede placeringer, hemmelige metoder eller et tilbud, hvor SEO ikke er beskrevet konkret. Se Googles råd om at hyre SEO-hjælp.
Spørg, hvilke tekniske og redaktionelle opgaver der faktisk er med, hvem der leverer indholdet, og hvordan arbejdet bliver kontrolleret. Det gør et realistisk tilbud lettere at skelne fra en resultatgaranti, som leverandøren ikke kan styre.
Tegn du bør undersøge nærmere
Et enkelt faresignal behøver ikke afgøre valget, men flere uklare svar på centrale forhold øger risikoen.
- Kandidaten giver en fast pris på en uklar opgave uden at skrive antagelser
- Portfolioen viser projekter, men kandidatens egen rolle kan ikke forklares
- Tilbuddet siger ikke, hvem der udfører arbejdet
- Platformen vælges uden en forklaring af fordele, begrænsninger og mulighed for at skifte leverandør
- Domæne eller vigtige konti skal stå alene i leverandørens navn
- Løbende priser, licenser eller bindingsperioder er uklare
- Test, fejlrettelser og overdragelse er ikke beskrevet
- Leverandøren lover bestemte placeringer, salgstal eller andre resultater uden et dokumenterbart grundlag
- Du bliver presset til at acceptere, før væsentlige spørgsmål er besvaret
Proprietær teknologi er ikke automatisk et dårligt valg. Den kan løse en standardopgave effektivt. Du skal bare forstå, hvad du kan tage med, hvad et skifte kræver, og hvilke priser eller begrænsninger der gælder efter lanceringen.
En enkel beslutningsproces
Brug denne rækkefølge, når du er klar til at vælge.
- Beskriv hjemmesidens vigtigste opgave og det nødvendige omfang
- Vælg kandidater med erfaring, der ligner opgaven i type eller kompleksitet
- Giv dem samme oplæg og stil de samme spørgsmål
- Sammenlign skriftlige tilbud punkt for punkt
- Afklar adgang, rettigheder, test, support og mulighed for overdragelse
- Kontrollér en relevant reference, hvis projektets størrelse eller risiko gør det rimeligt
- Vælg den kandidat, der giver den mest troværdige vej til den aftalte leverance
Det sidste valg behøver ikke være den billigste eller mest avancerede kandidat. Det bør være den leverandør, hvis kompetencer og arbejdsform passer til opgaven, og hvis aftale efterlader færrest vigtige forhold til gætteri.