Programma van eisen schrijven

Neem een regel die in vrijwel elk eisendocument staat: "er moet een knop komen die een pdf van de factuur naar de klant mailt". Dat is geen eis, het is een ontwerp met vier beslissingen erin verstopt: dat het een knop wordt, dat iemand die indrukt, dat het een pdf wordt en dat het per mail gaat.

Waarom die regel er staat is iets heel anders: klanten bellen omdat ze hun factuur kwijt zijn. Schrijf dat op, en een leverancier kan terugkomen met een klantportaal, met een automatische mail zodra de factuur wordt aangemaakt, of met een link in de betaalherinnering. De test is simpel: vraag bij elke regel waarom die er staat. Begint het antwoord met "zodat", dan staat de echte eis in dat tweede deel.

Er zit ook een minder prettige kant aan. Wie de oplossing dicteert, verplaatst het risico naar zichzelf: de leverancier levert de knop, de knop werkt, de telefoontjes blijven komen. Er is geleverd wat er stond. Een partij die alleen op uw ontwerp mag offreren denkt bovendien niet meer mee.

Eisen vallen uiteen in twee soorten. De eerste gaat over wat het systeem doet: iemand voert iets in, er gebeurt iets, er komt iets uit. Die staan meestal wel op papier. De tweede gaat over eigenschappen van het geheel, en die worden structureel overgeslagen, terwijl ze de architectuur bepalen en daarmee een groot deel van de kosten.

Een planningssysteem voor vijf mensen op een locatie is technisch iets anders dan hetzelfde systeem voor driehonderd mensen in vier landen, ook als de functionele lijst gelijk is. Ontbreekt die informatie, dan vult elke leverancier zelf iets in, en de goedkoopste offerte is die van degene die het kleinst heeft ingevuld.

Gebruik en volume

Hoeveel mensen werken ermee, hoeveel tegelijk, en hoe groeit dat. Systemen worden ontworpen op de piek, niet op het gemiddelde.

Gegevens en toegang

Welke persoonsgegevens gaan erin, wie mag ze zien, hoe lang bewaart u ze. Aansluiten op bestaande bedrijfsaccounts is een andere opdracht dan losse gebruikersnamen aanmaken.

Toegankelijkheid en talen

Voor overheids- en semipublieke organisaties gelden toegankelijkheidsverplichtingen; vraag na welke norm voor u geldt. Meertaligheid raakt ook datums, valuta en zoeken. Achteraf toevoegen is verbouwen.

Beschikbaarheid en beheer

Wat gebeurt er als het systeem eruit ligt, en wie lost het op. Dit hoort in het programma van eisen, niet pas in een beheercontract.

Een lijst waarin alles belangrijk is, is geen lijst. Toch komt dat vaak zo aan bij leveranciers: het document is samengesteld uit wensen van meerdere afdelingen en niemand durfde te schrappen. Categorieën als moet, hoort en mag helpen daar weinig tegen; na een paar afstemmingsrondes staat vrijwel alles in de bovenste categorie.

Twee stapels volstaan: wat de eerste werkende versie nodig heeft om echt gebruikt te worden, en wat kan wachten. Een derde is minstens zo nuttig: wat er bewust niet in komt, zodat het onderwerp niet elke maand terugkeert. De vraag die de stapels bepaalt is niet of iets handig zou zijn, maar of het werk zonder dat onderdeel kan doorgaan. Dat is de gedachte achter een MVP, toegepast op het product als geheel.

Die keuze hoort bij de opdrachtgever. Een leverancier weet wat iets kost, maar niet wat het waard is voor uw organisatie; laat u hem prioriteren, dan prioriteert hij op wat hij goed kan of wat technisch logisch op elkaar volgt. Dat is geen onwil, het is een verschil in belang: wie per uur factureert heeft weinig reden om aan te dringen op een kleinere eerste versie.

De meest onderschatte bron van meerwerk zit niet in de functies maar in de omgeving. Nieuwe software staat zelden op zichzelf: er is een boekhoudpakket, een webshop, een urenregistratie, een systeem dat de vorige directeur ooit kocht en dat nog steeds draait. Zet per systeem op papier welk pakket het is, welke versie, welke kant het verkeer op moet en wie het beheert.

Dat laatste is belangrijker dan het klinkt: koppelingen stranden vaker op toestemming dan op techniek. De leverancier van het bestaande pakket moet meewerken, en dat is niet vanzelfsprekend. Soms zit toegang tot de gegevens in een duurder abonnement, soms wordt er per koppeling afgerekend, soms reageert er niemand. Zoekt u dat niet vooraf uit, dan staat uw bouwteam stil.

Beschrijf ook waar de gegevens nu staan en in welke staat. Dubbele klantrecords, een veld dat door drie afdelingen anders is gebruikt, statussen die in een vrij tekstveld zijn getypt: dat komt boven bij de eerste proefmigratie. Het is meteen een toets bij het beoordelen van een softwareofferte, want een aanbieding die migratie en koppelingen als stelpost opneemt is niet te vergelijken met een die ze benoemt.

Een document dat alleen door management is geschreven, beschrijft het proces zoals het hoort te gaan. De mensen die het werk dagelijks doen kennen het proces zoals het echt gaat. Tussen die twee zit de ruimte waarin softwareprojecten sneuvelen.

Een herkenbaar voorbeeld: de procedure zegt dat een order pas wordt vrijgegeven na kredietcontrole, maar in de praktijk belt de accountmanager de administratie en gaat de order er alsnog doorheen, omdat de klant anders wegloopt. Bouwt u alleen de procedure, dan zit het systeem het werk in de weg. Mensen omzeilen het, of houden hun eigen bestandje ernaast bij, en de nieuwe software wordt een dure invoerschil.

Ga daarom zitten bij de mensen die het uitvoeren en kijk mee. Vraag naar de uitzonderingen, naar de lijstjes die ze naast het systeem bijhouden, en naar wat ze "even handmatig" doen. Die schaduwprocessen zijn eisen. Wijs daarnaast één eigenaar aan die knopen doorhakt; zonder die persoon wordt het document een verzamelbak waarin niemand iets schrapt.

Aan beide kanten zit een valkuil. Te vaag betekent dat elke leverancier zelf invult wat er ontbreekt. "Wij willen een klantportaal" levert offertes op die ver uiteenlopen: de een calculeert een documentarchief en facturen in, de ander een inlogscherm met drie pagina's. De laagste aanbieding wint dan op een misverstand, en het wordt lastig om een softwareleverancier te kiezen op iets anders dan gevoel.

Te dichtgetimmerd is het andere uiterste: schermontwerpen, veldnamen, tot en met de keuze voor een database. Dan koopt u uitvoering in terwijl u dacht een probleem uit te besteden, en wordt elke wijziging een afwijking van het bestek.

Het midden ligt bij drie dingen per onderwerp: wie iets moet kunnen, waarom dat nodig is, en waaraan te herkennen valt dat het gelukt is. Dat laatste is de scherpste toets, want een eis die u niet kunt aftekenen is geen eis. "Het systeem moet gebruiksvriendelijk zijn" is niet te controleren. "Een nieuwe medewerker voert zonder training een order in" is dat wel, en laat de bouwer vrij in hoe hij daar komt. Vuistregel: schrijf zo dat twee leveranciers hetzelfde probleem lezen, maar niet dezelfde oplossing hoeven te bedenken.

• Een softwareleverancier kiezen
• Een softwareofferte beoordelen
• Wat is een MVP?
• Software in meerdere talen