Sådan vurderer du en udviklers portfolio uden at kunne kode

Du kan godt vurdere en udvikler uden at kunne kode, for det meste af det der afslører kvalitet i en portfolio, kan du se og prøve selv. Tjek om løsningerne findes og virker i dag, find ud af præcis hvad udvikleren selv lavede på dem, og få kunderne til at bekræfte det. Den eneste del du ikke selv kan bedømme, selve koden, kan du betale en anden udvikler for at vurdere.

Jeg er selv freelanceudvikler og sidder altså på den anden side af bordet, så læs med det forbehold. Det her er de trin jeg selv ville følge hvis jeg skulle hyre en udvikler uden at kunne læse koden.

Den korte version: hvad du selv kan tjekke

En portfolio kan vurderes på fem punkter. De fire første kræver ingen teknisk viden, kun tid og de rigtige spørgsmål.

At vurdere portfolioen er ét trin i en længere proces. Hvor det passer ind, fra første behov til underskrevet aftale, kan du se i min guide til at hyre en udvikler.

Trin 1: Find de projekter der ligner dit

Start med at sortere. De fleste portfolioer er lavet til at imponere bredt, men du skal kun bruge de projekter der siger noget om din opgave. Tag 2-3 ud, og lad resten ligge indtil videre.

Lighed handler mest om typen af løsning. Skal du have en kundeportal med login og integration til dit økonomisystem, så er en anden portal med login og integrationer relevant, også selvom den er lavet til en helt anden branche. En flot kampagneside fra din egen branche siger mindre.

Stil dig selv fire spørgsmål om hvert projekt:

1. Er det samme type løsning: hjemmeside, webshop, webapp, SaaS eller internt system?
2. Har det de samme svære dele som dit: login, betaling, integrationer til andre systemer eller mange samtidige brugere?
3. Er det nogenlunde lige så stort, eller er det et weekendprojekt i forhold til dit?
4. Kører det stadig, eller var det en engangsleverance?

Finder du ingen projekter der ligner dit, så spørg om der findes nogen der ikke er med. Meget B2B-arbejde ligger bag login eller er omfattet af en fortrolighedsaftale, så en tynd portfolio er ikke automatisk et dårligt tegn.

Vær også ærlig over for dig selv om hvad portfolioen viser. Er alle projekterne lavet af én person, og har du brug for design, tekst, udvikling og projektledelse på samme tid, så er en enkelt freelancer måske ikke det rigtige valg uanset hvor god portfolioen er. Det gælder også mig.

Trin 2: Prøv løsningerne selv

Det er her du får mest ud af din tid. Du behøver ikke vide hvordan en løsning er bygget for at mærke om den virker.

Hjemmesider og webshops

Åbn linket på både mobil og computer. Klik rundt, brug søgefunktionen, udfyld en formular og læg en vare i kurven. Du leder efter tre ting: om løsningen ligner det portfolioen viser, om noget går i stykker, og om den føles hurtig.

Til hastigheden kan du bruge Googles gratis værktøj PageSpeed Insights. Indsæt adressen, og se om resultatet er grønt, orange eller rødt. Brug det som en grov indikator, ikke som en karakter. Google skriver selv at scoren svinger fra måling til måling, og en langsom side kan skyldes kundens store billeder eller marketingscripts, ikke udviklerens arbejde.

Vil du vide om løsningen er blevet vedligeholdt siden lanceringen, så slå adressen op i Wayback Machine. Den viser gemte udgaver af hjemmesider tilbage i tiden, så du kan se hvornår siden kom til, og om den er blevet udviklet videre.

Systemer bag login

Det mest interessante arbejde er ofte det du ikke kan se: kundeportaler, interne systemer, administrationsværktøjer og SaaS-produkter. Her har du to muligheder. Opret en prøvekonto hvis produktet tilbyder det, eller bed udvikleren om en kort skærmdeling hvor du får løsningen vist.

