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
@mm: De gebruikersdocumentatie beschrijft voor de gebruiker in detail waar hij mee gaat werken en voor de ontwikkelaar waar hij zich aan moet conformeren. Door de handleiding vooraf te schrijven, vertaalt de ontwikkelaar de consequenties van voorgestane architectuur en technologie naar gevolgen voor de gebruiker. De gebruiker weet daardoor van te voren dat hij bij dit paard een voet nodig heeft om mee te ontkoppelen waardoor hij tijdig met bezwaren kan komen en uitleggen dat ie natuurlijk niet voor niks zo stom is om een sneller paard te vragen.
Het vooraf schrijven van gebruiks- en technische documentatie staat andere vormen van projectbeheer natuurlijk niet in de weg.
Wie zegt dat een ICT consultant een technische achtergrond moet hebben? Bekrompen visie. Het devies is dat je als consultant helemaal geen expert moet zijn in wat dan ook en al helemaal niet op technisch gebied. Als er al een “geek” nodig is dan moet dat iemand zijn die het primaire proces waarin de gebruiker acteert kan doorgronden en de gebruiker helpt met het formuleren van wensen en eisen aan benodigde functionaliteit. Een goed ICT traject bouwt (of kiest) daar vervolgens een slimme oplossing voor die al dan niet als dienst wordt geleverd. Wat dat betreft 100% eens met Guido Groeneweg.
Waar het op neerkomt is dus: luister niet naar de gebruiker als die met een technische oplossing komt, maar luister zeker niet naar een technisch consultant die niet heeft geluisterd naar de gebruiker.
“A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system.” John Gall.
@cpt e.a. : Agile gaat over het algemeen over de uitvoering, dat is een later traject.
IT en software zijn helemaal niet zo moeilijk, je moet alleen weten *wat* je kunt automatiseren en tot hoe ver je kunt gaan de echte wereld na te bootsen.
Om techneuten, business analisten en de (potentiele) klant op 1 lijn te krijgen is het handig een domein te beschrijven, beetje domain driven design (DDD) dus. Hoe ziet de wereld van de klant of gebruiker eruit.
Daarnaast is het belangrijk dat je beseft dat elk bedrijf bestaande processen heeft en dat deze al uitgevoerd worden. Bij sommige bedrijven worden processen redelijk uniform uitgevoerd, bij andere bedrijven zijn mensen nauwelijks bewust van deze processen en van uniforme uitvoering; de parate kennis van een medewerker heeft sterke invloed op de uitvoering van het proces.
Mijn beleving is dat het niet zo heel erg uitmaakt welke methodes gebruikt worden om tot software ontwikkeling te komen, de kwaliteit van de mensen die het team vormen hebben in mijn ogen veel meer invloed op de succes van het project.
Als op 1 na laatste wil ik nog kwijt dat je OF de software veranderd OF het proces veranderd. Software gebruiken om een proces te veranderen is vaak te complex en gedoemd te falen. De uitzondering is natuurlijk dat als je standaard software koopt je maatwerk moet vermijden en dat dit dus leidt tot organisatorische veranderingen (je adopteert de processen van de software en past je organisatie hierop aan).
Ten slotte wil ik nog benadrukken dat je bij het inzetten van software twee keuzen hebt: Standaard software of volledig opnieuw gebouwde software. Standaard software aanvullen met maatwerk verlies je het voordeel van volledige zelf gebouwde software en de besparing op licenties. Blijf je aanlopen tegen beperkingen en ben je elke keer het haasje als de standaard software veranderd.
Dat is mijn beeld op bedrijfssoftware in een notendop.
Dit alles is zeker niet nieuw. (Beetje vreemde opmerking trouwens, alsof het zo zou werken dat iemand iets nieuws bedenkt, dat eenmalig publiceert en dan de hele sector voortaan zo werkt.)
Het deel over stap voor stap ontwikkelen is Agile, en dat vertelde ik 20 jaar geleden al, al was Agile toen nog een woord uit het woordenboek en noemden we het ‘incrementeel’ of ‘evolutionair ontwikkelen’ of ‘prototyping’. Ik denk het over 20 jaar nog steeds te roepen.
Het grootste punt is echter zeker niet specifiek Agile. Agile methoden hebben eerder nog meer dan traditionele de neiging te luisteren naar de gebruiker (al onderkennen ze dat requirements kunnen veranderen tijdens de bouw). Ook bij Agile is het een valkuil wat de gebruiker zegt teveel ‘at face value’ te nemen.
Mee eens dat verkoop een probleem kan zijn. Sommige klanten vragen een systeem van 100 miljoen, op basis van een meterdik pak papier, wat dan precies zo gebouwd moet worden en op een bepaalde datum af moet zijn. Probeer dan maar eens ‘nee’ te zeggen als softwarebouwer. Maar dit betoog is dan ook zeker net zozeer gericht aan de inkopers die dit soort dwaze dingen doen.
Dank voor de mooie quotes van Dijkstra, Ford, Gall.
Me dunkt dat veel gebruikers wel degelijk weten wat ze willen als er sprake is van nieuwe functionaliteit. Het simpele feit dat ze aangeven dat ze iets willen betekent al dat ze er over nagedacht hebben en vaak is dat iets wat zij bij de buurman of vriendjes hebben gezien en ze wel handig lijkt. En anders hebben ze simpelweg geen behoefte aan iets nieuws omdat wat ze hebben al goed functioneert. Hooguit willen ze dan dat het stabieler of sneller wordt.
De ict-geletterden, waar de jonge generatie nogal eens mee wordt aangeduid, heeft geen snars meer verstand van ict als de oude generatie. Ze zijn alleen handiger in het snel uitproberen van iets en het direct weer weggooien als het niet bevalt. Dus als een gebruiker na zo’n proces tot de conclusie komt dat applicatie zus-en-zo precies is wat hij wil dan is dat misschien wel gewoon echt de beste keus.
De meeste baanbrekende innovaties in bedrijven zijn tegenwoordig vooráfgegaan door een eerdere introductie van diezelfde functionaliteit in de consumentenwereld. Kijk naar MSN, Skype, Google enz. Elke systeemontwikkelaar weet tegenwoordig dat in een informatiesysteem de zoekfunctie minstens de kwaliteit van Google moet hebben. Bij de keuze die de consumenten al hadden gemaakt is doorgaans geen enkele ict-consultant komen kijken.
@Rob: De zoekfunctionaliteit van Google is trouwens helemaal niet goed.
Het doorzoeken na een extra woord toe te voegen aan je originele zoekopdracht resulteert in meer hits. Google is destijds doorgebroken door geen advertenties op hun startpagina te hebben.
Gebruikers zullen niet begrijpen dat de situatie van 2 WHERE’s in een query in meer resultaten eindigt dan een enkele WHERE.
On-topic: Het gaat natuurlijk om de vertaalslag van gebruiker en behoefte, werkomgeving en behoefte naar de passende technische oplossing.
Dit is echt een hele goede column – een verademing – en het beschrijft ook precies hoe ik al jaren werk.
Een mooi provocerend artikel waar wel enkele kanttekeningen bij zijn te plaatsen.
Als alleen al in de titel wordt gesteld dat er niet naar ‘de gebruiker’ moet worden geluisterd, dan is het onduidelijk welke gebruiker precies wordt bedoeld. Moderne selfservice-systemen hebben op z’n minst 2 typen gebruikers, namelijk de bedrijfsgebruikers (business-users) die een rol spelen in de afwikkeling van bedrijfsprocessen (voor zover deze niet volledig geautomatiseerd kunnen worden uitgevoerd) en de eindgebruikers (end-users), die ook wel klanten worden genoemd. Ten aanzien van deze tweede categorie gebruikers verdient de aanbeveling van het artikel alvast geen opvolging, aangezien die het bestaansrecht van de organisatie vormt.
Resteert de vraag hoe ICT zich dient te verhouden tot de business(-users).
Mijns inziens dient ICT de business niet meer te ondersteunen met volledige oplossingen, maar te faciliteren in het zelf ontwikkelen van de gewenste oplossingen. ICT wordt daarmee leverancier van software componenten (diensten, services), waarmee de business haar eigen oplossingen – desgewenst in samenwerking met de klant – gaat beschrijven. Overigens kunnen deze diensten in een aantal gevallen even goed uit de Cloud worden afgenomen. Uiteraard heb ik het hier over de Service Oriented Architecture (SOA) die, in combinatie met Cloud-computing, de business (letterlijk!) ongekende nieuwe mogelijkheden biedt.
Innovatie begint niet met een droom, maar met een architectuur die de toekomst mogelijk maakt.
Afgelopen week verscheen dit artikel in de papieren versie van Computable (nr. 19). Een prima analyse en niet alleen van toepassing op software-ontwikkeling. Ook bijvoorbeeld bij, heel concreet, het maken van rapportages spelen beide problemen. Ook dan speelt het risico van 1) een gebruiker die niet weet wat hij wil en 2) een consultant die de vertaling naar een oplossing niet weet te maken. En, alsof dat niet genoeg onduidelijkheid geeft, veelal zijn er ook nog andere complicerende factoren binnen en buiten de organisatie: onduidelijke bedrijfsvisie, externe krachten op cruciale posities, veranderende concurrentie en niet-homogene groep mondige klanten om er een paar te noemen. Onduidelijkheid troef en een groot probleem zou je zeggen.
Maar is dat werkelijk zo? Is er daadwerkelijk een probleem? Is het niet zo dat de oplossing binnen handbereik is? En mooier nog, op vele plaatsen daadwerkelijk gebruikt wordt?
Een iteratieve methode, bijvoorbeeld scrum, doet niet anders dan stapje voor stapje in een kortcyclische proces exact dat maken wat de klant wil. Bovendien wordt die nieuwe functionaliteit steeds na goedkeuring door de klant direct in productie genomen er hij kan er meteen in de praktijk mee aan de slag.
Mooi toch? Het gesignaleerde probleem is al opgelost.
Afgelopen week verscheen dit artikel in de papieren versie van Computable (nr. 19). Een prima analyse en niet alleen van toepassing op software-ontwikkeling. Ook bijvoorbeeld bij, heel concreet, het maken van rapportages spelen beide problemen. Ook dan speelt het risico van 1) een gebruiker die niet weet wat hij wil en 2) een consultant die de vertaling naar een oplossing niet weet te maken. En, alsof dat niet genoeg onduidelijkheid geeft, veelal zijn er ook nog andere complicerende factoren binnen en buiten de organisatie: onduidelijke bedrijfsvisie, externe krachten op cruciale posities, veranderende concurrentie en niet-homogene groep mondige klanten om er een paar te noemen. Onduidelijkheid troef en een groot probleem zou je zeggen.
Maar is dat werkelijk zo? Is er daadwerkelijk een probleem? Is het niet zo dat de oplossing binnen handbereik is? En mooier nog, op vele plaatsen daadwerkelijk gebruikt wordt?
Een iteratieve methode, bijvoorbeeld scrum, doet niet anders dan stapje voor stapje in een kortcyclische proces exact dat maken wat de klant wil. Bovendien wordt die nieuwe functionaliteit steeds na goedkeuring door de klant direct in productie genomen er hij kan er meteen in de praktijk mee aan de slag.
Mooi toch? Het gesignaleerde probleem is al opgelost.