Van softwarebureau wisselen

Wie hierover nadenkt, stelt meestal eerst de verkeerde vraag: kan een ander onze code overnemen? Ontwikkelaars lezen dagelijks code die ze niet zelf schreven. Rommelig werk maakt dat trager en duurder, zelden onmogelijk. Overstappen strandt op iets anders.

Het strandt op afhankelijkheid. De repository staat onder het account van het bureau, de domeinnaam is ooit door hen geregistreerd, het cloudproject draait binnen hun omgeving met hun facturatie eraan. De app store-accounts staan op hun naam, waardoor uw app onder hun uitgeversnaam in de winkel ligt. En een versie uitrollen is een handeling die precies één persoon nog foutloos uitvoert, zonder dat die ergens beschreven staat.

Los is elk punt onschuldig, samen vormen ze een slot: u kunt de code krijgen en er niets mee kunnen. Wat u contractueel toekomt en wat u feitelijk in handen heeft zijn twee dingen; die afstand bepaalt hoe sterk u staat. Wat er formeel geregeld hoort te zijn, staat in broncode: eigendom en overdracht.

Elk vinkje dat u nu niet kunt zetten, wordt straks een onderhandelingspunt in plaats van een feit. Vraag ontbrekende toegang aan als normaal beheer; dit hoort sowieso op orde te zijn.

Dit is het ongemakkelijke deel. Een deel van de frustratie waarmee opdrachtgevers overstappen, is niet door de leverancier veroorzaakt. Als niemand knopen doorhakt, als de wensen elke paar weken verschuiven, als er meerwerkdiscussie is over afspraken die nooit zijn opgeschreven, dan verhuist dat probleem mee. De opvolger is eerst enthousiast en geeft daarna dezelfde signalen af.

Het onderscheid is te maken. Wijst op uw eigen kant: niemand kan namens u beslissen, opleveringen worden pas laat bekeken, prioriteiten veranderen tussen twee overleggen door, en klachten gaan over dingen die nergens zijn vastgelegd. Wijst op de leverancier: dezelfde storing komt terug, niemand kan uitleggen hoe een onderdeel werkt, elke release is spannend, en gevraagde toegang wordt steeds uitgesteld.

Een bruikbare toets: vraag om een gezamenlijk overzicht van alles wat openstaat, met per punt wie waarop wacht. Is de lijst onder uw eigen naam de langste, dan zit het probleem niet aan de andere kant van de tafel. Een derde mogelijkheid: het bureau was goed in bouwen en minder in beheren. Bekijk dan eerst wat software in beheer nemen vraagt.

1. Inventariseer voordat u iets aankondigt

   Wat draait waar, en op wiens naam staat het. Deze stap is stil, kost niets en bepaalt de rest.

2. Haal binnen wat u zelf kunt binnenhalen

   Accounts overzetten, uzelf als beheerder toevoegen, facturatie op eigen naam. Dat valt binnen normaal opdrachtgeverschap.

3. Lees het contract op de exitbepalingen

   Opzegtermijn, afspraken over overdracht, wie eigenaar is van welk deel. Laat een jurist naar uw eigen situatie kijken, want dit verschilt per overeenkomst.

4. Voer het gesprek met uw huidige partij

   Benoem concreet wat er misgaat en wat u nodig heeft. Soms is er intern iets veranderd en valt het op te lossen.

5. Zoek daarna pas de opvolger

   Laat een kandidaat de software beoordelen voordat u definitief opzegt. Zolang de huidige partij doorwerkt, heeft u de tijd aan uw kant.

6. Regel de overdracht als aparte opdracht

   Met een opleverlijst en een aanspreekpunt. Wat niemands verantwoordelijkheid is, blijft liggen tot het te laat is.

Wie deze volgorde omdraait, onderhandelt daarna over dingen die hij nodig heeft. Dat is het moment waarop toegang duur wordt.

