Spørgsmål til en webudvikler før du skriver under
Du vurderer nogen, der skal levere arbejde, du ikke selv kan verificere. Løsningen er ikke at blive mere teknisk, men at stille spørgsmål, hvis svar kan vurderes uden teknisk viden.
Denne guide giver de spørgsmål, grupperet efter fase, med hvad et stærkt svar indeholder.
Om proces og samarbejde#
Disse spørgsmål forudsiger projektets forløb mere end noget teknisk spørgsmål.
- Hvordan forløber et typisk projekt hos jer? Et stærkt svar nævner faser, beslutningstidspunkter og hvad der forventes af dig.
- Hvem arbejder reelt på det, og hvor mange projekter har den person sideløbende? Det forudsiger tidsplanen bedre end tidsplanen.
- Hvor ofte taler vi sammen, og hvordan? Vage svar her bliver til stilhed senere.
- Hvad har I brug for fra mig, og hvornår? Den der svarer præcist på det, har set projekter blive forsinket af indhold.
- Hvad sker der, hvis vi vil ændre noget undervejs? Der bør være en procedure, ikke et «det finder vi ud af».
- Fortæl om et projekt der gik galt. Svaret «det har vi ikke haft» er i sig selv et svar.
Om teknik og valg#
Du behøver ikke forstå teknikken; du skal kunne vurdere, om nogen kan forklare sine valg.
| Spørgsmål | Hvad et stærkt svar indeholder |
|---|---|
| Hvad bygger I det på, og hvorfor? | En grund koblet til din situation |
| Hvad kan jeg selv ændre efter lanceringen? | En konkret liste, ikke «alt» |
| Hvordan sikrer I at det bliver hurtigt? | Konkrete tiltag og målinger |
| Hvordan håndterer I mobil? | Designe fra mobilen, ikke «den er responsiv» |
| Hvad gør I ved tilgængelighed? | En standard og hvordan de kontrollerer den |
| Hvad gør I ved sikkerhed? | Opdateringer, backup, adgange, HTTPS |
| Bruger I færdige temaer eller bygger I? | Et ærligt svar med afvejningen |
Læg mærke til om svarene knyttes til din situation eller forbliver generelle. «Vi bruger altid X» siger mindre end «til det du har brug for, passer X, fordi».
Om indhold, SEO og lancering#
Det område hvor projekter oftest bliver forsinket, og hvor forudsætninger oftest divergerer.
- Hvem skriver teksterne? Det er samtalens vigtigste spørgsmål og det, der oftest springes over.
- Hvem leverer billederne, og er billeddatabase med?
- Hvem taster indholdet ind i systemet? Ved to hundrede sider er det reelt arbejde.
- Hvad gør I med de eksisterende adresser? Svaret skal indeholde viderestillinger. Gør det ikke det, er det et problem.
- Hvad er med i SEO? Det tekniske hører til projektet; indholdsstrategi er separat.
- Hvordan tester I før lanceringen? Der bør være et testmiljø og en liste.
- Hvad sker der på lanceringsdagen, og hvem er tilgængelig?
- Får jeg oplæring eller dokumentation?
Om tiden efter levering#
De spørgsmål der afgør, om du er tilfreds om to år, og dem der stilles mindst under salget.
| Spørgsmål | Hvorfor det tæller |
|---|---|
| Hvad koster driften om måneden? | Forhindrer en overraskelse kort efter lanceringen |
| Hvad omfatter driften? | «Drift» uden liste betyder lidt |
| Hvor hurtigt svarer I ved nedbrud? | Sætter forventningen nu, ikke under nedbruddet |
| Hvad hvis jeg vil fortsætte med en anden? | Tester overdragelsen |
| Hvis er koden og hostingen? | Spørg om det før underskrift |
| Hvad sker der hvis I lukker? | Mere relevant ved freelancer eller lille bureau |
| Hvem har adgang til mine konti? | Skal tilbage til dig til sidst |
Ofte stillede spørgsmål
Hvilket spørgsmål er vigtigst?
«Hvem skriver teksterne?» Indhold forsinker flere webprojekter end nogen teknisk faktor, og begge parter antager for ofte, at det er den anden. Er svaret «jer», så spørg hvornår det skal være klar, og hvad der sker ved forsinkelse — og sørg for at det står i aftalen.
Skal jeg stille tekniske spørgsmål, når jeg ikke kan vurdere svaret?
Ja, men vurdér forklaringen frem for indholdet. Den der kan forklare et valg på almindeligt dansk og nævne dets ulemper, forstår hvad han laver. Den der gemmer sig bag jargon eller aldrig nævner en ulempe, er risikoen. Den skelnen klarer du uden teknisk viden.
Er det rimeligt at bede om referencer?
Fuldstændig, og ring faktisk til én. Spørg ikke om de var tilfredse, men hvad der gik galt, og hvordan det blev løst, og hvordan samarbejdet var efter lanceringen. Det sidste er det mest forudsigende spørgsmål og det mindst stillede — før lanceringen er alle tilgængelige.
Hvad hvis leverandøren bliver irriteret over spørgsmålene?
Det er i sig selv svaret. Det er almindelige spørgsmål fra en kunde, der bruger et betydeligt beløb, og professionelle forventer dem. Irritation ved rimelige spørgsmål før underskrift forudsiger, hvordan det bliver, når du rapporterer et problem efter lanceringen.
spørgsmål webudviklervælge webbureauspørgsmål ved tilbud hjemmesidevurdere udviklerstarte webprojektvælge leverandør
