Opdrachtgevers raken altijd enthousiast en opgewonden van het idee dat alles straks met een druk op de knop geregeld is. Hun visie is gebaseerd op dat voornemen. Maar soms is dat niet optimaal. In zo’n geval loopt het raderwerkje in hun hoofd al snel volledig vast.

Met een druk op de knop

ITers automatiseren jouw functie weg waar je bij staat. Als opdrachtgever moet het lijken alsof er geen eind komt aan de mogelijkheden van automatiseren van hele ketens van bedrijfsprocessen. Je begint met het digitaal verwerken van de inkoopfactuur, maar als je de ITers hun gang laat gaan blijkt dat je je inkoopfacturen al digitaal kunt ontvangen. Nee, wacht! Je kunt het inkoopproces zèlf automatiseren op basis van de (te automatiseren) voorraadinformatie. En ga zo maar door…

Wat vroeger tijd, opleiding en een hoop papier kostte gaat nu sneller, goedkoper en is eigenlijk …best stoer! Al die grafiekjes op je scherm! Machtig spul, software. Alles geregeld met een druk op de knop.

De doe-wat-ik-wil-knop

Tijdens mijn informaticastudie volgde ik het college User Interfaces.

“De ideale user-interface heeft eigenlijk maar 1 knop, de doe-wat-ik-wil-knop.”

Professor Paul de Bra nam toen een gewichtige adempauze, keek met twinkelende oogjes het publiek in en liet ons zijn wijsheid op ons eigen tempo waarderen. Toen de meeste studenten begonnen te knikken in overeenstemming, ging hij verder

“Maar als het systeem dan zo precies weet wat ik wil, waarom moet ik dan nog op die knop drukken? Die knop is dan overbodig.”

Mijn ontwerp van de kinderversie.

Mijn scherm of jouw scherm?

Mijn klanten hebben meestal een toekomstvisie voor hun systemen rondom een soort gravitatiecentrum: hun eigen computerscherm.

En hoe kun je een ITprobleem binnen dat referentiekader anders oplossen dan door de toevoeging van een knop die je probleem oplost? Natuurlijk is “knop” wat te smal: het omvat ook dat extra rapport, de extra checkbox die je afvinkt, of dat nieuwe formulier (boven de knop) dat je online bezoekers laat invullen. Maar in wezen is dit hetzelfde: je lost het probleem op binnen een scherm, er zal iemand op klikken, in typen, of het zien op het scherm. Vervelend (invul-)werk schuift dan naar andermans scherm, leuke dingen zoals goedkeuring zijn welkom op ons eigen scherm. Software bouwen met de strategie van je one-night-stands. De hamvraag is: Wordt het op mijn scherm of op jouw scherm?

Headless killer-apps

Applicaties zonder scherm noemt men headless. Deze metafoor vindt zijn oorsprong in de opstelling van je desktopcomputer vroeger: de monitor (zo’n toeter) was altijd het rustende hoofd bovenop de schouders van je brommende computerdoos (desktop). Maar deze onthoofding is veel minder gruwelijk…

Het grootste deel van de ècht belangrijke, grootschalige applicaties zijn headless. Banktransactiesystemen, het WWW en eindeloze digitale infrastructuur zijn slimmer en nauwkeuriger juist doordat ze niet wachten tot iemand op het juiste moment op een knop duwt. Ze functioneren goed, zonder knop: je start ze op en ze blijven draaien tot de stroom uitgaat.
Vrij letterlijk zijn veel van deze headless applicaties zó belangrijk, dat ze killer apps genoemd mogen worden, als die stroom inderdaad uitvalt.

Extra scherm extra ballast

Minder risicovolle applicaties, zoals dat hippe, automatische teleconferentiesysteem, of dat evenzo gave projectplanningssyteem kunnen enorm baat hebben van zulke onthoofding. Door zo’n applicatie niet weer een nieuw, eigen gezicht (‘head’) te geven, maar het in de duisternis te laten werken, hoeven gebruikers niet ‘nog een nieuwe user interface’ te gebruiken, die niet werkt in hun InternetExplorer of waarvan ze de URL niet kunnen vinden.

Recentelijk ontwierp ik bijvoorbeeld een scherm waarop iemand een PDF kon downloaden, zoals de klant vroeg. De gebruiker zou de link naar dat scherm via e-mail ontvangen.
Uiteindelijk heb ik klant en gebruiker dat hele scherm bespaard: we hechten de PDF nu gewoon aan die mail!

