Sådan samarbejder du med en udvikler: kommunikation, møder og forventninger

Et godt samarbejde med en udvikler hviler på tre aftaler: en fast rytme for status og demoer, feedback der er til at handle på, og én person på din side der træffer beslutninger hurtigt. Det er sjældent koden der får et projekt til at gå i stå. Det er spørgsmål der ligger og venter, prioriteter der skifter fra uge til uge, og forventninger ingen har sagt højt.

Jeg er selv freelanceudvikler, så det her er skrevet fra udviklerens side af bordet. Rådene gælder for freelancere, bureauer og fastansatte udviklere, og de fleste af dem kræver ikke at du er teknisk.

Den korte version: en rytme der holder projektet i gang

De fleste problemer forsvinder når begge parter ved hvornår de hører fra hinanden, og hvor tingene skal stå. Tabellen viser den rytme jeg vil anbefale til et typisk projekt med en freelancer eller et lille team.

Er du stadig ved at finde den rigtige udvikler, så start med guiden til at hyre en udvikler. Resten af indlægget går ud fra at aftalen er på plads, og at arbejdet skal i gang.

Hvad udvikleren har brug for fra dig, og hvad du kan forvente tilbage

Et samarbejde har to sider, og en stor del af tempoet i et projekt afhænger af kunden.

Det har udvikleren brug for fra dig:

• Prioriteter. En rangordnet liste over hvad der er vigtigst, så udvikleren aldrig skal gætte.
• Hurtige beslutninger. Et svar inden for et par hverdage er ofte mere værd end det perfekte svar efter to uger.
• Adgang til viden. Den der kender arbejdsgangene og de skæve tilfælde, skal være til at få fat i.
• Adgange og materiale til tiden. Logins, testdata, tekster og billeder. Min tjekliste til onboarding af en freelance udvikler har ti ting du kan have klar på dag 1.
• Test. Du er den eneste der kan afgøre om løsningen passer til din forretning.

Det kan du forvente af en god udvikler:

• Svar inden for en aftalt tid. Hos mig er det inden for 1 hverdag, og det er et rimeligt krav at stille til de fleste.
• Status du kan forstå uden at være teknisk, og software du kan afprøve.
• Dårlige nyheder tidligt. En udvikler der siger "det her tager længere tid end planlagt" i uge to, er langt mere værd end en der siger det i uge otte.
• Spørgsmål når noget er uklart, i stedet for gæt.

Sådan sætter du samarbejdet op i fem trin

De fem trin tager en time eller to at gennemgå ved opstart og sparer typisk mange flere timer senere.

1. Udpeg én beslutningstager

Vælg én person på din side der har det sidste ord om prioriteter og funktioner. Det behøver ikke være direktøren, men det skal være en der faktisk må beslutte, og som har tid til det.

Flere interessenter er fint, så længe deres input bliver samlet hos beslutningstageren. Det dyreste mønster jeg kender, er når salg, ledelse og kundeservice skriver direkte til udvikleren med hver deres ønsker. Så går tiden med at mægle, eller med at bygge noget der bliver lavet om ugen efter.

2. Aftal hvad der hører hjemme hvor

Aftal fra start hvor hver type kommunikation hører til, så beskeder ikke forsvinder:

• Opgavelisten: alle opgaver, fejl og ønsker. Om det er Trello, Notion, Jira eller GitHub Issues betyder mindre end at der kun er én liste.
• Beskeder på mail, Slack eller Teams: korte afklaringer og spørgsmål.
• Møder: demoer og beslutninger der kræver en samtale.
• Telefon: kun når noget er gået ned eller reelt haster.

Min tommelfingerregel er enkel: Står det ikke i opgavelisten, findes det ikke. Et ønske der blev nævnt i en bisætning på et møde, bliver glemt, og så er I uenige om noget ingen af jer kan dokumentere.

3. Aftal en fast ugerytme

Rytmen fra tabellen ovenfor kan skrues op og ned efter projektet, men den skal være fast. Hvis jeg skal foreslå én ugerytme til et typisk forløb med en freelancer, ser den sådan ud:

1. Starten af ugen: en kort skriftlig plan for hvad der bliver arbejdet på, og hvilke spørgsmål der skal besvares for at det kan lade sig gøre.
2. Undervejs: spørgsmål bliver stillet skriftligt i den aftalte kanal, og nye ting bliver lagt på et testmiljø (staging). Det er en kopi af systemet hvor du kan prøve det nye af uden at påvirke rigtige brugere.
3. Slutningen af ugen: en status med tre punkter: hvad er lavet, hvad er det næste, og hvad venter på dig.
4. Hver eller hver anden uge: en demo på en halv time hvor du ser det nye i rigtig software, og I prioriterer næste runde.

