Maatwerksoftware is een drug

February 22nd, 2009 auteur: Felix Ogg | onderwerp: User Centered Design, bedrijfsproces, requirements.

Je baas gunt je een smak geld om software te laten bouwen door vaklui. Maatwerk is een verslavend fijne ervaring. Zowel opdrachtgever als bouwer worden high. Maar verslavingen hebben een keerzijde: Meestal lijden de eindgebruikers pijn.

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…

Tags: ,

Share Your Thoughts