Gebruikers buitensluiten kost veel geld!
Gebruikers buitensluiten kost veel geld: 119 miljard per jaar!
Nooit eerder heb ik zo duidelijk een berekening gezien die aangeeft wat slecht functionerende software nu daadwerkelijk kost. Het niet luisteren naar de eindgebruiker levert daadwerkelijk onwerkbaren software op. De gedachte dat gebruikers dan meer training nodig hebben om met de software te kunnen werken, klinkt als het paard achter de spreekwoordelijke wagen spannen. Software hoeft maar een keer gebouwd te worden, het is dan ook veel goedkoper om goede, werkbare softare te ontwikkelen dan om continu (nieuwe) gebruikers op te leiden.
Organisatiefocus
Het genoemde artikel geeft allerlei oplossingen gericht om de symptomen aan te pakken. Men noemt opleidingen en trainingen, een buddy-systeem en een andere focus van de helpdesk. Terwijl het bedrijf wellicht beter zou kunnen investeren in een aantal goede requirement analisten, welke echt problemen en klantwensen helder kunnen beschrijven. Pak het probleem aan bij de oorzaak. De macht ligt bij de klant/gebruiker, maar deze beseft zich dit helemaal niet!
Projectfocus
Zoals in eerdere blogs al is besproken is het belangrijkste van een goed project opleveren, het opleveren van software waar de gebruiker om vraagt, wat aansluit bij zijn of haar wensen en software wat daadwerkelijk een probleem oplost en het leven makkelijker maakt. Het onderzoek gedaan door Ctrl Alt Delete toont aan dat de focus van software-ontwikkelaars nog te veel ligt bij de techniek en minder bij de klant. Er ligt nog een schone taak voor projectleiding en testteam om hun poging om de klantwens te borgen te verbeteren.
Power to the people!
Een nieuwe versie van software hoort idealiter zijn oorsprong te hebben bij de gebruiker. In de huidige versie zitten een aantal ongemakken die opgelost dienen te worden, zodat de gebruiker efficienter zijn of haar werk kan doen. Daarnaast kan het uiteraard ook voorkomen dat er nieuwere technieken in een versie moeten worden gestopt om bijvoorbeeld de beveiliging op niveau te houden, maar als er dan ook functionele wijzigingen aan het pakket ontstaan, dan moet dit uiteraard worden afgestemd met de gebruikersgroep. Dit gebeurd te weinig en de gebruiker krijgt het pakket in zijn of haar maag gesplitst. De acceptatiegraad van nieuwe software is vele malen hoger als de gebruikers er daadwerkelijk bij betrokken worden. Gebruikers worden te vaak verrast tijdens een gebruikersacceptatietest. Je hoort te vaak
‘ow, is dit het nu?’ Het vreemde is dat je juist zou verwachten dat een klant vooraf al weet wat ie krijgt.
Niet software-relateerd voorbeeldje
Als ik als klant bijvoorbeeld in een winkel kom, dan kom ik daar met een reden. Als mijn wasmachine aan vervanging toe is, dan ga ik naar een winkel en leg mijn klantwensen op tafel. Een wasmachine moet 7 kilo was kunnen bevatten, energiezuinig (A+ label) zijn, een witte kleur hebben en het moet een A-merk zijn. Hele concrete klantwensen die de verkoper dan voor mij gaan ‘vervullen’. Het lijkt duidelijk dat ik dan niet met een Zwarte, C-klasse wasmachine van onbekend merk X naar huis ga. Waarom gebeurd dit in de software-ontwikkelbranche dan wel en wordt dit geaccepteerd?
Verandering begint bij besef
Zoals eerder gezegd, gebruikers hebben niet in de gaten hoeveel macht ze hebben. De gebruikersgroep heeft meer sturingsmogelijkheden dan ze zelf doorhebben. Echter is het de projectleider die ook het besef moet hebben om met de eindgebruikers aan een tafel te gaan zitten om het projectidee te bespreken. Ook kan dit vanuit het testteam worden geinitieeerd, om bijvoorbeeld input voor de gebruikersacceptatietest boven water te krijgen. Daarnaast kan een functioneel ontwerper de output uit zo’n overleg direct gebruiken bij het opstellen van de functionele documentatie. Bekend is dat de gebruikersgroep dit niet uit zichzelf zal beginnen, omdat ze niet weten dat het tot de mogelijkheden behoort. Er zijn minder projectleden dan gebruikers, het is dan ook aan de projectleden om de gebruikers te mobiliseren om mee te doen!
Gebruikers bij je project betrekking vergroot de efficientie
Als je eerst 90% van al je projectactiviteiten uitvoert, alvorens de gebruikers te betrekken, kan het zomaar zo zijn dat je een gedeelte van die 90% opnieuw kan uitvoeren omdat het niet past in de gebruikersorganisatie. Dat is zonde. Waarom zou je eerst zelf het wiel uitvinden en dat daarna aan de gebruikers vol trots tonen, om er vervolgens achter te komen dat de gebruiker het wiel al lang heeft uitgevonden en je alleen de bouwtekening hoefde over te schrijven om dat wiel daadwerkelijk te maken. Hoe vaak komt het niet voor dat documentatie sterk veranderlijk is, omdat er telkens met de verkeerde mensen wordt gesproken en het wiel steeds meer vorm krijgt omdat je dichter bij de uitvinder komt (eindgebruiker).
De juiste mensen aan het woord
Hoe je de juiste mensen vind, ligt een beetje aan de organisatie, de hoeveelheid beschikbare tijd en wat je doelstelling is. Je zou kunnen controleren wie het vaakst inlogt op een systeem of een bepaalde functionaliteit vaak gebruikt. Ook kun je op zoek gaan naar een aantal senior users, maar de valkuil daarmee is dat deze vaak te veel oplossingsgericht denken. Het is juist zaak om het probleem aan de kaak te stellen. Ook kunnen medewerkers die net gestart zijn hele verfrissende ideeen hebben.
Conclusie
Als conclusie kunnen we stellen dat het onderzoek een mooi inzicht geeft in de kosten die software met zich meebrengt die niet volgens de klantspecificaties is gebouwd. Dit meegenomen lijkt het dat menig businesscase nog eens moet worden herevalueert. De aanbevelingen die worden gedaan in het artikel zijn echter alleen maar middelen om om te leren gaan met de gebrekkig software en dragen niet bij aan het voorkomen of oplossen van de problematiek.
Het artikel waar naar verwezen wordt staat hier: Nu.nl