Ik vergeet soms zelf voldoende afstand te nemen om op te kunnen merken dat je schermfuncties kunt weglaten. Maar vaker wìl de klant er gewoon niet aan: de radertjes in zijn/haar hoofd lopen vast als je het scherm uit het plan haalt.

Mashups in duisternis

Web2.0 was bracht ons Mashups: een nieuw schermpje door de koppeling van onafhankelijke, bestaande webapplicaties. Iedereen was er dolenthousiast over. Maar het koppelen is interessanter dan de mashups! Steeds meer bestaande applicaties faciliteren headless uitbreidingen. Zo kun je weer werk verzetten zònder dat iemand zich ermee bemoeit, in een soort digitale duisternis. Dàt is pas echt automatiseren: Zònder user interface werken systemen … vanzelf.

Jan, gebruiker

In softwaremaatwerkland lijdt Jan-op-de-werkvloer onder conventionele wijsheid van zijn manager, die een IT systeem laat bouwen voor Jans afdeling. Het meest storende gevolg vind ik de datamodelgedreven interactie waarmee Jan opgezadeld wordt.

Laat ik eerst uitleggen wat datamodellen zijn.

Datamodellen

Tegenwoordig slaan vrijwel alle zakelijke applicaties hun gegevens op in SQL databases. Het principe daarvan is niets meer dan een verzameling tabellen, bestaande uit kolommen met ruwe data (je geboortedatum, je naam, de productcode) en speciale kolommen met regelnummers uit andere,soortgelijke tabellen.

IT managers met een opleiding in de jaren 70/80 (of autodidact) hebben geleerd om databases te ‘modelleren‘. Dat is het zo handig mogelijk opdelen van bedrijfsgegevens in tabellen. Modelleren is een truucje: als je het doorhebt is het eigenlijk heel simpel.

De opdrachtspecificatie van maatwerk bestaat, omdat dat dat nu immers het domein is van voornoemde demografische groep, dan ook meestal vooral uit database-velden: de kolommen van de tabellen. Daar wordt lang en zwaarwichtig over gediscussieerd. Daar voelt men zich veilig en gezaghebbend bij. En dat vindt iedereen tenslotte prettig!

Datamodelgedreven interactie

De inhoud van de SQL tabellen zit diep verborgen onder de motorkap van de applicatie. Echter, door de grote nadruk die managers/klanten leggen op het opslagformaat (de kolommen en tabellen) zetten zij software-ontwikkelaars impliciet onder druk om, op het scherm, te tonen dat de applicatie inderdaad voldoet aan een datamodel.  Zo wordt elk scherm een afspiegeling van de tabelvorm van zijn onderliggende gegevens.  Daarom zien bijna alle schermen eruit als een Excel-blad: een schermvullende tabel.

De knoppen waarop je klikt en de invoervelden zijn later toegevoegd, volgens conventies. Het gevolg is dat de applicatie de acties wel uitvoert zoals gespecificeerd, maar op een hele saaie, inefficiënte en bovenal verwarrende manier. Immers, het conceptueel model van de interactie is gebaseerd op machine-efficiënte gegevensopslag, niet op efficiënt applicatiegebruik of een prettige ervaring. Of om het anders te zeggen: Het is een chassis zonder interieur, zonder pedalen en vooral zonder een stuurwiel. Geen wonder dat het oncomfortabel voelt.

Herken datamodelgedreven interactie

Hoe herken je nu datamodelgedreven interactie? Welnu, ten eerste natuurlijk aan de overdaad aan tabellen, vooral met veel kolommen die je nu niet nodig hebt: je moet dus turen naar welke kolom de gegevens bevat die jij zoekt voor je taak. Als het niet op het scherm past maken we de letters gewoon wat kleiner…

Maar er is nog een teken aan de wand: Bij het uitvoeren van je taak doorkruis je meerdere schermen, waarbij je op elk scherm een ander stukje informatie aan het systeem moet voeren.

Voorbeeld:

Je systeem registreert de teams van de voetbalvereniging. Het datamodel bewaart leden en teams gescheiden, elk in hun eigen tabel. Elk seizoen wijzigt de teamindeling en de klasse van elk team. Dat levert je veel werk op, want je moet

1. het bestaande team opzoeken (scherm 1) en dat “archiveren”
2. een nieuw team aanmaken van de juiste speelklasse(scherm 2) en dat “starten”
3. een teamlid opzoeken (scherm 3) op naam
4. het teamlid toevoegen aan het nieuwe team (scherm 4)
5. voor alle andere 10 spelers stap 3 en 4 herhalen (schermen 5..24)
6. voor alle andere 6 teams stap 1/tm 5 herhalen (schermen 25..144)

