Referencer på en udvikler: 9 spørgsmål til tidligere kunder

Når du tjekker referencer på en udvikler, skal du spørge ind til hvad der skete i samarbejdet, ikke om kunden var tilfreds. Næsten alle referencer siger ja til det sidste. De spørgsmål der afslører noget, handler om pris i forhold til aftalen, dårlige nyheder, ændringer undervejs og hvem der sidder med koden bagefter.

Jeg er selv freelanceudvikler, så læs med det forbehold. Det er de spørgsmål jeg selv ville stille hvis jeg skulle hyre en udvikler til et vigtigt projekt.

Den korte version: 9 spørgsmål og hvad de afslører

Spørgsmålene er bygget til at få historier frem. En reference der skal fortælle hvad der skete, kan ikke nøjes med at svare "fint". Referencetjekket hører til sidst i processen når du har en eller to kandidater tilbage. Hele forløbet fra første behov til underskrevet aftale finder du i min guide til at hyre en udvikler.

Før du ringer: sådan får du ærlige svar

En reference vil som regel gerne hjælpe, men ingen har lyst til at tale en udvikler ned over for en fremmed. Din opgave er at gøre det let at være ærlig, og det gør du med lidt forberedelse og den rigtige form.

Har du allerede interviewet udvikleren, så tag dine noter med. Nogle af de bedste opfølgende spørgsmål opstår når du sammenligner referencens svar med det udvikleren selv har fortalt. Har du ikke holdt det møde endnu, så start med de spørgsmål du skal stille udvikleren selv.

Spørgsmål om projektet og forventningerne

1. Hvad skulle udvikleren løse for jer, og hvor stort var projektet?

Start med at finde ud af om referencen overhovedet kan bruges. Spørg hvad der blev bygget, hvor længe samarbejdet varede, og om det var et afgrænset projekt eller løbende udvikling. Du behøver ikke et præcist beløb, men en størrelsesorden hjælper: var det et par uger eller et helt år?

Et godt svar er konkret, fx "udvikleren byggede vores bookingsystem og integrationen til regnskabsprogrammet over cirka fire måneder". Et svar som "hun hjalp os med noget på hjemmesiden" er et advarselstegn i sig selv, for så ved du ikke hvad du sammenligner med. Skal du have bygget en SaaS, og har referencen fået lavet en enkel WordPress-side, så siger referencen noget om samarbejdet, men ikke om udvikleren kan løse din opgave.

2. Hvordan passede resultat og pris med det I aftalte fra start?

Meget få softwareprojekter ender præcis som aftalt, og det er ikke i sig selv et problem. Problemet opstår når kunden bliver overrasket. Spørg derfor ikke kun om prisen holdt, men også hvornår kunden fik at vide at den ikke gjorde.

Et godt svar lyder nogenlunde sådan her: "Vi endte over budgettet, men vi vidste det tidligt, og det var fordi vi selv lagde to funktioner til." Et dårligt svar handler om regninger der kom bag på dem, eller om en leverance der var mindre end aftalt uden at nogen sagde det højt.

Følg op med "hvornår hørte I første gang at det ville tage længere tid?" Svaret fortæller dig om udvikleren siger det ubehagelige med det samme eller venter til det ikke kan skjules længere.

3. Hvem talte I med, og hvor hurtigt fik I svar?

Spørg hvordan en almindelig uge så ud. Var der faste møder, korte statusbeskeder eller kun kontakt når kunden selv rykkede? Hvor lang tid gik der typisk før en mail blev besvaret?

Hør også efter hvem kunden faktisk talte med. Hos en freelancer bør svaret være udvikleren selv. Nævner referencen en kollega, en underleverandør eller en person der overtog efter opstarten, så spørg ind til det. Det er ikke forkert at bruge underleverandører, men du skal vide det før du skriver under, så du ved hvem der skriver din kode.

Spørgsmål om ansvar når noget går galt

De næste tre spørgsmål er de vigtigste. Tilfredshed fortæller hvordan et projekt endte. Ansvar fortæller hvordan dit projekt vil forløbe den dag noget går skævt, og den dag kommer i de fleste projekter.

4. Fortæl om en gang hvor noget gik galt. Hvad gjorde udvikleren?

Formulér det som en opfordring, ikke som et ja/nej-spørgsmål. Spørger du "gik der noget galt?", svarer de fleste nej. Beder du om en historie, får du en.