Skærmdelingen er den bedste test du har. Bed udvikleren om at vise dig rundt som om du var en ny kollega: hvilket problem havde kunden, hvad gør løsningen, og hvilken del var sværest at bygge? En udvikler der selv har bygget det, kan svare uden noter og forklare det i et sprog du forstår.

Apps og løsninger der er lukket ned

For en app i App Store eller Google Play kan du se hvornår den sidst blev opdateret, og hvad brugerne skriver i anmeldelserne. Er en løsning lukket ned, så spørg hvorfor. Projekter lukker af mange grunde, og ofte er de forretningsmæssige. Det er forklaringen du skal lytte til, ikke det at projektet er væk.

Trin 3: Find ud af hvad udvikleren selv lavede

Det her er det vigtigste trin, og det er det mange springer over. Næsten alle løsninger af en vis størrelse er lavet af flere personer: en designer, en eller flere udviklere og måske et bureau med en projektleder. Har udvikleren været ansat på et bureau, kan portfolioen sagtens vise bureauets projekter. Det er helt i orden så længe du ved hvilken del udvikleren stod for.

Husk også at det flotte ved en løsning tit er designerens fortjeneste. Udviklerens arbejde viser sig i det der virker: at login, betaling og integrationer fungerer, at siden er hurtig, og at løsningen stadig kører efter et par år.

Spørg til hvert af de projekter du har udvalgt:

1. Hvad lavede du selv, og hvad lavede andre?
2. Var du med fra start, eller kom du ind undervejs?
3. Hvem talte med kunden og traf beslutningerne?
4. Hvad var det sværeste, og hvordan løste du det?
5. Hvem vedligeholder løsningen i dag?

Et godt svar er præcist og lidt kedeligt, fx: "Designet kom fra bureauet. Jeg byggede backend og integrationen til lagersystemet, og de sidste otte måneder var jeg den eneste udvikler på projektet." Et advarselstegn er en rolle der bliver mere uklar jo mere du spørger, eller et "vi" der aldrig bliver til et "jeg".

Flere spørgsmål til selve samtalen har jeg samlet i 27 spørgsmål du skal stille en udvikler før du hyrer.

Trin 4: Læs kundeudsagnene med kritiske øjne

Kundeudsagn på en udviklers hjemmeside er udvalgt af udvikleren selv, så de er aldrig negative. Det gør dem ikke værdiløse, men du skal læse dem på en bestemt måde:

• Står der fulde navne, firma og titel? Et udsagn fra "Mette, direktør" kan du ikke efterprøve.
• Kan du finde personen på LinkedIn, og arbejdede vedkommende i virksomheden på det tidspunkt?
• Handler udsagnet om noget konkret, fx overholdte deadlines eller en integration der virker, eller er det generel ros?
• Passer udsagnene til de projekter der står i portfolioen?

Det stærkeste du kan gøre, er at tale med en eller to af kunderne selv, helst fra de projekter der ligner dit. Et kvarter i telefonen afslører mere end en hel side med citater fordi du kan stille opfølgende spørgsmål og høre hvor referencen tøver. Hvad du skal spørge om, har jeg samlet i ni spørgsmål til en udviklers tidligere kunder.

Trin 5: Bed om det du ikke kan se

Når du har været portfolioen igennem, har du typisk et par huller. Måske ligger det mest relevante projekt bag login, eller også er du i tvivl om kvaliteten under overfladen. Det kan du bede om:

• En demo af et relevant projekt bag login, som skærmdeling eller med en testbruger.
• Kontakt til en kunde fra et projekt der ligner dit.
• En kort skriftlig beskrivelse af et projekt: problemet, løsningen og udviklerens rolle.
• Et kodeeksempel eller læseadgang til et repository (kodearkiv) som en anden udvikler kan kigge på.

Det sidste punkt er det eneste der siger noget om selve koden. Du kan ikke selv læse den, og det skal du heller ikke. En uafhængig udvikler kan typisk på nogle timer give dig et bud på om koden er overskuelig, testet og til at bygge videre på. Det er især fornuftigt hvis budgettet er stort, hvis løsningen er forretningskritisk, eller hvis du skal overtage en eksisterende kodebase. Hvornår det betaler sig, har jeg beskrevet i ni situationer hvor du har brug for et code review udefra.

