We stonden bij het laboratorium van een ziekenhuis waar we al een paar jaar niet waren geweest. Puur toevallig was daar net die dag het nieuwe ziekenhuisinformatiesysteem live gegaan.
De conversie van het oude systeem was blijkbaar goed gegaan want al onze gegevens stonden er nog in, inclusief het polisnummer van een verzekering die we al een paar jaar niet meer hadden. Dat moest dus nog even bijgesteld worden. Bij het invoeren van de ingangsdatum daarvan ontstond echter enige verwarring. We wisten eigenlijk niet meer in welk jaar we waren gewisseld van verzekering.
Wat zou nou een logisch antwoord zijn? Je kunt natuurlijk wel de echte ingangsdatum opgeven, maar in de logica van een boekhouder doet die er niet toe, want het vorige jaar is toch al afgesloten. Het systeem dacht daar blijkbaar ook zo over, want een datum in het verre verleden leidde tot de onverbiddelijke foutmelding: ‘De ingangsdatum van de nieuwe verzekering moet na 1 januari 2011 liggen'.
Na drie keer tevergeefs invoeren van 01-01-2011 werd er een collega bijgehaald. Die wist het ook niet, en daarna boog de ‘key user' zich over het toetsenbord. Na tien minuten stonden ze al op het punt om de helpdesk te bellen tot er iemand op het idee kwam om 02-01-2011 in te voeren. En voilá, dat werkte.
Is dit nu logisch? De it'er zegt natuurlijk van wel: 'na' betekent 'groter dan', en niet 'groter dan of gelijk aan'. Maar gezien het feit dat hier drie mensen een minuut of tien mee aan het pielen zijn geweest was er blijkbaar toch iets onlogisch aan. In dit land is de verzekeringslogica namelijk dat je alleen per de eerste van het jaar kan wisselen van verzekering, normaal gesproken. Vanuit die logica is de foutmelding niet te snappen.
Natuurlijk kun je zeggen dat de instructie klopt. Maar dan nog kun je een betere instructie maken. Zeg dan gewoon: ‘Voer een ingangsdatum vanaf 2 januari 2011 in'. Dan hoeven al die gebruikers daar in ieder geval niet over na te denken, en kunnen ze hun aandacht besteden aan de klant.
Voila, de IT oplossing is gewoon de eisen aanpassen aan het systeem.
Geen wonder dat zoveel IT projecten mislukken.
Want een ingangsdatum 1-1-2011 is nauurlijk iets anders dan 2-1-2011 – wie betaalt anders de dure operatie op 1-1-2011 – de arme patient zelf zeker??
Zouden ze wel eens van grenswaarden testen hebben gehoord. Nee zeker. Zou verplicht moeten zijn voor ieder project.
Mooi en realistisch praktijkvoorbeeld.
Moet er ook altijd om lachen als ik “van a tot z” zie staan. Z zelf doet blijkbaar niet mee.
Gebruiksvriendelijkheid is een tienkoppig monster, handig als je er meerdere mensen naar laat kijken en je ook echt usabilty testen laat uitvoeren.
Mijn ervaring is daarin overigens wel dat de kosten hiervan erg hoog zijn en dat het daarom vaak niet gedaan wordt.
Daar gewoon de commentaar van gebruikers te registreren zoals in jouw voorbeeld, wordt het programma ook vanzelf steeds beter.
Functionele testers (gebruikersacceptatie) moeten geen ervaren geleerde koppen zijn, maar van de straat/werkvloer geplukte mensen zijn. Die zich suf zoeken naar een miniknopje en in ogen van ontwikkelaars onlogische jip&janneke menustructuren verwachten.