Regelmatig hoor je het weer. Automatiseerders zijn techneuten. Ze kijken niet wat de gebruiker wil. Ze komen met technische oplossingen waar niemand om vraagt, en daarom mislukken al die projecten. Om een it-project tot een succes te maken, moet je niet van de techniek uitgaan, maar eerst eens gaan vragen wat de gebruiker nu eigenlijk wil.
Het oude, vertrouwde model. We gaan de gebruiker vragen wat die wil, en schrijven dat heel precies op, in User Requirements, of Eisen en Wensen of zoiets. Dan laten we daar een partij informatie-analisten op los, die deze informatie analyseren, en zo nog een paar stappen verder komen we met een functioneel ontwerp, en dat laten we ondertekenen door de gebruiker met diens eigen bloed, zwerend op al wat voorhanden is, dat dit toch écht (maar dan ook écht) is wat hij of zij wil. En dat bouwen we dan (wat altijd veel en veel duurder is dan verwacht, en veel en veel langer duurt, want waar in dit verhaal komt nu voor wat de techniek wel kan en niet kan, en wat makkelijk gemaakt kan worden en wat niet).
En als het dan af is, is het niet wat de gebruiker wil. Niet vreemd, want dit gaat uit van twee veronderstellingen:
1. De gebruiker weet wat hij of zij wil.
2. De consultant kan dat vertalen naar een oplossing.
Beide veronderstellingen zijn onjuist. Een gebruiker weet niet wat hij wil. Wanneer je een gebruiker vraagt wat hij wil van een informatiesysteem, dan krijg je te horen wat het huidige informatiesysteem kan, en waar de gebruiker niet tevreden over is. Wanneer je dat als uitgangspunt neemt krijg je dus op zijn hoogst een opgepoetste versie van het huidige systeem. Dat is niet gek. De gebruiker is zelf iemand met een vak, een specialist op zijn eigen gebied. De verzekeraar loopt warm voor sterftekansentabellen, de internist weet alles van poliepen en de bakker houdt van rijzen en kneden. Innovatie door inzet van ict-middelen hoort daar normaliter niet bij. Vraag de gebruiker dus niet wat hij wil: dat leidt tot middelmatige systemen, gebaseerd op achterhaalde technologie, en zonder gebruik van de mogelijkheden die nieuwere technologie (internet, mobiel, social media et cetera) biedt.
Witte raaf
In een enkel geval loopt het anders. Soms tref je een witte raaf. Een vakmens die in staat is een stap terug te doen, te kijken naar het hele proces, en op waarlijk innovatieve wijze te kijken naar wat mogelijk is. Wat anders kan. Wat met nieuwe technieken opeens wél kan. Dat is een mazzeltje, want witte raven zijn zeldzaam. Maar zelfs dan is het verstandig niet al te lang naar de witte raaf te luisteren.
Want het tweede probleem blijft. Natuurlijk kan de consultant (automatiseerder, informatie-architect, organisatiekundige, business consultant, nieuwste-rage-goeroe, vul maar in…) dat niet. Die is namelijk zelf vakmens in het eigen vak, dus snapt in principe maar net-aan waar die gebruiker het over heeft. Laat staan dat dit vakmens, die toch tijd en energie in het verwerven van het eigen metier heeft gestoken, echt inziet hoe het vak van de gebruiker werkt, en hoe dat beter kan. Dus gaat de consultant, bij gebrek aan echt inzicht, dat al snel opvullen met datgene waar hij of zij wel verstand van heeft, namelijk techniek. De consultants die het best in het eigen vak zijn, zijn geeks: mensen, die alles weten van iets. Van Internet, of mobiel, of social media. Die daarmee kunnen toveren. Maar dan zonder te begrijpen wat die gebruiker er écht mee kan of wil.
Bruggenbouwer
Soms gaat het iets beter. Soms tref je een bruggenbouwer. Een consultant, die zich in een vak (niet alleen het eigen!) verdiept heeft en wél iets weet van het vak van de gebruiker. Er misschien zelfs enige passie voor voelt. Of vroeger gebruiker was, en uit passie voor de techniek de ict in is gedreven. Maar zelfs dan is het verstandig niet al te lang naar de bruggenbouwer te luisteren. Want ondanks de passie: de kennis voor het vak van de gebruiker gaat niet zo diep. Of bij de omgeschoolde bruggenbouwer: de kennis van het gebruikersvak is inmiddels toch minimaal wat roestig en verouderd geworden.
Hoe het dan wel moet? Ten eerste moeten we het gebrek aan kennis als uitgangspunt nemen. Noch de gebruiker, noch de consultant weet precies wat er gebouwd moet worden. En dat gebrek aan kennis moet opgevangen worden met een surplus aan praktijk. Dus eerst met een lampje zoeken naar alle witte raven en bruggenbouwers die je kunt vinden. Want die hebben we wel nodig.) Laat die, met een paar geeks erbij (want die heb je ook nodig), een schets maken. Liefst iets geks, wat helemaal niet realiseerbaar of wenselijk is, omdat het veel te gedroomd is en helemaal niet lijkt op wat de gebruiker wil.
En maak dan een eerste systeempje, snel en krakkemikkig en niet te groot, en ga dat in de praktijk testen. Kijken wat het doet als er mee gewerkt wordt. Dan valt er vanzelf wel af wat écht niet realiseerbaar of wenselijk is, dan blijkt wel wat droom moet blijven, en wat de gebruiker écht nodig heeft en wat er dus tóch nog bij moet komt ook wel bovendrijven. En zo ga je verder, nog een stap, en nog een stap, en dan komt er wel een systeem. Eén waarvan de gebruiker nooit gedacht had dat hij dat wilde. Maar innovatie begint niet met luisteren naar wat de gebruiker wil. Innovatie begint met een droom.
Marc de Graauw, freelance consultant
Je moet de wereld niet geven waar ze om vraagt, maar wat ze nodig heeft.
— Edsger W. Dijkstra
Een amerikaanse medewerker van Microsoft vertelde eens hoe zij intern communiceerden met gebruikers. Het verandert alleen de volgorde van op te leveren zaken en is een ideale kapstok voor alle partijen om – ieder op hun eigen abstractielaag – met elkaar te laten communiceren: maak het eerst zo gedetailleerd mogelijk de gebruikers- en beheerdocumentatie.
Daarbij komt als het goed is alles aan de orde: welke standaards worden op welke wijze ondersteund voor connectiviteit, etc. Je dwingt daarmee alle partijen zich te verplaatsen naar wanneer het opgeleverd is en het is een arbitragemiddel voor de schuldvraag bij gebleken misverstanden. Voldoe daarna aan alle voorwaarden die vanuit je expertise van belang zijn en voor anderen (nog) niet relevant.
Ik heb het een aantal keren geprobeerd en het is knap lastig. Maar er dienden zich wel direct een aantal valkuilen aan die anders ontstaan zouden zijn.
@J$ yepp, maar het citaat van Dijkstra is wel erg afgeleid van de uitspraak van Henri Ford.
‘Als ik zou vragen wat mijn klanten willen, dan zouden ze vragen om snellere paarden’
Zolang klanten onredelijke eisen stellen, verkopers accoord gaan met onredelijke eisen, en techneuten niet vooraf melden dat de eisen onredelijk zijn, zal er niets veranderen.
Resumerend, er zal niets veranderen.
Sommige bedrijven hebben gewoon iemand in dienst die zich bij de klant probeert in te leven.
Als die consultant dan voldoende onderlegd is om de tech colegas uit te leggen wat nu eigenlijk de wens is, dan is er nog hoop.
Zo niet, dan maken we ons aleen maar druk over het aantal stippeltjes en de kleurtjes op de website.
Wordt hier niet gewoon een Agile methode uitgelegd? Wat is hier nieuw aan (kortom: vertel me, onderbouwd, dat ik het verkeerd zie).
Of wat algemener: van een volledige fase-voor-fase V-model naar een iteratief proces (bv Agile).
Natuurlijk moet je wel luisteren naar de gebruiker.
Het gaat fout als de gebruiker met oplossingen komt en de IT-er ze klakkeloos overneemt (dat zijn de IT-ers die zich niet kunnen voorstellen dat er ook mensen zijn zonder verstand van IT).
De ideale gebruiker vertelt wat zijn werkelijke behoefte is (ik wil me sneller kunnen verplaatsen) maar de gemiddelde gebruiker heeft zelf al nagedacht over mogelijke oplossingen en hij vraagt om de zijns inziens beste oplossing (een sneller paard).
Een slechte IT-er gaat een sneller paard leveren. Een goede IT-er zal de werkelijke behoefte van de gebruiker achterhalen en vervolgens, gebruikmakend van zijn vakkennis, een oplossing voorstellen die het beste aan de behoefte van de gebruiker tegemoetkomt.
Vergelijk het met een patiënt die bij de huisarts vraagt om een bepaald medicijn: een goede huisarts zal vragen wat de klachten zijn, een diagnose stellen en dan pas bepalen met welke behandeling de patiënt het best geholpen wordt.
@Rob:
Ik begrijp uit jouw verhaal niet welk systeem men daar dan gebruikt. Zou je dat kunnen verduidelijken?
Ik kan me volledig vinden in de aanbevolen methode. Bepaal een maximum budget ( tijd, geld). Maak hiermee een eenvoudig prototype zonder toeters en bellen en ga ermee aan de slag met de gebruikers. Dan komen de serieuze specificaties vanzelf en kun je realistisch begroten. Dromen kunnen dan na wat bijstelling best uitkomen.
Het valt overigens niet mee om opdrachtgevers hiervoor warm te krijgen. Die willen vaak toch een offerte van de verkoper en sturen dan vooral op tijd ( snel beginnen)en zaken die zij belangrijk vinden.
voor iemand die me uit kan leggen hoe ik dit verhaal succesvol verkoop aan klanten.
Helaas geloven veel mensen in het proprietary model. Software is een product. En een product is klaar als je het koopt. Liefst met garantie van 3 jaar.
Hoe leg uit dat het bij software niet zo werkt? Hoe overtuig je klanten dat het uiteindelijk wel goed komt, maar dat je eerst door een artistiek proces heen moet? Waar plaats je betaal momenten?
@100 euro
Het werkt ook niet zo, je maakt de denkfout dat een klant software wilt aanschaffen, dat is namelijk niet zo.
De klant wilt een dienst afnemen, wat eventueel in de vorm van een softwarepakket komt. Het is dan ook de dienst waar de klant voor wil betalen en dat zou je kunnen opsplitsen in termijnen en in plaats van garantie kun je een SLA afspreken. Het betalen begint op het moment dat de dienst naar tevredenheid van de klant wordt afgenomen.