Sådan skifter du udvikler midt i et projekt (uden at miste alt)

Skal du skifte udvikler midt i et projekt, er rækkefølgen vigtigere end tempoet: først sikrer du adgange og kode, så får du koden vurderet, og først derefter bygger nogen videre. Følger du den rækkefølge, mister du sjældent mere end nogle ugers fremdrift. Springer du de første trin over, risikerer du at betale for det samme arbejde to gange.

Jeg er selv freelanceudvikler og overtager projekter som andre har bygget, så jeg har en interesse i emnet. Trinene herunder virker uanset hvem du vælger som din næste udvikler.

Den korte version

Din situation afgør hvor du starter:

Tommelfingerreglen er den samme i alle tre tilfælde: ingen ny kode før du har adgang til den gamle, og ingen beslutning om at bygge videre før nogen har læst den. Leder du stadig efter den nye udvikler, så start med min guide til at hyre en udvikler og kom tilbage hertil når overdragelsen skal i gang.

Er det udvikleren eller projektet der er problemet?

Før du skifter, så brug ti minutter på et ærligt spørgsmål: Vil en ny udvikler faktisk gøre det bedre? Et skifte koster altid tid fordi den nye skal sætte sig ind i koden. Det er kun pengene værd hvis problemet sidder hos udvikleren og ikke i rammerne omkring projektet.

Tegn på at det er udvikleren:

• Aftalte datoer skrider igen og igen uden en forklaring du kan forstå.
• Du ser aldrig noget der virker, kun statusbeskeder.
• Rettelser skaber nye fejl andre steder.
• Du får ikke adgang til koden eller serveren når du beder om det.
• Udvikleren svarer sjældnere og sjældnere.

Tegn på at det er projektet:

• Kravene ændrer sig hver uge, og ingen hos jer har det sidste ord.
• Budgettet blev sat før nogen vidste hvad der skulle bygges.
• Opgaverne kommer i én mail ad gangen uden prioritering.

Passer den sidste liste bedst på din situation, flytter problemet med over til den næste udvikler. Så er det bedre at bruge et par uger på at beskrive projektet og prioritere før du skifter. Ofte er begge dele i spil, og det er helt normalt.

Sådan skifter du udvikler i 6 trin

Trinene er skrevet til den situation hvor den gamle udvikler stadig svarer. Er udvikleren forsvundet, så læs også afsnittet længere nede.

1. Lav en liste over alt projektet består af

Et softwareprojekt er mere end kode. Det er også de konti og tjenester koden er afhængig af. Skriv dem ned før du gør noget andet, og notér for hver enkelt hvem der ejer kontoen, og hvem der betaler for den.

Typisk drejer det sig om repository (kodearkivet, fx på GitHub, GitLab eller Bitbucket), hosting og server, domæne og DNS, database og backups, mailtjenester, betalingsløsning, app store-konti og de integrationer systemet taler med, fx e-conomic eller et CRM. Gå dine fakturaer og kreditkortudtog igennem. Alt hvad virksomheden betaler for hver måned, hører med på listen.

2. Flyt adgange over i virksomhedens navn

Grundprincippet er enkelt: virksomheden ejer kontoen, og udvikleren er inviteret som bruger. Står en konto i udviklerens private navn, så bed om at få den overført eller få dig selv tilføjet som administrator mens samarbejdet stadig fungerer.

Domænet er det vigtigste at tjekke. For .dk-domæner kan du slå op hos Punktum dk hvem der står som registrant, altså den der har retten til domænet. Står udvikleren der, kan udvikleren overdrage domænet til virksomheden via selvbetjeningen hos Punktum dk, og du accepterer overdragelsen via en mail. Koden kan flyttes til virksomhedens egen GitHub-organisation, og en overførsel af et repository på GitHub beholder hele historikken.

Vent med at fjerne den gamle udviklers adgang til overdragelsen er færdig. Skift derefter adgangskoder, og bed den nye udvikler om at lave nye API-nøgler til betaling, mail og andre integrationer.

3. Aftal en ordnet overdragelse

Den billigste overdragelse er den hvor den gamle udvikler hjælper til. Selv hvis du er utilfreds, så hold tonen saglig. Aftal en fast slutdato og en kort liste over hvad du forventer at få:

• Al kode lagt op i repository, også halvfærdigt arbejde på separate grene (branches).
• En beskrivelse af hvordan projektet sættes op lokalt, og hvordan det sættes i drift.
• En liste over kendte fejl, midlertidige løsninger og ting der mangler.
• Et overdragelsesmøde på et par timer med den nye udvikler hvis det kan lade sig gøre.

