Ik denk dat je bedoelde “NIET écht kennen” ipv “écht kennen”.

Ik volg wel dat er meerdere manieren zijn om tot een doel te komen. Het hangt ook allemaal af van de aard van het project, de belangrijkheid, het protocol in het bedrijf of organisatie, het aantal gebruikers, de beschikbaarheid van de team (en andere) leden en last but not least: het budget.

Ik volg ook niet altijd de ‘ideale’ weg: research -> conceptueel model maken -> testen -> basis prototype ontwerpen -> testen -> finale prototype ontwerpen -> testen -> source code laten schrijven.

Deze weg is niet goedkoop, kost wat tijd en is niet voor elk type project nodig of mogelijk.

Persoonlijk hou ik er wel niet van om te starten en wel te zien waar ik uitkom. In mijn nederige opinie is er altijd een kritische massa aan research nodig. Maar goed, ik ben niet echt een grote fan van XP achtige toestanden (wat niet wil zeggen dat er niets goed in dat concept zit).

Ene Gilb heeft eens gezegd dat als een usability wijziging in de ontwerpfase $1 kost, deze $10 kost in de ontwikkelfase en zelfs $100 moet kosten na aflevering van het systeem. Ik heb al ondervonden dat het niet overdreven is.

Voer je die kritische massa aan research niet uit, dan loop je het risico dat de programmeurs onnodige of verkeerde source code gaan schrijven. Het is duurder om functionaliteit te programmeren dan deze even uit te tekenen in een concept of een prototype.

Er is ook een psychologische factor: het dumpen van een prototype (of een gedeelte ervan) wordt veel gemakkelijker aanvaard door het team. Source code dumpen, waar ze weken en zelfs maanden aan gewerkt hebben, is niet alleen een kostelijke affaire het zal veelal tot wrevel en fricties leiden binnen het team.

Het komt ook de leesbaarheid van de code ten goede. Als je constant wijzigt en schrapt, door wijzigende functionaliteit en requirements, dan zit je code dikwijls vol hacks en workarounds, wat dan weer repercussies heeft voor het onderhoud later.

Een ander gevaar is, dat ze het gewoon zo laten. Ook al weten ze dat het niet in orde is. Ze vinden het gewoon zonde om de investering te vernietigen en nieuwe code schrijven kost ook geld.

Wat het Fusion Usability Recept betreft: zeker komen kijken en kritiek geven!

Je hebt gelijk dat veel organisaties hun doelgroep écht kennen en begrijpen en dat dit een risico is voor een agile aanpak. Ik denk wel dat er meerdere manieren zijn om hiermee om te gaan en dat de keuze tussen agile, waterval en een mengvorm van meer factoren afhankelijk zijn.

Je kunt inderdaad meer user research vooraf doen, zoals je voorstelt. Je zou ook de doelgroep meer in het proces kunnen betrekken. In het opvolgartikel vermeld ik tips van Jeff Patton om op regelmatige tijdstippen een pool van gebruikers te betrekken bij user research en usability testing.

In ieder geval ga ik je Fusion usability recept eens goed bestuderen.

Eerst en vooral: soms kom je al eens een blog of website tegen over usability die de moeite is. Deze is er zo ééntje. Hij krijgt dan ook een plaatsje op mijn site.

Ik heb wel wat ervaring met Agile achtige modellen. In organisaties die héél zuiver zo werken, kan je niet op een ernstige manier aan usability doen. Tenzij het om zeer kleine projecten ging, was de usability niet op maat van de gebruiker, zijn taak en zijn omgeving.

Het probleem ligt voor een stuk bij één van de Strengths van je SWOT analyse van een Agile benadering:

“Klanten die de wensen en behoeften van hun gebruikers kennen en begrijpen.”

Dat is in de praktijk een zeldzaam gegeven. Weinigen geven gewoon toe dat ze hun gebruikers niet kennen en begrijpen, de meeste zeggen dat ze dat wél doen, maar in mijn praktijk blijkt dat ze het zelden echt weten. Vooroordelen en misvattingen zijn eerder legio.

Als je niet weet WIE de gebruiker is, WAT, HOE en WAAR hij zijn taken uitvoert dan kan je geen software (website of applicatie) afleveren op maat van die gebruiker.
Dan is die software op maat van de programmeur, zijn omgeving en zijn interpretatie van de taken van de gebruiker. Wat je dan ook kan merken in pakweg 80% van de software in omloop.

Slimme organisaties en bedrijven zien dat wel in en gaan Agile mengen met waterval.

Zo’n mengvorm verenigt het beste van die 2 werelden. Ik ben zelf bezig met zo’n methodologie: http://usability-vlaanderen.blogspot.com/2009/04/het-fusion-usability-recept_10.html

In het kort:
Ik verzamel eerste een kritische massa aan gegevens over de gebruiker, zijn taak en omgeving, destilleer hieruit de usability doelen en hierna ga ik op een Agile achtige wijze te werk bij het ontwerpen van de feitelijke user interface.

Belangrijk is dat de software architecten pas beginnen wanneer het conceptueel model is afgerond, de programmeurs starten pas na aflevering van een getest prototype. Wat uiteraard niet wil zeggen dat de usability mensen eerst ALLES moeten afronden nog voor de anderen aan de slag mogen.

Daarna kunnen de software architecten en programmeurs zoveel ‘Agilen’ als ze zelf willen.

Leuk dat je dit zo gaat oppakken! Ben nu al benieuwd naar de uitkomst…

Ik zal in de tussentijd zorgen voor nog wat desk research materiaal.

Je hebt me geïnspireerd: ik ga hier een afstudeerstage van maken bij Approach.

Ik weet dat veel webbureaus in NL met de vraag worstelen hoe de voordelen van Agile kunnen worden gecombineerd met de wensen van user centered designers en opdrachtgevers.

Mijn collega’s dragen agile een warm hart toe, vanuit disciplines als software en enterprise architectuur, BPM, en QA testing. Ik ben sceptisch over de meerwaarde van “strict agile”, maar heb nog geen eigen ervaring met Agile methoden. Tijd voor onderzoek met een afstudeerder, die het discussievuurtje hier intern ongetwijfeld lekker zal opstoken

Ik zie voor me dat een afstudeerder op dit onderwerp:
- de do’s and don’ts op een rij zet op basis van desk research
- een rondje maakt langs een aantal NL webbureaus om de praktijkervaringen met waterval en agile te wegen (interviewssessies, round table gesprekken)
- waarbij de designer, ontwikkelaar, projectmanager en opdrachtgever aan het woord komen
- de resultaten uitwerkt en komt tot een praktisch model waarmee webbureaus voordelen kunnen benutten en risico’s kunnen beperken, voor 4 genoemde doelgroepen.

Uiteraard worden de uitkomsten van de afstudeerder beschikbaar gesteld, zoals goed gebruik op jouw blog (tnx!).

Groet, Nils

Interessante post.
Heb al in meerdere projecten gezeten waar met ‘agile uitgangspunten’ werd gestart. Je SWOT klopt wat mij betreft erg goed.
Mijn ervaring is dat tijdens het project de agility nogal eens afneemt. Onder druk is het verleidelijk om af te bakenen in vertrouwde watervalstappen. Agility vergt vooralsnog veel inspirerend vermogen en leiderschap.

Ben benieuwd naar andere ervaringen.

Groet, Bas Brand