Teknisk onboarding: Få nye udviklere godt i gang

En ny udvikler, freelancer eller et nyt bureau på din webshop kan levere værdi i første uge – eller bruge den første måned på at vente på adgange og gætte sig til, hvordan tingene hænger sammen. Forskellen er forberedelse. God teknisk onboarding betyder, at adgangene er klar, at der findes en kort oversigt over systemerne, og at den første opgave er lille nok til at lykkes.

Her er, hvordan du gør det – også selv om du ikke har et udviklingsteam, men en webshop med en ekstern udvikler.

Hvorfor onboarding går galt

Det typiske forløb: Den nye starter mandag. Der er ingen adgange. Der er ingen dokumentation. “Du skal lige tale med den tidligere udvikler, han ved, hvordan det hænger sammen.” Han har ikke tid. Første uge går med at vente, anden med at gætte, tredje med at rette fejlene fra gætteriet.

Det sker, fordi alle har travlt, fordi “det tager bare en time at sætte op”, fordi dokumentationen ikke findes, og fordi ingen har ansvaret for onboardingen.

Før første dag

Adgange

Shopify: Er udvikleren eller bureauet Shopify Partner, så brug en collaborator-konto:

• Du giver dem en firecifret anmodningskode, som findes under Settings > Users > Security.
• Du godkender anmodningen og bestemmer rollen og rettighederne – også hvilke apps og salgskanaler de må tilgå.
• Collaborators tæller ikke med i butikkens antal brugere.
• De skal have to-trins-godkendelse slået til for at kunne logge ind.

Ansætter du selv en udvikler, får vedkommende en medarbejderkonto. Bemærk, at antallet afhænger af planen: Basic har ingen ekstra medarbejderkonti, Grow har 5, Advanced 15 og Plus ubegrænset ifølge Shopifys danske prisside.

Andre systemer: repository, fragt, regnskab, e-mailmarketing, domæne og eventuelle integrationsværktøjer. Brug en password manager til delte adgange, og giv aldrig dit eget login videre.

Udviklingsmiljø

• En kopi af temaet at arbejde i, så der aldrig udvikles direkte på det aktive tema.
• Et repository med temaets kode. Shopifys GitHub-integration kan forbinde en branch med et tema og synkronisere begge veje, så ændringer i admin også bliver gemt i GitHub.
• Testdata, fx testordrer, der ikke rammer rigtige kunder og regnskabet.

Dokumentation

Det behøver ikke være meget, men det skal findes. Mere om, hvad der bør være skrevet ned, står i artiklen om dokumentation af webshoppen.

Den dokumentation, der skal findes

Systemoversigt. En tegning og en side tekst: webshop, apps, integrationer, lager, regnskab, fragt og e-mail. Hvad taler med hvad, og hvor bor data?

Kom i gang-guide. Hvordan arbejder man med temaet? Hvordan testes en ændring? Hvordan udgives den? Testen er, om en ny kan følge guiden uden at spørge.

Tilpasninger. Hvad er ændret i temaet, og hvorfor? Hvilke apps har lagt kode i temaet?

Ordliste. Dine interne navne for produkter, kundetyper og processer. Forretningsforståelse er ofte det sværeste for en ny udvikler.

Hvem spørger man om hvad? Hvem kender lageret, regnskabet, kundeservice og de gamle beslutninger – og hvordan når man dem?

Adgang i trin

Giv den adgang, opgaven kræver – ikke alt fra dag ét:

1. Start: kopi af temaet, repository, dokumentation og chat.
2. Når de første ændringer er godkendt: rettigheder til at udgive temaændringer og adgang til test af integrationer.
3. Når der er behov: adgang til ordrer, kunder eller indstillinger – kun de dele, rollen kræver.

Dokumentér, hvem der har adgang til hvad, og fjern adgange, når samarbejdet slutter. Gennemgå også sikkerheden: hvordan adgangskoder og API-nøgler håndteres, hvad der ikke må deles i chat, og hvordan kundedata behandles.

Første dag

• En kort velkomst og en gennemgang af forretningen fra kundens side: Hvad sælger du, til hvem, og hvad er vigtigst?
• Gennemgang af systemoversigten.
• Tjek, at alle adgange virker.
• En lille ændring helt igennem – fra kopi af temaet over test til udgivelse. Det giver tryghed og viser, at processen virker.

Første uge

• Gennemgang af de vigtigste dele af temaet og integrationerne – og hvorfor de er bygget, som de er.
• Et kig på de vigtigste forløb: produktside, kurv, checkout, ordreflow og returnering.
• Små fejlrettelser i samarbejde med den, der kender løsningen bedst.
• Opfølgning efter en uge: Hvad har fungeret? Hvad var forvirrende? Hvad mangler i dokumentationen? Opdatér den med det samme.

De første opgaver

Gode første opgaver

• mindre fejlrettelser i temaet
• dokumentation af noget, ingen har skrevet ned
• små forbedringer på sider, der ikke er forretningskritiske

Undgå i starten

• ændringer i checkout, betaling og kritiske integrationer
• store omskrivninger
• hasteopgaver med hård deadline
• opgaver uden klare krav

Øg derefter gradvist: fra småopgaver over mindre funktioner til selvstændige opgaver med review.

En fast kontaktperson

Giv den nye én fast person at spørge. Det kan være en kollega, den tidligere leverandør i en overgangsperiode eller en ekstern teknisk rådgiver. Pointen er, at der er nogen, der svarer – også på de spørgsmål, der føles dumme.

Kommer udvikleren fra et nyt bureau, der overtager efter et andet, så brug tjeklisten til handover fra et bureau, så intet falder mellem to stole.

Typiske fejl

• Ingen tid afsat. Onboarding er en investering, ikke spildtid.
• Alt på én gang. Spred informationen ud, og giv det, der er relevant nu.
• Ingen plan. Lav en simpel plan for første dag, første uge og første måned.
• For svære første opgaver. Start småt.
• Forældet dokumentation. Brug hver onboarding til at opdatere den.
• Delte logins. Hver person og hver leverandør skal have sin egen adgang.

Mål om det virker

• Tid til første sikre ændring i produktion.
• Tid til selvstændighed: hvornår kan udvikleren tage en opgave uden tæt opfølgning?
• Feedback efter en måned: hvor godt forberedt følte de sig?
• Spørgsmål, dokumentationen burde have besvaret: færre over tid betyder bedre dokumentation.

Opsummering

Forbered adgangene, skriv det vigtigste ned, giv en lille første opgave, og følg op. Det koster lidt tid før start og sparer meget bagefter. Står du foran at ansætte, så læs om din første tekniske medarbejder og overvejelserne om in-house udvikler, bureau eller freelancer.

Vil du have hjælp til struktur, adgange og dokumentation, kan du læse om min rolle som ekstern CTO eller kontakte mig.