Betal for de timer det tager. Alternativet er at den nye udvikler skal gætte sig frem, og det bliver dyrere.

Læs også din kontrakt igennem. Mange aftaler lader rettighederne til koden gå over til kunden når fakturaen er betalt. Uden en skriftlig aftale er udgangspunktet i dansk ret at den freelancer der har skrevet koden, har ophavsretten. Reglen i ophavsretslovens § 59 om at arbejdsgiveren overtager rettighederne til edb-programmer, gælder kun ansatte. Jeg har skrevet mere om hvem der ejer koden, og hvilke adgange du skal sikre dig. Er der uenighed om rettigheder eller betaling, så tal med en advokat før du bygger videre.

Har udvikleren haft adgang til persondata, så bed også om en skriftlig bekræftelse på at lokale kopier af databasen er slettet.

4. Få koden gennemgået af den nye udvikler

Inden den nye udvikler skriver en eneste linje, skal koden gennemgås. Det er her du finder ud af hvad du faktisk har betalt for. En god gennemgang besvarer blandt andet:

• Kan projektet startes op ud fra det der ligger i repository, eller mangler der noget?
• Hvor gamle er framework og pakker, og får de stadig sikkerhedsopdateringer?
• Ligger der adgangskoder eller nøgler direkte i koden?
• Findes der automatiske tests, og virker de?
• Er der backups, og er en gendannelse nogensinde blevet testet?
• Hvor meget af det du har bestilt, er reelt færdigt?

Resultatet bør være en kort skriftlig rapport med risici i prioriteret rækkefølge, skrevet så du kan forstå den uden at kunne kode. For et mellemstort projekt tager det typisk fra et par dage til en uge. Et skifte er netop en af de situationer hvor et code review udefra betaler sig.

5. Beslut: byg videre, ryd op eller start forfra

Med rapporten i hånden har du tre muligheder:

• Byg videre når koden er i orden og blot ufærdig. Det er den mest almindelige situation, og den billigste.
• Ryd op først når fundamentet holder, men dele af koden er rodet, forældet eller usikker. Den nye udvikler bruger så de første uger på at stabilisere før der kommer nye funktioner.
• Start forfra når teknologien er forældet, ingen kan få projektet til at køre, eller sikkerheden er gennemgående dårlig. Det kan også være det rigtige hvis projektet er lille, og det meste alligevel skal laves om.

Vær skeptisk hvis en ny udvikler foreslår at starte forfra uden at have læst koden. Det er nemmere at bygge sin egen løsning end at sætte sig ind i en andens, men det er dig der betaler for den nemme vej. En omskrivning tager næsten altid længere tid end planlagt fordi den gamle kode gemmer på forretningsregler som ingen har skrevet ned.

6. Prioritér de første 30 dage

Den første måned handler om at få kontrollen tilbage, ikke om at indhente det tabte. Min anbefalede rækkefølge er:

1. Stabilisér: backups, overvågning og de fejl der rammer brugerne.
2. Lever noget lille og synligt inden for de første uger så du kan se at samarbejdet virker.
3. Lav en prioriteret liste over resten, og aftal et fast tidspunkt hver uge hvor du ser hvad der er lavet.

Regn med at den nye udvikler arbejder langsommere de første uger. Det er ikke et tegn på at du har valgt forkert. Det er prisen for at overtage en kodebase man ikke selv har skrevet.

Hvis den gamle udvikler er forsvundet

Måske har udvikleren fået fuldtidsjob, er blevet syg eller svarer bare ikke. Det er ubehageligt, men sjældent katastrofalt fordi det meste kan genskabes via udbyderne.

Start med at skrive til udvikleren på mail med en konkret frist for at udlevere adgange og kode. Får du ikke svar, har du i det mindste dokumentation for at du har prøvet. Arbejd dig derefter igennem listen fra trin 1:

• Hosting og tjenester: Betaler virksomheden regningen, kan udbyderen som regel give dig adgang når du dokumenterer at du er kunden, fx med fakturaer og CVR-nummer.
• Koden: Har du ikke adgang til repository, ligger den seneste version ofte på serveren. Får du adgang til hostingen, kan den nye udvikler hente koden derfra. Historikken er væk, men koden er der.
• Domænet: Står virksomheden som registrant, kan du selv flytte domænet. Står udvikleren som registrant og er umulig at få fat på, behandler Klagenævnet for Domænenavne tvister om .dk-domæner.
• Rettigheder: Uden en kontrakt der overdrager rettighederne, står du i en gråzone. Få juridisk rådgivning før du bygger din forretning videre på koden.