Er du stadig i tvivl efter alt det, så er den sikreste test at starte med en lille opgave sammen. En betalt prøveopgave viser hvordan udvikleren arbejder med netop dig og dit projekt, og det kan ingen portfolio.

Advarselstegn og falske alarmer

Nogle ting i en portfolio bør få dig til at stoppe op. Andre ser mistænkelige ud, men er helt normale.

Advarselstegn

• Kun skærmbilleder og designskitser, ingen links til noget der kører.
• Links der ikke virker, eller som fører til noget andet end det skærmbillederne viser.
• En rolle udvikleren ikke kan forklare, eller som ændrer sig når du spørger igen.
• Kundeudsagn uden navne, eller med navne du ikke kan finde nogen steder.
• Projekter der alle ligner den samme færdige skabelon. Det passer dårligt hvis du skal have noget specialudviklet.

Falske alarmer

• Få offentlige projekter. Meget B2B-arbejde ligger bag login eller under fortrolighed.
• En portfolio der ikke er opdateret længe. Travle udviklere er tit dårligst til at opdatere deres egen hjemmeside.
• Ingen projekter fra din branche. Typen af løsning betyder mere end branchen.
• Begrænset aktivitet på GitHub. Kundeprojekter ligger typisk i private kodearkiver som ingen udefra kan se.

Advarselstegnene i resten af forløbet, fra første mail til kontrakt, har jeg samlet i red flags når du hyrer en udvikler.

Næste skridt: fra portfolio til samtale

Når du har gennemgået portfolioerne, har du forhåbentlig 1-3 kandidater tilbage og en liste med spørgsmål til hver. Brug tjeklisten før du går videre til samtaler og referencer.

Er jeg en af dine kandidater, så kan du se hvad jeg laver, og hvordan et samarbejde med mig er skruet sammen. Du ejer koden fra første dag, og større projekter starter med et betalt forprojekt til fast pris.

Ofte stillede spørgsmål

Hvad gør jeg hvis udvikleren ikke har nogen portfolio?+

Spørg først hvorfor. En udvikler der kommer fra en fast stilling, eller hvis arbejde ligger under fortrolighedsaftaler, kan sagtens være dygtig uden en offentlig portfolio. Bed om en skærmdeling af noget vedkommende har bygget, eller om et eget projekt. Kan udvikleren hverken vise, fortælle om eller henvise til noget, så start med en lille, betalt opgave til fast pris før du overlader et stort projekt til vedkommende.

Betyder kendte kundenavne noget i en portfolio?+

Mindre end man skulle tro. Et kendt logo viser at udvikleren har været med på et projekt for virksomheden, men ikke hvad vedkommende lavede. Store virksomheder køber også små opgaver, og en udvikler kan have rettet en enkelt formular på et stort site. Spørg derfor til rolle og omfang, præcis som ved alle andre projekter. Et mindre projekt hvor udvikleren stod for det hele, siger ofte mere.

Kan jeg bruge et AI-værktøj til at vurdere en udviklers kode?+

Kun som forberedelse, ikke som afgørelse. En AI-assistent kan forklare hvad et stykke kode gør, og pege på åbenlyse problemer. Men den kender ikke projektets historie og krav, og du kan ikke selv afgøre om svaret er rigtigt. Brug den til at formulere spørgsmål til udvikleren. Og indsæt aldrig kode fra et kundeprojekt uden tilladelse fra både udvikleren og kunden.

Hvor lang tid skal jeg bruge på at vurdere en portfolio?+

Min tommelfingerregel er en time eller to pr. kandidat når du har sorteret de åbenlyst forkerte fra. Det dækker 2-3 relevante projekter, en skærmdeling eller samtale om rollen og et opkald til en kunde. Det lyder af meget, men det er lidt i forhold til et projekt der kan løbe over flere måneder. Brug kun tiden på de kandidater der stadig er med efter første samtale.