Een overdracht valt of staat bij wat je zelf in bezit hebt. Staan de broncode, de domeinnaam en de sleutels van de koppelingen op naam van jouw organisatie, dan is overstappen vooral een kwestie van inwerken. Staan ze op naam van je huidige bureau, dan ga je onderhandelen.
De aanleiding is meestal dat het bureau stopt of wordt overgenomen, dat de ontwikkelaar die alles wist vertrokken is, of dat het tempo niet meer past bij wat je nodig hebt. Soms is het vertrouwen gewoon op. Wij doen dit regelmatig; hoe wij een bestaande applicatie overnemen staat op een aparte pagina.
Waarvan je eigenaar moet zijn
Loop dit langs, ook als je voorlopig helemaal niet wilt wisselen. De vraag is wat er gebeurt als je bureau morgen ophoudt te bestaan.
De broncode. Toegang tot de repository waar de code echt in staat, met de volledige historie erin. Een zipbestand dat iemand ooit gemaild heeft is iets anders. In die historie leest een nieuwe ontwikkelaar terug waarom iets is zoals het is, en dat scheelt in de inwerkperiode meer dan welk document ook.
De domeinnaam. Op naam van jouw organisatie, in een account waar jij zelf bij kunt. Een domeinnaam op naam van het bureau is bij een conflict het enige echt gijzelbare bezit, en tegelijk het onderdeel dat je het hardst nodig hebt.
Het DNS-beheer. Dit wordt het vaakst vergeten. Wie het DNS beheert bepaalt waar je website en je e-mail naartoe wijzen. Zonder die toegang staat een verhuizing stil op het laatste kwartier.
De accounts en sleutels van alles wat eraan hangt. Betaalprovider, mailverzending, koppelingen met je boekhouding, statistieken. Maak er een lijst van met daarachter op wiens naam ze staan. Die lijst is bijna altijd langer dan iedereen dacht.
De licenties. Betaalde modules of thema's staan soms op naam van het bureau. Bij een overstap moeten ze worden overgezet of opnieuw gekocht. Zelden veel geld, wel een verrassing op het verkeerde moment.
Hoe een overdracht verloopt
1. Inventarisatie. Het nieuwe bureau bekijkt de code, de gebruikte versies, de koppelingen en de staat van het onderhoud, en levert daar een beeld bij op. Bij ons heet die stap een code review. Dit is werk en dus niet gratis. Het is wel de goedkoopste stap in het hele traject, want hier komt aan het licht of je met een nette applicatie te maken hebt of met een verbouwing.
2. Lokaal draaiend krijgen. Voordat er iets gewijzigd kan worden, moet de applicatie draaien op de computer van de nieuwe ontwikkelaar, los van de live-omgeving. Bij een goed gedocumenteerd project is dat een uur werk. Zonder documentatie is dit het eerste struikelblok, en meteen een eerlijke graadmeter voor de rest.
3. Een gesprek met de vorige bouwer. Een uur met de mensen die het gebouwd hebben is meer waard dan een week zelf uitzoeken. Waar zitten de eigenaardigheden, welke keuzes zijn bewust gemaakt, wat stond er op de lijst die er nooit van kwam. Vraag dit aan zolang de relatie nog goed is. Na de laatste factuur wordt de agenda van een vertrekkend bureau merkbaar voller.
4. Toegang omzetten. Accounts over, sleutels vernieuwen, oude toegang intrekken. Dat laatste wordt vaak vergeten, en het is precies zo'n vergeten deur waar later iemand door naar binnen loopt. Meer daarover staat in het artikel over het beveiligen van een klantportaal.
5. Een kleine wijziging live brengen. Iets ongevaarlijks, nog voordat de grote wens aan de beurt is waarvoor je bent overgestapt. Daarmee test je de hele keten van bouwen tot uitrollen. Werkt dat, dan is de overdracht geslaagd en is de rest gewoon werk.
Waar het misgaat
Er is geen documentatie. Dat is eerder regel dan uitzondering en het is te overleven. Het kost inwerktijd. Reken erop dat de eerste weken trager gaan dan je gewend was en beoordeel het nieuwe bureau daar niet op.
De applicatie draait op een verouderde versie van het framework of van PHP. Dan wordt er eerst bijgewerkt voordat er iets nieuws bij kan, en dat is werk waar je niets van ziet. Het alternatief is doorbouwen op software die geen beveiligingsupdates meer krijgt. Structureel onderhoud voorkomt dat je hier ooit staat.
Er zijn geen tests. Voor een nieuwe ontwikkelaar is elke wijziging dan deels gokwerk: hij kan niet controleren of hij ergens anders iets gesloopt heeft. Dit is de belangrijkste reden dat de eerste maanden na een overdracht voorzichtig gaan.
De applicatie moet ook nog verhuizen. Gaat de overstap gepaard met een verhuizing naar een andere hostingomgeving, doe die twee dan achter elkaar en niet tegelijk. Eerst de verhuizing, met de oude omgeving nog een tijdje intact als terugvaloptie, en daarna pas de kennisoverdracht.
De afspraken waren mondeling. Wie is verantwoordelijk voor een bug die er al zat? Krijg je bij vertrek de laatste versie geleverd? Dit regel je bij de start van een samenwerking. Zet in het contract dat code, omgevingen en documentatie op verzoek worden overgedragen, en dat je toegang kunt krijgen tot de servers waar je applicatie op draait.
Wat het kost en hoe lang het duurt
Dat hangt vrijwel volledig af van de staat van de code en de documentatie, en dat weet je pas na de inventarisatie. Wat je vooraf kunt aanhouden: de inventarisatie kost dagen, het inwerken weken, en de eerste maanden gaan trager dan daarna. Een bureau dat een vast bedrag voor de overname noemt zonder de code gezien te hebben, gokt. Dat gokje komt later ergens terug.
Netjes uit elkaar gaan
Je oude bureau is zelden de vijand en meestal heb je elkaar nog nodig. Betaal openstaande facturen, kondig de overstap aan voordat iemand het zelf ontdekt, en vraag om een overdrachtsdocument in plaats van om "alles wat jullie hebben". Wie correct behandeld wordt neemt drie maanden later nog steeds de telefoon op als er iets onduidelijk is.
Houd er tegelijk rekening mee dat medewerking niet vanzelfsprekend is. Staat er in je contract niets over overdracht, dan bestaat er ook geen verplichting. Dat pleit ervoor om het te regelen bij het aangaan van een samenwerking.
Waar begin je?
Maak een lijst van broncode, domeinnaam, DNS, externe accounts en licenties, met daarachter op wiens naam elk daarvan staat.
Zorg dat je zelf kunt inloggen bij alles wat op jouw naam hoort te staan.
Leg in het contract vast dat je toegang kunt krijgen tot de servers waar je applicatie op draait.
Laat een inventarisatie doen voordat je een nieuw bureau kiest.
Plan het gesprek met de vorige bouwer zolang de relatie nog goed is.
Zet de toegang om en trek de oude toegang in zodra de overdracht rond is.
Begin bij die eerste lijst. Die kost een uur en is ook nuttig als je blijft waar je bent.