Hvad et skifte koster, og hvornår jeg ikke er den rette

Et udviklerskifte koster tre ting: overdragelsestimer hos den gamle udvikler, en kodegennemgang hos den nye og en indkøringsperiode hvor fremdriften er lavere. Hvor meget det løber op i, afhænger især af kodens stand, hvor godt projektet er dokumenteret, og om den gamle udvikler hjælper til.

Det dyreste scenarie er det hvor alt går galt på én gang: ingen dokumentation, ingen hjælp og en kodebase der skal ryddes op i. Det billigste er en samarbejdsvillig udvikler og et projekt hvor koden har ligget i dit eget repository fra starten.

Vælg også en ny udvikler der arbejder i den teknologi projektet er bygget i. Jeg arbejder primært i Laravel/PHP og JavaScript (React og Next.js). Er dit projekt bygget i fx .NET, Java eller Ruby, er en udvikler med erfaring i netop den teknologi et bedre valg end mig. Er det en almindelig WordPress-side med et standardtema, kan et WordPress-bureau ofte løse opgaven billigere.

Sådan undgår du at stå her igen

Når overdragelsen er på plads, så brug erfaringen til at sætte rammerne for den næste udvikler:

• Koden ligger i jeres eget repository fra første dag, ikke i udviklerens.
• Alle konti står i virksomhedens navn, med udvikleren som inviteret bruger.
• Kontrakten beskriver rettigheder, opsigelse og pligt til at hjælpe med en overdragelse. Min tjekliste til kontrakten med en freelanceudvikler gennemgår punkterne.
• Opsætning og drift bliver dokumenteret løbende, ikke kun når samarbejdet slutter.

Hos mig ejer kunden koden fra dag ét, netop fordi det gør et skifte enkelt, også væk fra mig. Flere konkrete greb finder du i guiden om at undgå at blive låst til din udvikler. Og når du vælger den næste, så brug spørgsmålene du bør stille en udvikler før du hyrer til at spørge ind til overdragelse og adgange.

Næste skridt

Er du klar til at skifte, så gør det i denne rækkefølge:

1. Lav listen over konti og tjenester i dag.
2. Sikr dig administratoradgang til det hele.
3. Aftal en slutdato og en overdragelse med den gamle udvikler.
4. Få koden gennemgået før nogen bygger videre.

Har du brug for en udvikler til at overtage projektet, kan du læse om hvordan jeg arbejder med overtagelse, vedligehold og videreudvikling af eksisterende løsninger. Jeg svarer inden for 1 hverdag.

Ofte stillede spørgsmål

Skal jeg fortælle den gamle udvikler at jeg har fundet en ny?+

Ja, men først når du har administratoradgang til de vigtigste konti. Det er både ordentligt og praktisk fordi en overdragelse fungerer bedst når de to udviklere kan tale sammen. Hold beskeden kort og saglig: hvornår samarbejdet slutter, hvad du har brug for, og at du betaler for overdragelsestimerne. Snakken om hvad der gik galt, kan vente.

Hvor lang tid tager det at skifte udvikler?+

Regn typisk med nogle uger fra beslutningen til den nye udvikler er godt i gang. Selve overdragelsen kan klares på en uge eller to hvis den gamle udvikler samarbejder. Kodegennemgangen tager fra et par dage til en uge, og derefter kommer en indkøringsperiode. Er udvikleren forsvundet, afhænger tiden mest af hvor hurtigt udbyderne giver dig adgang.

Kan den gamle og den nye udvikler arbejde sammen i en periode?+

Ja, og et kort overlap er ofte den bedste investering i hele skiftet. Et par betalte timer hvor den gamle udvikler viser opsætning, drift og de svære dele af koden, sparer den nye for mange timers gætteri. Længere tids parallelt arbejde i den samme kode er sjældent en god idé fordi ansvaret bliver uklart.

Skal den nye udvikler arbejde i samme programmeringssprog?+

Ja, hvis du vil bygge videre på det du har. En udvikler der foreslår at skifte til sit eget foretrukne sprog eller framework, foreslår i praksis at starte forfra. Det kan være det rigtige, men så skal det være en bevidst beslutning på baggrund af en kodegennemgang og ikke en følge af at du har valgt en udvikler med en anden baggrund.

Skal jeg have en databehandleraftale med den nye udvikler?+

Som regel ja, hvis udvikleren får adgang til persondata, fx en database med kunder eller brugere. Så behandler udvikleren data på dine vegne, og GDPR kræver en skriftlig aftale om det. Få den på plads før adgangen gives. Er du i tvivl om hvad aftalen skal indeholde, så tal med en rådgiver.