Gode svar ligner hinanden: udvikleren opdagede problemet selv eller sagde det med det samme, forklarede hvad der var sket uden fagsprog, kom med et forslag til en løsning og rettede sine egne fejl uden diskussion. Dårlige svar ligner også hinanden: skylden lå hos hostingfirmaet, den tidligere udvikler eller kunden selv, og udvikleren var svær at få fat på mens det stod på.

Siger referencen at intet gik galt, så spørg på en anden måde: "Var der noget der tog længere tid end forventet?" Et projekt på flere måneder helt uden forsinkelser eller overraskelser er sjældent, så måske husker referencen det pænere end det var.

5. Hvad skete der da I ændrede jeres ønsker undervejs?

Næsten alle kunder ændrer mening undervejs, for man bliver klogere når man ser de første skærmbilleder. Det interessante er hvordan udvikleren håndterede det.

Der er to fælder. Den ene er udvikleren der siger ja til alt uden at nævne pris eller tid, og som så leverer for sent. Den anden er udvikleren der afviser enhver ændring med "det står ikke i aftalen". Det gode svar ligger imellem: udvikleren forklarede hvad ændringen betød for pris og tidsplan, og så traf kunden beslutningen.

Følg op med "fik I det på skrift når noget blev lagt til?" Er svaret ja, har udvikleren styr på sine aftaler. Er svaret nej, risikerer du diskussioner om regningen senere.

6. Sagde udvikleren nogensinde nej til noget eller frarådede en idé?

Det spørgsmål afslører om du får en sparringspartner eller en ordremodtager. En erfaren udvikler siger fra når en funktion er dyr i forhold til hvad den giver, når en færdig standardløsning er god nok, eller når en idé vil skabe problemer om et år.

Et godt svar kunne være "udvikleren frarådede os at bygge vores eget betalingsmodul og foreslog en færdig løsning i stedet". Et svar som "nej, udvikleren lavede bare det vi bad om" kan lyde positivt, men det betyder at du selv skal træffe alle de tekniske beslutninger. Det er sjældent det du betaler for.

Spørgsmål om ejerskab og tiden efter lanceringen

7. Havde I adgang til koden, serverne og alle konti undervejs?

Det her spørgsmål er let at glemme, og det er det der koster mest når svaret er forkert. Spørg om koden lå i kundens eget repository (kodearkiv) eller i udviklerens. Spørg også hvem der ejede hostingkontoen, domænet og kontiene til betalingsløsning og mailudsendelse.

Et godt svar er at kunden havde adgang til det hele fra starten, også selvom udvikleren stod for det daglige. Et advarselstegn er en reference der ikke ved hvor koden ligger, eller som fortæller at alt står i udviklerens navn "for nemheds skyld". Hos mig ejer kunden koden fra første dag, og jeg anbefaler at hosting, domæne og andre konti står i kundens eget navn. Det bør du kræve af enhver udvikler, også af mig.

Har kunden skiftet udvikler siden, så spørg hvordan overdragelsen gik. Det er den bedste test af om man kan komme videre uden udvikleren. Hvad en god overdragelse kræver, har jeg beskrevet i guiden om at skifte udvikler midt i et projekt.

8. Hvordan har løsningen klaret sig efter lanceringen?

Mange referencer bliver kontaktet kort efter et projekt mens alt stadig er nyt og pænt. Spørg derfor hvor længe løsningen har været i drift, og hvordan det er gået siden. Er der kommet mange fejl? Hvem retter dem, og hvor hurtigt? Er udvikleren stadig til at få fat på?

Det stærkeste svar er en løsning der stadig kører, og som kunden udvikler videre på, enten med den samme udvikler eller uden problemer med en ny. Det svageste er en løsning som en anden udvikler byggede om fra bunden kort tid efter. Spørg i så fald hvorfor. Nogle gange var det udviklerens skyld, andre gange havde forretningen ændret sig.

9. Ville I hyre udvikleren igen til den samme opgave?

Gem det til sidst, og læg vægt på "den samme opgave". Mange referencer siger gerne ja til at bruge udvikleren igen til mindre ting, men tøver hvis det handler om et stort projekt. Den forskel er vigtig hvis dit projekt er det store.