Geen wonder dat je daar tegenop ziet!

NB. Ik laat het aan u over zelf een slimmere, gecombineerde manier te bedenken zodat de taak in 1 of 2 schermen klaar is. Hint: teams veranderen relatief weinig.

Datamodellen zijn een ’solution’

De datamodellen in de specificatie zijn zelf een ’solution’: een IT oplossing op zoek naar een probleem. Het probleem van gegevensopslag speelt namelijk nog helemaal niet tijdens de eerste vergaderingen over een mogelijk nieuw IT systeem. De wereld is veranderd sinds de jaren ‘80: het datamodel is meestal onbelangrijk.

In plaats van te vergaderen over datamodellen zou de IT manager moeten praten over

1. welke acties de mensen op de werkvloer met de applicatie moeten uitvoeren en
2. hoe de daarbij benodigde informatie gecondenseerd en in de juiste context aan hen gepresenteerd wordt.

En als je iemand betrapt op het voornemen vooral tabellen te gebruiken, “lekker makkelijk, zoals iedereen gewend is, van Excel”, bedenk dan dat dat eigenlijk zonde is van duur maatwerk: dat kan vrijwel gratis met gespecialiseerde tools en zelfs – hoe kan het ook anders – met Excel zelf!

• de huur van een server,
• de bepalingen in het onderhoudscontract, of
• de afspraken over aanlevering van operationele gegevens

Maar vooral ook afspraken met en over mensen en de operationele organisatie liggen op het bordje van de productmanager, zoals

• het voorbereiden van een gebruikerscursus,
• een marketingcampagne voorbereiden of
• het aanstellen van een applicatiebeheerder

Je zou bijna vergeten dat de productmanager verantwoordelijk is voor de zakelijke inhoud van de software in ontwikkeling! De bouwers zullen ervoor zorgen dat het product opstart, rekent en misschien zelfs “gebruiksvriendelijk” is. Maar hij moet ervoor waken dat het product de investering waard wordt.

Conceptuele Integriteit

Ik zie een leidraad die de product owner kan volgen tijdens de ontwikkelingsfase. Hij moet streven naar Conceptuele Integriteit. Eigenlijk beantwoordt hij doorlopend de vraag: Kan elke functie in de applicatie zijn eigen broek ophouden?

Concept. Integer. Twee moeilijke woorden. Het woordenboek helpt ons gelukkig op weg:

Concept:

Algemeen idee, Intentie, Bedoeling

Integer:

1. Eerlijk en oprecht zijn, morele principes

2. Compleet en inwendig samenhangend. Solide constructie.

Streven naar conceptuele integriteit betekent letten op de Compleetheid, Samenhang en Consistentie ten opzichte van de zakelijke Intenties. Laten we daar eens induiken.

Compleetheid

Een softwareproduct moet in meerdere opzichten compleet zijn, af zijn.

Puzzelstukjes

Bovenal vervult de software een paar stappen van een bedrijfsproces. Elke stap moet het product netjes uitvoeren en elke stap moet ook netjes aansluiten op zijn naburige stappen in de workflow. Mens en machine wisselen hun beurt af om samen een taak uit te voeren. Op de overdrachtspunten tussen beide moet de software netjes in de organisatie passen.

ontbreekt er een puzzelstukje?

Maar ook de gegevens binnenin de software moeten volledig zijn. Gegevensbestanden moeten foutloos ingeladen kunnen worden, per bestand, database of met een externe koppeling.

Mag ik er even bij?

Complexere organisaties vereisen tenslotte ook nog een hiërarchisch systeem van applicatierollen en daaraan gekoppelde rechten. De rechten van elke rol moet de volledige taak van een persoon met die rol ondersteunen. Dat betekent dat elke gebouwde functie die nodig is om de rol op je te nemen ook tot je beschikking staat. (Genoeg rechten.) Door het proces na te spelen blijkt al snel waar nog rechten ontbreken, of welke rollen  teveel rechten hebben. (“Verrek! De conciërge mag de directiesalarissen wijzigen! Oeps.”)

Samenhang & Consistentie

Dat een applicatie alle functies op de lijst van eisen bevat, wil nog niet zeggen dat ze ook te gebruiken zijn. De samenhang van functies en de gelijkvormigheid van systeeminteracties maakt de applicatie voorspelbaar en breed inzetbaar.