Læg mærke til hvor få møder der er. Med én udvikler er daglige statusmøder sjældent nødvendige, og hvert møde tager tid fra det du betaler for. En skriftlig status kan desuden læses af andre i din virksomhed og findes igen om et halvt år.

4. Aftal hvad "færdig" betyder

For en udvikler kan færdig betyde at koden er skrevet. For dig betyder det at funktionen virker for brugerne. Den forskel er årsag til mange skuffelser.

Aftal en fælles definition, fx at en opgave først er færdig når den er testet, ligger på testmiljøet, og du har godkendt den. Skriv også for hver større opgave hvad der skal være opfyldt, i almindeligt sprog: "En kunde kan se sine ordrer fra de sidste to år og hente en faktura som PDF." Så er der noget konkret at teste op imod.

5. Aftal hvordan ændringer og timer bliver håndteret

Nye idéer undervejs er et sundt tegn, men aftal på forhånd hvad der sker med dem. Ved fast pris skal en ny funktion enten erstatte noget andet eller have sin egen pris før arbejdet starter. Ved timepris skal du aftale et loft pr. måned og få en løbende oversigt over hvad timerne er gået til.

Sådan giver du feedback som udvikleren kan bruge

Feedback er der hvor mange samarbejder taber mest tid. "Det virker ikke" kræver flere runder spørgsmål før udvikleren kan gå i gang, mens en god fejlbeskrivelse ofte kan løses med det samme.

En brugbar fejlbeskrivelse svarer på fem spørgsmål:

1. Hvor var du? Adressen på siden eller navnet på skærmbilledet.
2. Hvad gjorde du? Trinene, så udvikleren kan gentage dem.
3. Hvad forventede du der skulle ske?
4. Hvad skete der i stedet?
5. Hvilken enhed og browser brugte du?

Tre vaner gør resten af forskellen:

• Beskriv problemet, ikke løsningen. "Kunderne overser knappen til betaling" giver udvikleren plads til at foreslå den bedste løsning. "Gør knappen rød" løser måske slet ikke problemet.
• Skeln mellem fejl og ændringer. En fejl er noget der ikke virker som aftalt. En ændring er noget der virker som aftalt, men som du gerne vil have anderledes. Det er to forskellige samtaler, også økonomisk.
• Saml feedback i én runde. Ti mails i løbet af en dag med hver sin lille rettelse koster mere tid end én samlet liste, fordi udvikleren skal skifte fokus hver gang.

Er du ikke selv teknisk, er det helt i orden at sige "jeg forstår ikke hvad det betyder". En god udvikler kan forklare hvad et valg betyder for tid, pris og risiko uden fagsprog. Det har jeg skrevet mere om i guiden til at hyre en udvikler når du ikke selv er teknisk.

Beslutninger og nye ønsker: sådan undgår du at projektet går i stå

Et projekt går typisk i stå når en beslutning ligger og venter, eller når nye ønsker bliver lagt oveni uden at noget andet bliver taget af.

Gør beslutninger hurtige

• Bed om et forslag til hvert spørgsmål. "Skal rabatkoder også gælde for abonnementer? Jeg foreslår nej i første version, fordi det kræver en ekstra betalingsregel." Så kan du svare ja eller nej i stedet for selv at skulle finde på svaret.
• Aftal en standard. Har du ikke svaret inden for et par hverdage, går udvikleren videre med sit forslag. Det holder arbejdet i gang, og de fleste valg kan ændres senere.
• Skeln mellem små og store beslutninger. Farver og tekster kan rettes på minutter. Valg om data, betaling og brugerroller er dyre at lave om, og det er dem du skal bruge din tid på.

Prioritér nye ønsker i stedet for at lægge dem oveni

Når du får en ny idé, er der tre ærlige muligheder:

• Byt: Den nye funktion erstatter noget der var planlagt, og budgettet holder.
• Udskyd: Idéen kommer på listen over det der skal laves efter lanceringen.
• Prissæt: Den bliver lagt oveni med sin egen pris og tid, som du kender før arbejdet starter.

Den fjerde mulighed, at lægge den oveni og håbe på det bedste, er en af de mest almindelige grunde til at tidsplaner skrider. Arbejder I til fast pris, er en byttehandel ofte den bedste vej. Hvorfor en fast ramme med fleksibel udførelse typisk holder bedre end en plan der er låst fra start, har jeg beskrevet i agil udvikling vs. vandfald.