Følg op med "hvad ville I gøre anderledes hvis I skulle starte forfra?" Svaret handler tit lige så meget om kunden selv: en bedre projektbeskrivelse, faste møder eller en tydeligere aftale. Det er gratis råd til dit eget projekt. Slut af med "er der noget jeg burde have spurgt om?" Det fanger det referencen gerne ville sige, men ikke fik anledning til.

Sådan læser du svarene

Efter to eller tre samtaler har du noter nok til at se et mønster. Det er mønsteret du skal vurdere, ikke det enkelte svar.

• Konkrete historier vejer tungere end tillægsord. "Hun svarede altid samme dag" siger mere end "hun var rigtig sød".
• Én lunken reference er ikke nødvendigvis et problem. Spørg dig selv om kritikken handler om noget der betyder noget for netop dit projekt.
• Det samme forbehold fra to referencer er et mønster. Tag det op med udvikleren, og hør hvordan vedkommende forklarer det.
• En reference der selv indrømmer at deres projektbeskrivelse var uklar, er ofte den mest troværdige du får.

Hvad referencer ikke kan fortælle dig

Referencerne er som regel udvalgt af udvikleren, så fravær af advarselstegn er ikke et bevis. De fleste kunder kan heller ikke vurdere kvaliteten af koden. De kan sige om løsningen virker i dag, men ikke om den er nem at bygge videre på om tre år.

Står der meget på spil, så kombinér referencerne med noget du selv kan se. En betalt prøveopgave viser hvordan udvikleren arbejder sammen med netop dig. En ekstern gennemgang af koden fra en anden udvikler kan vurdere det som referencerne ikke kan.

Vær også ærlig over for dig selv om hvad referencerne viser. Har udvikleren kun lavet projekter der er langt mindre end dit, eller har du brug for design, tekst og udvikling fra et helt hold på samme tid, så er en enkelt freelancer sandsynligvis ikke det rigtige valg. Det gælder også mig.

Næste skridt efter referencetjekket

Når referencerne er på plads, mangler du typisk tre ting: et sidste møde med udvikleren om det du har hørt, en skriftlig aftale og en plan for opstarten.

Tag gerne et par af referencernes forbehold med til det sidste møde. Hvordan udvikleren reagerer på kritik, er i sig selv et svar. Derefter kommer aftalen. Min tjekliste til kontrakten med en freelanceudvikler gennemgår blandt andet ejerskab, betaling og opsigelse, så det du har hørt om i spørgsmål 7, også står på skrift.

Vil du se hvordan jeg selv arbejder, fra et betalt forprojekt med fast pris til vedligehold og videreudvikling, så kan du læse om mine ydelser og hvordan et samarbejde med mig foregår.

Ofte stillede spørgsmål

Hvad gør jeg hvis udvikleren ikke vil give referencer?+

Spørg først hvorfor. Nogle udviklere arbejder under fortrolighedsaftaler (NDA) og må ikke nævne bestemte kunder, og det er en rimelig forklaring. Så kan du bede om en reference fra et andet projekt, en tidligere samarbejdspartner eller et stykke arbejde du selv kan se. En udvikler der hverken kan eller vil vise dig noget, bør du være forsigtig med.

Hvad hvis udvikleren er ny og ikke har referencer endnu?+

Så må du teste i stedet for at spørge. Start med en lille, betalt opgave med en klar afgrænsning og en fast pris, og vurder samarbejdet bagefter. En nyere udvikler kan sagtens være dygtig, men du tager en større risiko. Lad derfor det første projekt være så lille at du kan tåle at det går galt.

Kan anmeldelser på Google eller freelanceplatforme erstatte et referencetjek?+

Nej, de er et godt supplement, men ikke en erstatning. Anmeldelser er korte, ofte skrevet lige efter leveringen, og de fortæller sjældent hvordan problemer blev håndteret. Brug dem til at se mønstre og til at finde tidligere kunder du kan kontakte. Svarene på opfølgende spørgsmål får du kun i en samtale.

Hvordan bruger jeg referencer når udvikleren har arbejdet i et bureau?+

Spørg referencen præcis hvad udvikleren selv lavede. På et bureauprojekt er der ofte en projektleder, en designer og flere udviklere, og kundens indtryk handler om hele holdet. Det er stadig brugbart, men spørgsmålene om kommunikation og ansvar siger mindre om personen. Bed derfor også om en reference fra et projekt hvor udvikleren arbejdede alene eller havde ansvaret.