Software opleveren en accepteren

Bij de oplevering krijgt u een demo en de vraag of het zo goed is. Wie dan nog moet bedenken waar hij op let, heeft geen maatstaf, en zonder maatstaf wordt acceptatie een onderhandeling. Die wint de partij met de meeste haast: meestal de bouwer, wiens team al op het volgende traject staat en die pas kan factureren als er is afgetekend.

Er speelt ook een kennisverschil: de leverancier weet welke punten normaal zijn bij een eerste versie, de opdrachtgever niet. Op indruk afgaan helpt daar niet tegen, want een demo op schone data, gegeven door iemand die weet welke route werkt, ziet er altijd goed uit.

Een beslissing heeft criteria, en die horen bij de afspraak over wat er gebouwd wordt. Een bruikbaar criterium is geen functiebeschrijving maar een uitspraak die waar of niet waar kan zijn: iemand in rol X rondt taak Y af onder omstandigheid Z, zonder hulp van de bouwer. Dat zulke criteria vaak ontbreken heeft een reden die zelden hardop klinkt: vage afspraken houden het gesprek achteraf onderhandelbaar voor de leverancier en besparen de opdrachtgever denkwerk dat nog niemand wil doen. Beiden kiezen voor uitstel en betalen dat aan het eind.

De bouwer toetst of zijn werk doet wat hij bedoeld had, en legt daarmee zijn eigen aannames langs zichzelf. De projectleider toetst de route uit het ontwerp, want die kent hij uit zijn hoofd. Beiden klikken de bedoelde volgorde, en die volgorde is nooit het probleem.

De mensen die er straks mee werken doen iets anders. Zij beginnen halverwege, plakken een adres uit een e-mail waar een regeleinde in zit, en zoeken op een klantnaam die twee keer voorkomt. Ze weten bovendien welke uitzondering elke maand terugkeert, en dat staat in geen functioneel ontwerp.

Daar hangt een prijskaartje aan dat zelden in de planning staat. Wie er tussen zijn werk door een uurtje aan besteedt, doorloopt de makkelijke gevallen en meldt niets. Reken erop dat u mensen moet vrijroosteren, en dat het uw beste mensen zijn. Wie dat niet regelt, krijgt geen test maar een handtekening.

Een functielijst kan volledig groen zijn terwijl het werk niet te doen is. Zo'n lijst toetst de overgangen tussen functies namelijk niet, en daar zitten de gaten: gegevens die niet meekomen naar het volgende scherm, een status die niet terug te draaien is, een stap die alleen een beheerder mag zetten.

Schrijf de scenario's zoals het werk echt loopt, en laat ze doorlopen tot het einde van de keten: tot en met de bevestiging in de mailbox en de regel in de boekhouding. Ketens breken bij de overdracht.

Drie verzonnen records zeggen niets over een systeem dat straks jaren historie krijgt. Bij volume gedraagt software zich anders: zoeken wordt traag, en een filter dat op tien regels logisch leek beantwoordt op tienduizend regels de verkeerde vraag. Echte data bevat bovendien dubbele klanten, namen met bijzondere tekens en oude records die nooit volledig zijn ingevuld.

Komen er gegevens uit een bestaand systeem over, dan hoort die migratie bij de acceptatietest en niet bij het weekend van de livegang. Klopt het aantal, kloppen de bedragen, en wat is er gebeurd met velden die in het oude systeem niet bestonden.

Een kopie van de productiedatabase in de testomgeving is de snelste route naar realistische data, maar ook een nieuwe verwerking van persoonsgegevens: er kijken meer mensen mee, de beveiliging ligt lager en kopieën worden zelden opgeruimd. Werkbaar is gegevens onherkenbaar maken of testdata genereren die de echte in omvang en rommeligheid benadert. Dat kost tijd die nergens begroot is. Wat in uw situatie mag, legt u voor aan een jurist of privacyfunctionaris.

Uit een serieuze test komt een lange lijst. Sorteer die samen met de leverancier in drie categorieën.

Blokkerend

Live gaan kan niet: het werk is niet uit te voeren, gegevens komen verkeerd terug, of er is een risico rond beveiliging of privacy. Alleen dit is een reden om niet te accepteren.

Herstel, niet blokkerend

Het systeem is bruikbaar, maar dit hoort niet zo en valt binnen wat is afgesproken. Accepteren kan, mits vastligt wanneer het hersteld wordt en voor wiens rekening.

Wens

Het werkt zoals afgesproken, maar bij het gebruiken bleek u iets anders te willen. Dat is nieuwe functionaliteit en dus meerwerk, hoe klein ook.

De grens tussen de tweede en de derde categorie is waar het geld zit. De opdrachtgever noemt iets een gebrek omdat hij aannam dat het zo zou werken; de leverancier noemt het nieuw omdat het nergens staat. Alleen wat vooraf is opgeschreven beslecht dat.

Let ook op de beweging tussen categorieën: onder tijdsdruk verhuist een blokkerend punt makkelijk naar "herstellen we later", en een wens net zo makkelijk naar "gebrek". Wie de categorie verandert zonder dat het punt verandert, verplaatst alleen de rekening.

Acceptatie is in de meeste overeenkomsten ook een geldmoment: de laatste termijn wordt opeisbaar, en de periode begint waarin herstel nog bij de bouw hoort in plaats van bij onderhoud. Dat verklaart de druk aan beide kanten, en geen van beide helpt. Onder druk accepteren levert een systeem met een lijst; eindeloos uitstellen levert een team dat allang aan iets anders werkt.

Scheid twee momenten die door elkaar lopen: acceptatie gaat over de vraag of het gebouwde voldoet aan wat is afgesproken, livegang over de vraag of uw organisatie er klaar voor is. Die kant staat in de app launch checklist.

Wat daarna nog onder herstel valt, staat in uw contract. Kijk na of het onderscheid tussen herstel van gebreken en doorlopend onderhoud expliciet is beschreven: bijgewerkte afhankelijkheden en het draaiend houden van de omgeving zijn onderhoud, ook als ze kort na oplevering nodig blijken. Hoe u die fase inricht leest u in software in beheer nemen; uw eigen overeenkomst laat u door een jurist tegen het licht houden.

In vrijwel elke planning staat de testperiode als laatste blok voor de livegang, en vangt die dus elke vertraging op die eerder is ontstaan. De opleverdatum ligt bovendien vaak vast om redenen die niets met software te maken hebben: een seizoen, een aflopend contract met de vorige leverancier. Als alles behalve die datum is opgeschoven, is testtijd het enige wat nog kan krimpen. Hoe die druk ontstaat staat in waarom software projecten uitlopen.

Het gevolg is voorspelbaar: er wordt geaccepteerd wat niet af is, met een lijstje kleine punten erbij. Dat lijstje is de eerste onderhoudsachterstand van het systeem, en vanaf de handtekening staat u er zwakker in.

De tegenzet is niet harder duwen maar minder tegelijk toetsen: laat gebruikers tijdens de bouw per afgerond onderdeel testen, zodat de eindtest over het samenspel gaat. En spreek vooraf af wat er gebeurt als de test uitwijst dat het niet klaar is.

• Waarom software projecten uitlopen
• Software in beheer nemen
• App launch checklist
• Testen met gebruikers