Når samarbejdet knirker

Selv gode samarbejder har perioder hvor det går trægt. Det vigtige er at opdage det tidligt, og det er de tegn jeg ville reagere på:

• Demoer bliver udskudt to gange i træk.
• Status bliver vag, fx "arbejder på det" i stedet for hvad der konkret er lavet.
• Den samme opgave har været "næsten færdig" i flere uger.
• Du hører kun fra udvikleren når du selv skriver.
• Fejl du har meldt, dukker op igen efter de er rettet.

Tegnene gælder også din side. Svarer du langsomt, eller skifter prioriteterne hver uge, er det svært for selv en dygtig udvikler at holde tempoet.

Tag snakken med det samme, og vær konkret: "De sidste to demoer er blevet aflyst. Hvad skal der til for at komme tilbage på sporet?" Ofte er årsagen noget der kan løses, fx for mange opgaver på én gang, en uklar prioritering eller en teknisk overraskelse ingen har sagt højt.

Hjælper det ikke, er det godt at koden og adgangene ligger hos dig. Hos mig ejer kunden koden fra første dag, og det bør være standard. Så kan en anden udvikler tage over, og hvordan det gøres med mindst muligt tab, står i guiden om at skifte udvikler midt i et projekt.

Hvornår en enkelt freelancer ikke passer til måden du vil arbejde på

Samarbejdet med én freelancer passer ikke til alle. Det er sjældent det rigtige valg hvis:

• Du har brug for at udvikleren sidder fysisk hos jer flere dage om ugen.
• Du vil have daglige statusmøder og fast deltagelse i interne møder.
• Systemet kræver vagt døgnet rundt, også når udvikleren er syg eller på ferie.
• Opgaven kræver flere specialister på samme tid, fx design, apps, dataanalyse og drift.

I de tilfælde er et bureau eller en fastansat udvikler ofte et bedre match. Til gengæld får du med en freelancer direkte kontakt til den der skriver koden.

Næste skridt: aftal spillereglerne før I går i gang

Brug tjeklisten på opstartsmødet. Det tager en times tid at blive enige om punkterne, og den time sparer mange misforståelser senere.

Vil du se hvilke typer projekter jeg arbejder med, så find dem i oversigten over mine ydelser inden for hjemmesider, webapps og SaaS.

Ofte stillede spørgsmål

Skal jeg bruge mail eller Slack med en freelance udvikler?+

Det betyder mindre end at I bruger den samme kanal hver gang. Mail er fint til de fleste projekter, og en fælles chat som Slack eller Teams kan være praktisk når der er mange små afklaringer. Undgå at sprede samtalen over mail, sms, chat og telefon, for så bliver beslutninger svære at finde igen. Opgaver og fejl hører under alle omstændigheder hjemme i opgavelisten.

Hvor hurtigt kan jeg forvente svar fra en udvikler?+

Inden for 1 hverdag er et rimeligt krav til almindelige spørgsmål, og det er også det jeg selv lover. En udvikler arbejder bedst i lange perioder uden afbrydelser, så svar inden for få minutter er sjældent realistisk og heller ikke noget du bør ønske. Akutte fejl er noget andet. Er dit system forretningskritisk, så aftal en særskilt svartid, fx i en serviceaftale.

Har jeg brug for daglige statusmøder med min udvikler?+

Sjældent, når du arbejder med én udvikler. Daglige møder hjælper teams der skal koordinere arbejdet mellem flere personer, og med en enkelt udvikler tager de mest tid fra selve arbejdet. En ugentlig skriftlig status og en demo hver eller hver anden uge er som regel nok. I intense perioder, fx ugen op til en lancering, kan et kort dagligt tjek dog være fornuftigt.

Hvad gør jeg hvis jeg ikke forstår hvad udvikleren siger?+

Sig det, og bed om at få det forklaret som konsekvenser i stedet for teknik. Spørg hvad valget betyder for pris, tid og risiko, og hvad der sker hvis du vælger det andet. En god udvikler kan forklare det uden fagord. Kan en udvikler gang på gang ikke det, er det et tegn på at kommunikationen bliver et problem senere i forløbet.

Må jeg skrive til udvikleren uden for arbejdstid?+

Ja, men forvent ikke svar før næste hverdag, medmindre I har aftalt andet. Det er fint at sende spørgsmål når de dukker op, så udvikleren kan svare samlet. Har du brug for hjælp uden for normal arbejdstid, fx når en webshop er nede en lørdag, skal det aftales på forhånd og bliver typisk betalt særskilt.