Anders dan de rest

Eén stijl

Ten eerste moet de lay-out consistent zijn. De kleuren, lettertypen en de vlakverdeling zijn een houvast voor de gebruikers. Ze maken de applicatie herkenbaar en bieden houvast bij navigatie (“waar ben ik?”). Doordat alle webapplicaties in dezelfde browser, hetzelfde window op je scherm staan is dit tegenwoordig onmisbaar.
En als de gebruikersinterface steunt op een metafoor, moet die metafoor ook consequent doorgevoerd zijn.

Eén ding, één naam

Ook de terminologie snakt naar consistentie. Als je bijvoorbeeld klikt op een link die belooft te leiden naar een “Registratieoverzicht”, mag de pagina waarop je uitkomt niet “Inschrijvingenrapportage” heten, ook al is dat synoniem. Dezelfde naam voor hetzelfde artefact door de hele applicatie dus.
Soms is dit verrassend lastig, omdat bij automatisering van bedrijfsprocessen taken voor het eerst een unieke naam moeten krijgen. Een nieuwe naam bedenken dus en die meteen consequent inzetten, zowel in de applicatie (makkelijk) als in de organisatie (moeilijk).

Eén taak, één manier

Tenslotte moeten systeeminteracties gelijkvormig zijn. Als je een weekrapportage op dezelfde manier opvraagt als de jaarrapportage, hoef je die handeling maar één keer te leren om het allebei te kunnen.
En als je beide rapportages exporteert, voelt het natuurlijk raar als er één in Excel97 en de ander in Excel2007 formaat uitkomt. (Eigen ervaring!)

De keerzijde

Nu een situatie uit het harde leven. Met Conceptuele Integriteit heb je als productmanager telkens alle features waaraan men begonnen is, vol vertrouwen naar vervolmaking gestuurd. Het projectbudget is bijna op, oplevering (van de Scrum sprint) in zicht. Gesteund door je toetsing aan Conceptuele Integriteit concludeer je geschrokken dat één applicatieonderdeel nog niet klaar is. Maar er is ook niet genoeg budget meer om het af te bouwen. Het is geen extra investering of vertraging waard. Wat dan?
Welnu, dan snijd je het rottende orgaan uit de patiënt. Een half werkend feature is geen feature. Het is ballast.

Auw! Dat doet zeer dokter!

In Scrumprojecten, adviseer ik de klant (product owner) over Conceptuele Integriteit, in plaats van er zelf over te beslissen. Dat is een ‘world of pain’.  Ik vermoord niet alleen het hobbyproject van een collega, maar ik doe ook de klant pijn als ik vraag afstand te doen van een half voltooid feature. Dit voelt de klant als een misdaad, als kapitaalvernietiging. Houd de tissues in de aanslag!

Waardeloze, kostbare ballast

Jammer maar helaas

Maar een onaf feature is ballast:

• het belooft een ontwetende gebruiker waarde en stelt hem dan keihard teleur
• het levert negatieve, nettowaarde
• het verwart ontwikkelaars tijdens onderhoud. “Wat is dit nu weer? Dit werkt niet eens!“
• het neemt waardevolle ruimte in, op het scherm en in ieders gedachten

De tijdsinvestering die gemoeid is met het orgaan heeft geld gekost. Maar kapitaal is het niet, want die investering heeft geen waarde opgevelerd. Wat aan het eind van de rit niet werkt, dat zet je buiten de deur. Een programmeur wist alle sporen ervan, de onafgeronde resultaten gaan in quarantaine (versiebeheersysteem) en daarna praten we er niet meer over. Een gezondere applicatie is het resultaat.

Het beoordelen van conceptuele integriteit vereist domeinexpertise en een zakelijke blik. Het is soms confronterend, maar zeker de moeite waard. En als de applicatie dan live gaat, is de kans het grootst dat alle betrokkenen werkelijk iets te vieren hebben wat later geld oplevert!

Met dank aan Marco Plaisier, sparringpartner in de voorbereiding en aangever van de term Conceptuele integriteit.

Grootste gemene deler

De meeste software waarmee we dagelijks werken is ontwikkeld voor een enorme groep mensen. Producten als Word, Windows (of Mac OS) en zelfs de software in je mobieltje vallen in die categorie. Al die mensen willen een beetje van hetzelfde, maar heel veel verschillends. Zo’n product kun je alleen bij de massa aan de man brengen als je mensen tevredenstelt: de kern van hun behoefte bevredigen. Oftewel: dit zijn producten die gaan voor de grootste gemene deler van de functies. Massaproducten voldoen nooit aan al je wensen.

