Lijstjes met eisen en wensen zijn vaak als Paris Hilton: fraai, nietszeggend en je hebt er weinig aan. Het klinkt natuurlijk goed, in kaart brengen wat de gebruiker nu echt wil van het systeem, maar in de praktijk is het vaak een ritueel dansje. Het hoort erbij, we doen het even, maar niemand weet nog waar het echt voor dient.
Lijstjes met eisen en wensen kunnen een nuttige bijdrage leveren aan de automatisering, maar alleen wanneer deze eisen en wensen niet uit louter platitudes voor de vorm bestaan. En veel te vaak doen ze dat helaas wel. Neem nu een voorbeeld dat ik recent zag (ik zal geen namen noemen). De lijst met eisen en wensen begon met flexibel, schaalbaar en nog enkele van dit soort doodoeners.
Zo'n lijstje kun je net zo goed niet maken. Wat is het probleem? Het probleem is dat deze eigenschappen niets zeggen over het te bouwen systeem. Wat, zul je misschien vragen? Er staat toch dat het systeem flexibel en schaalbaar moet zijn? Ja, dat staat er wel, maar dat zegt niets over het te bouwen systeem omdat dat wenselijke eigenschappen zijn voor íéder te bouwen systeem. Eisen die een eigenschap van het te bouwen systeem aangeven, zijn alleen zinvol wanneer de negatie van die eigenschap ook zinvol kan zijn als eigenschap. En niemand wil een rigide systeem. Dus: opschrijven dat het te bouwen systeem flexibel moet zijn, is een open deur intrappen. Het voegt niets toe. We weten niet meer dan voorheen.
Rugdekking verschaffen
Waarom schrijven mensen dan dergelijke lijstjes met eisen en wensen, en is het maken van zo'n lijst het uitgangspunt van ieder ict-traject? Dat doen mensen om zichzelf in te dekken. Helaas is een groot deel van alles wat er in eisen-en-wensenland gebeurt niets meer of minder dan rugdekking verschaffen. Er mislukken nu eenmaal veel ict-projecten: bij de overheid, maar ook elders, al houden commerciële bedrijven de stront wat liever onder de klep, en loopt de beerput met mislukte ict-projecten daardoor wat minder in het oog. Dus hoe voorkomt je dat een mislukt project je aangewreven wordt? Uiteraard door van álles, maar dan ook van álles wat maar mis kan gaan van tevoren vast te leggen dat het er wel in had moeten zitten. Is het project mislukt omdat het systeem te rigide is? Niet mijn schuld: ik had opgeschreven dat het juist wel flexibel moest zijn.
Hoe moet het dan wel? Eisen moeten concreet zijn. Verifieerbaar en liefst meetbaar. Eisen moeten verifieerbaar zijn wanneer het ja/nee-eisen betreft: het systeem heeft het wel of het systeem heeft het niet. Draait op iOS: dat is verifieerbaar. Alle documenten op te slaan als pdf: verifieerbaar. Een roze rand met bloemetjes om het systeem. Ook verifieerbaar. Wanneer het geen ja/nee-eisen betreft moeten ze meetbaar zijn. 10 petabyte aan ruwe data op kunnen slaan. In twee uur onder de knie te krijgen door een eindgebruiker die er niet eerder mee gewerkt heeft. 99,9 procent uptime. Dat is meetbaar.
Welles, nietes
Maar hoe verifieer of meet je of een systeem flexibel is? ‘Ik vind het best flexibel.' ‘Nou, ik niet.' U voelt het lijk al drijven. Niet-verifieerbare en niet-meetbare eisen en wensen leiden alleen maar tot een eindeloos welles-nietes spelletje.
‘Altijd wenselijke' eisen hebben alleen zin wanneer ze voorkomen in een gewogen lijstje.
Dus: 1) Flexibel, 2) … 10) Schaalbaar. Dit zegt wel iets. Namelijk dat het systeem vooral flexibel moet zijn, en dat dit eventueel ten koste mag gaan van de schaalbaarheid. Alleen zo kun je met dergelijke ‘altijd wenselijke' eigenschappen iets zinnigs uitdrukken. Het doet denken aan het aloude voorbeeld, ‘Fast. Good. Cheap. Pick two'. Je kunt snel een goed systeem maken, maar dat kost geld. Je kunt goedkoop en snel iets maken, maar het zal nog rammelen. Je kunt het goedkoop en goed, maar dat duurt even. ‘Altijd wenselijke' eigenschappen zijn alleen zinvol wanneer het geen eisen zijn, maar items in een prioriteitenlijst: wat heeft voorrang wanneer er keuzes gemaakt moeten worden? Software ontwikkelen zit vol met trade-offs, en nadenken over wat echt belangrijk is en wat niet, is goed. Maar prioriteitenlijstjes zijn geen eisen: het werkt alleen wanneer er ook echt zaken op staan die een lage prioriteit hebben.
De eerste eis die aan alle lijstjes met eisen en wensen gesteld moet worden: als het tegendeel nooit wenselijk is, hoort deze eis of wens niet thuis op een lijstje met eisen en wensen. Bestel u dus alleen nog een systeem dat ‘robuust' of ‘gebruikersvriendelijk' moet zijn wanneer u ook regelmatig eist dat een systeem ‘gammel' of ‘gebruikersvijandig' is.
Marc de Graauw, freelance consultant
Marc,
Erg herkenbaar wat je schrijft. Zeker in aanbestedingsland kom je vaak de meest aparte eisen tegen. Hoe omschrijf/defineer je bijvoorbeeld schaalbaarheid? Dit kan zijn dat er bijvoorbeeld extra disken bijgeplaatst kunnen worden maar het kan ook zijn dat er bijvoorbeeld een 2e stroomstekker bijgeplaatst kan worden.
Zeker met aanbestedingen kan je nog wel eens de meest creatieve antwoorden van de leveranciers terug verwachten.Het is daarom zaak om je eisen zo helder te defineren en waarbij nodig extra toe te lichten.
Doe je dit niet dan is de kans dat je de verkeerde keuzes maakt erg groot.
Eigenlijk raak je een teer punt. Requirements maken is een vak apart. Waar je voor moet oppassen is dat het niet al meteen de oplossing wordt. Dus je voorbeeld op welk OS het moet draaien is al meteen een lastige. Is dat nu de oplossing of een requirement. Beter is dan om te stellen dat het moet draaien op het OS wat door de leverancier is aangegeven.
Een ander punt is dat je moet aangeven wanneer een requirement ingevuld is of niet. En vooral hoe.
Requirements maak je vaak met de klant, maar de klant is altijd eigenaar.
Hoewel ik de toonzetting in het artikel wat betreur ben ik het wel helemaal eens met de auteur. Niemand zit te wachten op een ‘open deuren’ lijstje en door vast te stellen of een requirements verifieerbaar en meetbaar is beoordeel ik zelf vaak hoe goed een requirement is, helemaal waar!
Wat ik nog mis in het artikel is dat er meerdere niveau’s van requirements worden onderkent, van business requirements via gebruikersrequirements tot systeemrequirements. Hierbij geldt dat de systeemrequirements altijd meetbaar/verifieerbaar moeten zijn, anders is de projectopdracht niet helder. Dat geldt in mindere mate voor gebruikersrequirements en in nog mindere mate voor business requirements.
Niemand bestelt een gebruikersonvriendelijk systeem. Dat sluit echter niet uit dat het zeer zinvol kan zijn de gewenste “gebruikersvriendelijkheid” handen en voeten te geven. Niemand bestelt een onbewoonbaar huis, maar toch stellen we allemaal andere eisen aan het begrip “bewoonbaar”.
Dus definieer flexibel, schaalbaar, robuust, gebruikersvriendelijk etc.
Het zijn non functional requirements en ja: je hoeft ze niet te benoemen. Maar waarom zou je het niet doen? Zolang overeenstemming bestaat over de “betekenis van”, “de mate waarin” en “de normen waaraan” wat is er dan tegen? Bovendien kun je pas wanneer die overeenstemming er is een gewogen lijstje maken. Niemand kan weten of flexibiliteit werkelijk belangrijker is dan gebruikersvriendelijkheid als er geen consensus is. Objectiveren dus. Pas als dat niet lukt heb je gelijk.
Het is wat mij betreft dus veel te kort door de bocht om dit soort wensen te diskwalificeren, althans zo komt het op mij over.
Een eenduidig en verifieerbaar programma van eisen (pve) schrijven is een vak apart. Waar het al fout gaat is in de projectfase die voorafgaand aan het opstellen van een pve behoort plaats te vinden: welke keuzepunten, welke hoofdlijnen en oplossingsrichting zal de volgende ICT-infrastructuur moeten gaan bevatten.
Niet wat is de oplossing dat is een taak en deskundigheid voor de markt. Het meetbaar maken van de antwoorden is interessant, zolang het gaat om de inhoud en niet om de “tikfouten”.
Daarnaast een goed PVE gaat veel verder, het dient ook om de post meerwerk, onvoorzien werk en dat soort posten te elimineren. Daarnaast het is ook de basis voor de invoering en de acceptatietest. Kortom een goed pve is meer dan een “wensenlijstje”, namelijk de basis voor een objectief vergelijk en de realisatie-basis van het project dat op de keuze volgt.
Het schijnt dat iedereen er wel van overtuigd is dat requirements toetsbaar moeten zijn. Je wil immers geen welles/nietes discussie aan het einde van het traject. Tenzij het handig is om er mee weg te komen natuurlijk.
Wat mij dan wel uitermate bevreemdt zijn opvattingen dat je dan maar dingen weg moet laten (nonfunctionals) of dat sommige requirements minder meetbaar hoeven te zijn (gebruikers- and business requirements). Basisregel is hoe dan ook dat alles waar je elkaar op wil afrekenen, gewoon toetsbaar (meetbaar, verifieerbaar, ..) moet zijn!
Ach, als ik alleen al even naar de praktijk kijk van de afgelopen, laat ons zeggen 6 maanden tot een jaar, kan ik helaas niet anders dan concluderen dat menig eis/wens, in welke fase van een IT traject, elders zulke problemen opleveren dat de kosten gigantisch uit de klauwen gieren of dat men noodgedwongen stekkers uit projecten trekt.
Dan hebben we het uiteraard niet een over de nonsens in vacature land die heden ten dage plaats vind.
Het is namelijk altijd al zo geweest dat aan het einde van een aanbestedingstraject allerlei addertjes onder het gras vandaan kwamen waardoor in de vervolgfase de nota’s veel gepeperder werden dan men zichzelf rijk had begroot.
Het jammere is een beetje dat ik nergens terug lees dat de materie IT een materie is die prachtig en vrijwel naadloos segmenten operationeel als wel procesmatig goed doordacht op elkaar aan kan laten sluiten.
Ik vraag me dan ook heel eenvoudig af waar plots dan al die discussies vandaan komen, als men die grote klant heeft binnen gehaald als men weet dat men, uit eerdere ervaring puttend, gewoon weet dat dat meerwerk, met begeleidende discussies, er gewoon weer aan zitten te komen als de handtekeningen zijn gezet.
Het is bijna een wetmatigheid zou je denken.
back to basics…
Een pve is niet “een lijstje met eisen en wensen”, dat is hooguit een onderdeel van een pve.
Een pve is wel een document waarin (o.a.) de architectuur en structuur van de beoogde (communicatie-)infrastructuur op functionele wijze (1-1 duidig…) is beschreven. Daarna volgens pas details over de functionaliteiten waar het geheel aan moet voldoen onder welke omstandigheden etc. Gevolgd door de wijze van testen, projectmanagement, invoering, commerciële/juridische overwegingen en de wijze van functionele en financiële evaluatie plaatsvindt.
Wat in veel pve’s gebeurd is, dat er vrij open vragen gesteld worden. Dat zijn vragen waar het antwoord de volgende structuur heeft: Ja, en daarna 80% van de ontkenning of inperking van het “volmondige” ja. Dat soort antwoorden (maar het ligt aan de wijze van vraagstelling, die dat soort antwoorden veroorzaakt) heeft tot gevolg dat een keuze nooit reproduceerbaar is. Veel van dat soort pve’ heben een hoge faalfactor of siginificant meerwerkinvoering tot gevolg, met alle gevolgen voor het project, de invoering en de gebruiksfase……..