Software opleveren zonder discussie: de acceptatiechecklist

1. Het probleem met "af"

Aan het eind van een project zeggen ontwikkelaars dat alles werkt, terwijl de opdrachtgever nog drie dingen mist die "toch logisch waren". Beide hebben gelijk vanuit hun eigen beeld. Zonder afgesproken definitie van klaar wordt de laatste twee weken van een project een onderhandeling, en de factuur een discussie.

Een acceptatiechecklist lost dat op door vooraf vast te leggen wat er getoetst wordt. Niet in juridische taal, maar als een lijst van concrete onderdelen die je kunt aanvinken. Het is het verschil tussen "de webshop werkt" en "een klant kan met iDEAL afrekenen en ontvangt binnen een minuut een bevestiging met factuur".

2. Wat hoort er in een acceptatiechecklist?

Een goede checklist is kort genoeg om echt door te lopen, maar dekt alle kanten van een oplevering. Wij groeperen onderdelen meestal in vijf categorieën:

• Functioneel — de scenario's uit de offerte, geformuleerd als handeling en resultaat. "Beheerder kan een product deactiveren; het verdwijnt direct uit de shop."
• Technisch — performance op representatieve data, werkt op de afgesproken browsers en apparaten, foutafhandeling bij een uitgevallen koppeling.
• Beveiliging — rollen en rechten getest, tweestapsverificatie actief, geen testaccounts meer in productie, back-ups aantoonbaar terug te zetten.
• Documentatie — handleiding voor beheerders, technische documentatie van koppelingen, overzicht van omgevingen en toegangen.
• Overdracht — domeinen en certificaten op naam van de klant, monitoring ingericht, beheerafspraken vastgelegd.

Elk onderdeel moet door iemand zonder technische kennis te beoordelen zijn. Als een punt alleen door de ontwikkelaar kan worden afgevinkt, hoort het niet in de acceptatie maar in de interne definitie van klaar van het team.

3. Per onderdeel goedkeuren of afkeuren

De kracht zit in het per stuk beoordelen. Je loopt de lijst door en geeft per onderdeel goedgekeurd of afgekeurd. Bij afkeuren geef je een korte reden: wat verwachtte je, wat zag je? Die reden gaat rechtstreeks naar het ontwikkelteam, zonder vertaalslag via een projectleider of een mailthread van veertig berichten.

Afgekeurde onderdelen worden opgepakt en opnieuw ter beoordeling aangeboden. Pas als alle punten zijn goedgekeurd, wordt de oplevering ondertekend. In ons klantportaal gebeurt dat digitaal: je ziet de voortgang als "7 van 9 goedgekeurd", en de handtekening wordt vastgelegd met naam en tijdstip.

4. Wanneer teken je, en wat betekent dat?

Ondertekenen betekent niet dat er nooit meer een fout mag voorkomen. Het betekent dat de afgesproken scope is geleverd en dat de garantie- of beheerfase begint. Leg daarom bij de start drie dingen vast:

• De acceptatieperiode — hoeveel werkdagen heb je om de checklist door te lopen? Twee weken is voor de meeste projecten realistisch.
• De garantieperiode — welke fouten worden na acceptatie kosteloos hersteld, en hoe lang? Denk aan drie maanden voor bugs binnen de opgeleverde scope.
• Het vervolg — wat valt daarna onder beheer, en wat is nieuw werk? Een SLA maakt dat concreet.

5. Veelgemaakte fouten

• De checklist pas aan het eind opstellen — dan wordt hij een verdedigingsmiddel in plaats van een gezamenlijk doel. Maak hem bij de offerte of uiterlijk bij de start.
• Vage formuleringen — "de site is snel" is niet toetsbaar. "De productpagina laadt binnen twee seconden op 4G" wel.
• Alles in één keer testen — toets per fase of sprint. Dan zijn afkeuringen klein en snel op te lossen.
• Nieuwe wensen als afkeuring indienen — een goede wens is geen fout. Zet hem apart als wijzigingsverzoek, anders komt het project nooit tot acceptatie.
• Niemand die tekent — spreek af wie namens de opdrachtgever bevoegd is. Zonder eigenaar blijft een oplevering eindeloos open.