Complete verzameling

Maar in de wereld van maatwerksoftware ligt dat anders. Omdat de opdrachtgever het beste weet wat zij wil kunnen met het product is zij de enige die kiest welke functies we inbouwen. De specialist die de productwensen in detail bespreekt met de opdrachtgever levert een lijst functies - het programma van eisen –  op, die de grootste gemene deler zijn van …. een handjevol personen. Oei..

Dit programma van eisen kost veel tijd en moeite van alle kanten, maar hoe meer opdrachtgevers (collega’s, zakenpartners) ernaar kijken, hoe meer punten eraan toegevoegd worden. Het is geen grootste gemene deler. Dankzij het poldermodel is het de complete verzameling van uitgesproken wensen.

De schaar erin

De hele lijst past niet in het budget noch de planning. Met deadlines om de hoek en een oprakend budget wordt iedereen wat ongeduldig. Dan komt onvermijdelijk het kiezen of delen, dus met MoSCoW (of anderszins) gaat de schaar in de lijst. Maar wie maakt die keuze? Meestal is dat de gepijnigde opdrachtgever die het project betaalt. 

Ik observeer deze kleine marteling dagelijks, met gepast medelijden. Stel je voor dat je al je medewerkers enthousiast hebt gemaakt. Iedereen kwam met goede ideeën en elk idee bleek nog aantrekkelijker nadat de eisenspecialist ze op papier zette. En nu moet je dus kiezen tussen

• Jans kostenbesparende functie, of 
• Pieters informerende functie, of 
• Chantals klantwervende functie, of
• je eigen al-zeg-ik-het-zelf-best-wel-goede-idee voor een functie

Je bent gewend te kiezen uit meerdere opties voor  één kwestie, maar dit zijn allemaal opties met elk hun eigen kwestie! Er valt niks te vergelijken! 

Afkicken

Er bestaan keuzehulpjes die je aandacht richten op Return on Investment, PR-waarde of stakeholder-buy-in. Maar het blijft een ontzettend afkicken. In de roze fantasiewereld van het eisenpakket is alles mogelijk. Dan hoef je niemand teleur te stellen. Betrokkenen verworden tot verslaafden in het prioriteringsproces. Ze zeggen 

• Meer geld! Meer tijd! Ik moet die functie hebben. (geldverslindend)
• Zonder deze functie heeft het het project geen zin meer. (suïcidaal)
• Zit je me nu te belazeren? (paranoïde, wantrouwig)

Daag een eis uit

Ik heb geen definitief antwoord. Ik merk dat mijn opdrachtgevers het verhelderend vinden wanneer ik ze uitdaag: “Ach, dit kunnen we wel schrappen hè?” of “Je gelooft zelf toch ook niet dat deze functie ooit zijn investering terugverdient?” Kortom, vrij boute stellingen. Als er conflict ontstaat is de functie kennelijk de moeite waard om voor te vechten. Anders gaat het in de prullenbak.

Wie strijdt voor gebruiksvriendelijkheid

Maar in deze ondervragingstaktiek schrapt de klant vlotjes alle gebruiksvriendelijkheidspunten op de lijst. In dit blog lees je al dat gebruiksvriendelijkheid te beargumenteren valt, maar meestal is het juist de opdrachtgever die daarvan overtuigd moet worden. Zo kiest dus bijna elke opdrachtgever voor een extra functie, ten ongunste van de gebruikersinterface. Dat stelt enkelen op korte termijn tevreden – je keus voor Pieters suggestie voelt hij als een compliment – maar velen uiteindelijk teleur: iedereen klaagt steen en been over de moeizame ingebruikname van het systeem. 

De UCD expert (ik) zou dus juist de functie moeten verdedigen in een soortgelijk steekspel met de opdrachtgever. Maar daarvoor moet de opdrachtgever inzien dat ze misschien toch niet alles weet van haar eigen toko. Natuurlijk kan je haar met prototypes laten ‘voelen’ wat gebruiksvriendelijkheid oplevert, maar dan moet je eerst wel toestemming hebben om die te ontwikkelen. Soms zie ik daarvoor alleen burgerlijke ongehoorzaamheid als uitweg. En dat is precies wat ik zou adviseren: Tolereer een gezonde mate van dwarsheid van je softwarebouwers. Ze zijn niet alleen je dealer. Ze kunnen ook je afkickbegeleider zijn…