Een serieuze kandidaat kan pas iets zinnigs zeggen als hij twee dingen heeft gedaan: de software aan de praat krijgen op zijn eigen machines, en zelf een kleine wijziging uitrollen naar een testomgeving. Dat tweede is de echte toets. Wie een wijziging live krijgt, heeft begrepen hoe het geheel in elkaar zit. Wie door de code heeft gescrold, heeft een indruk.

Een prijs op basis van een globaal verhaal is daarom geen daadkracht maar een verkoopreflex. Hetzelfde geldt voor de zin die u vaak zult horen: wij kijken er wel even naar. Dat klinkt behulpzaam en laat het risico bij u liggen, want er is niets toegezegd.

Wat een partij die het vak kent wel voorstelt, is een afgebakende periode om de code te leren kennen, als aparte opdracht met een schriftelijke uitkomst: welke onderdelen zijn begrepen en welke niet, welke afhankelijkheden geen updates meer krijgen, wat er niet getest is, en wat zij als eerste zouden aanpakken. Pas daarna wordt praten over doorontwikkeling zinnig. Waar u bij die keuze verder op let, staat in een softwareleverancier kiezen.

Reken erop dat dit gebeurt, en besef dat er een belang achter zit. Herbouwen is voor een bouwende partij aantrekkelijker: een schone start in de eigen technologie, geen verantwoordelijkheid voor de keuzes van een voorganger, en een grotere opdracht. Dat maakt het oordeel niet onwaar, wel iets om te toetsen.

Vraag om voorbeelden in plaats van kwalificaties. Welk onderdeel precies, wat is daar het probleem, en wat is het gevolg voor gebruikers, voor de veiligheid of voor de snelheid waarmee er nog iets te veranderen valt. Vraag daarna de vergelijking die het gesprek eerlijk maakt: wat vraagt het herstellen van alleen die punten, tegenover volledige herbouw. Reken mee dat doorontwikkelen tijdens een herbouw doorgaans stilligt.

In oude code zit bovendien iets dat in schattingen zelden meetelt: jaren aan kleine uitzonderingen en randgevallen, verwerkt zonder dat iemand ze opschreef. Een herbouw begint schoon, maar ook zonder die kennis. Soms is herbouw wel het juiste antwoord: als de technologie geen beveiligingsupdates meer krijgt, als er geen enkele test is en elke wijziging dus een gok, of als niemand meer weet hoe een cruciaal onderdeel werkt. Die argumenten zijn te controleren; een oordeel is dat niet.

Waar de vertrekkende partij toe verplicht is, staat in uw overeenkomst en niet in een algemene regel. Kijk of er een exit- of overdrachtsbepaling in staat, wat die omvat en of er voorwaarden aan hangen, bijvoorbeeld rond openstaande facturen. Ontbreekt zo'n bepaling, dan is het een kwestie van onderhandelen. Laat een jurist meekijken naar uw eigen contract.

Een overdracht is gewoon werk, en werk waar niets tegenover staat, schuift naar achteren. Een afgebakende betaalde overdracht met een opleverlijst levert doorgaans meer op dan een gratis toezegging. Op die lijst horen: alle accounts overgezet met bewijs, een uitrolbeschrijving die iemand van de nieuwe kant ook echt heeft uitgevoerd, een gesprek met de ontwikkelaars zelf in plaats van met een accountmanager, en een periode waarin er nog vragen gesteld mogen worden. Vervang daarna alle wachtwoorden en sleutels waar de oude partij bij kon, hoe goed het afscheid ook was.

Een nette afronding is ook in het belang van de vertrekker. De opvolger ziet van dichtbij hoe het werk is achtergelaten, en dat oordeel reist door de markt. Een partij die de overdracht traineert, vertelt daarmee iets over hoe zij met haar andere klanten omgaat.

• Broncode: eigendom en overdracht
• Software in beheer nemen
• Een softwareleverancier kiezen