Software overdragen: een checklist die verder gaat dan broncode
Een overdracht is pas bruikbaar als de ontvangende partij de software kan begrijpen, opzetten, aanpassen en beheren binnen de afgesproken verantwoordelijkheid. Een map met code is daarvoor meestal onvoldoende. Begin met duidelijk maken wat wordt overgedragen: ontwikkeling, hosting, functioneel beheer, technische ondersteuning of een combinatie. De benodigde informatie en toegang hangen af van die scope.
Bespreek uw situatie1. Toegang en rechten
Maak zichtbaar waar broncode, omgevingen, domeinen en externe diensten worden beheerd. Controleer wie toegang heeft en wie die toegang kan verlenen of intrekken. Leg vast welke licenties en afspraken voor voortzetting relevant zijn.
Test toegang in de praktijk. Een accountnaam in een document bewijst nog niet dat de ontvangende partij kan werken. Deel gevoelige toegang via een passende overdrachtsmethode en spreek af wanneer oude rechten worden aangepast.
2. De software kunnen opzetten
Een ontvanger moet weten welke versies, afhankelijkheden en instellingen nodig zijn. Leg de stappen vast voor een ontwikkel- of testomgeving, inclusief benodigde voorbeeldgegevens en externe diensten.
Laat iemand die de omgeving niet heeft gemaakt de stappen uitvoeren. Waar mondelinge uitleg nodig blijkt, ontbreekt mogelijk nog informatie. Het doel is een reproduceerbare werkwijze, niet alleen documentatie verzamelen.
3. Gegevens en koppelingen begrijpen
Breng de belangrijkste gegevensstromen in kaart. Waar komt informatie vandaan, welk systeem is leidend en welke verwerking gaat naar andere partijen?
Leg ook vast wat er gebeurt bij een ontbrekend antwoord, mislukte import of dubbele verwerking. Deze uitzonderingen zijn vaak belangrijk voor de dagelijkse operatie. Voor eventuele migratie zijn aanvullende afspraken nodig over kwaliteit, controle en verantwoordelijken.
4. Testen en uitbrengen
Beschrijf hoe een wijziging wordt gecontroleerd en in productie komt. Welke tests bestaan, welke kernprocessen worden beoordeeld en wie geeft toestemming voor de release?
Spreek af wat bij een mislukte wijziging gebeurt. Een herstelprocedure moet passen bij de applicatie en beschikbare gegevens. Een beschrijving van een back-up is nog geen bewijs dat herstel werkt.
5. Kennis van het product
Technische documentatie verklaart niet vanzelf waarom het systeem zo werkt. Leg belangrijke productkeuzes, bedrijfsregels, bekende beperkingen en terugkerende uitzonderingen vast.
Gebruik concrete voorbeelden van werk dat gebruikers uitvoeren. Daarmee kan de ontvangende partij controleren of zij niet alleen de techniek, maar ook de gevolgen van wijzigingen begrijpt.
6. Beheer en ondersteuning
Wie beoordeelt meldingen, bewaakt externe diensten en handelt incidenten af? Wat is de afgesproken beschikbaarheid en welke ondersteuning valt buiten de opdracht?
Maak onderscheid tussen de periode van overdracht en de situatie daarna. Onduidelijkheid over verantwoordelijkheid kan anders pas zichtbaar worden wanneer een probleem optreedt.
De controlelijst
Vul per onderdeel in: aanwezig, gecontroleerd, verantwoordelijke en open actie. Een verzameld bestand is niet hetzelfde als een afgeronde controle.
| Onderdeel | Aanwezig? | Werkend gecontroleerd? | Verantwoordelijke | Open actie |
|---|---|---|---|---|
| Broncode en versiegeschiedenis | ||||
| Rechten, licenties en contractafspraken | ||||
| Ontwikkel- en testomgeving | ||||
| Hosting, domeinen en externe diensten | ||||
| Gegevensstromen en koppelingen | ||||
| Bedrijfsregels en productkeuzes | ||||
| Tests en releaseprocedure | ||||
| Back-up en herstelprocedure | ||||
| Monitoring en incidentafhandeling | ||||
| Documentatie en kennissessies | ||||
| Acceptatie en resterende ondersteuning |
Toets de overdracht met echt werk
Kies, wanneer dat verantwoord is, een kleine wijziging waarmee de ontvangende partij de afgesproken werkwijze doorloopt: begrijpen, aanpassen, testen en uitbrengen. Laat de huidige partij ondersteunen binnen vooraf bepaalde grenzen.
Noteer wat zelfstandig lukte en waar aanvullende kennis nodig was. Dat helpt bepalen of de overdracht voor de afgesproken scope voldoende is. Eén geslaagde wijziging is geen garantie dat alle toekomstige werkzaamheden zonder ondersteuning kunnen.
Wat als toegang of documentatie ontbreekt?
Maak het tekort expliciet en beoordeel de gevolgen voordat beheer of ontwikkeling wordt overgenomen. Soms kan informatie alsnog worden aangevuld. Soms moet eerst technisch onderzoek plaatsvinden of is een andere route nodig.
Rechten en contractuele afspraken kunnen afzonderlijke beoordeling vragen. Deze checklist is een praktische inventaris voor de overdracht; ze stelt niet vast welke rechten in uw specifieke overeenkomst bestaan.
Een overzichtelijke eerste stap
Wilt u van ontwikkelaar wisselen of meer intern kunnen uitvoeren? Begin met de gewenste verandering en de beschikbare toegang. Ownward helpt de vragen voor een overdracht of technische beoordeling af te bakenen.
Bespreek uw softwaresituatie.