"Een prototype zegt meer dan duizend woorden" was een andere kandidaat-titel, maar een mens moet nu eenmaal kiezen.
En zowaar, het begrip analytical prototyping bestaat zowaar, zo leert google mij.
Of het overeenkomt met wat ik bedoel, durf ik niet zeggen - al was het maar omdat het idee voor mij nog niet geheel en al is ontwikkeld - en heb nu ook niet de tijd om door te googlen.
Maar wat ik er ongeveer mee bedoel is eigenlijk redelijk simpel:
Zo vaak wordt door analysten/ontwikkelaars/... geklaagd dat gebruikers pas weten wat ze willen eens de applicatie af is.
Die observatie is terecht, zou ik durven zeggen. Maar de conclusie niet. Want ieder nadeel heb z'n voordeel. Als je het wil zien, tenminste.
In mijn ervaring is het vooral zo dat van in het begin redelijk duidelijk is wat de belangrijke concepten zijn die moeten beheerd worden, maar komen daar achteraf pas alle 'attribuutjes' bij (niet zo'n groot probleem), en vooral, pas na eerste gebruik wordt duidelijk hoe die gebruikers hun applicatie écht willen gebruiken (een veel groter probleem).
Hmm... hoe zouden we dat knapperig kunnen uitdrukken:
There's no better way to discover the use cases of a system than by actually using it.
Dus, wanneer je zelfs maar het gevoel hebt dat gebruikers nog niet echt weten wat ze willen (hmm...), zorg dan weliswaar dat je de kernconcepten als een coherent geheel in een model kunt gieten, maar maak er voor de rest nog niet teveel UML aan vuil, en bouw eerst een 'prototype' (or whatever the name). Een throw-away prototype, weliswaar - zoals alle prototypes zouden moeten zijn.
Weggegooide inspanning? Mja, misschien. Maar het is de ROI die telt, in principe.
Enerzijds, zorg dat het prototype zo simpel mogelijk gebouwd wordt. Gooi op dat moment zoveel mogelijk non-functional requirements overboord (security, availability, scalability,...), en focus je op een selectie van functional requirements. Anders gezegd: zorg dat de kost, de investment, minimaal is. En bedenk: als je dat prototype niet zou bouwen, zou je een pak meer analyse nodig hebben voor je aan je applicatie kunt bouwen.
Anderzijds, is het hele idee natuurlijk dat je op deze manier een betere applicatie kunt maken. Eén waarmee je gebruikers beter hun werk kunnen doen. Elke dag. Vlot, eenvoudig, krachtig. Daar ligt een hoop return op de loer achter het hoekje.
Kortom: zie een prototype als een uitvoerbare analysis deliverable. Een belichaming van het idee dat in analyse alle middelen goed zijn om de doelstellingen te bereiken: zo goed mogelijk begrijpen wat gebruikers willen, en die informatie zo duidelijk mogelijk doorgeven aan ontwikkelaars.
Eén caveat nog: zet in grote rode letters in de UI van je prototype dat het een PROTOTYPE is, en hou de code base hiervan duidelijk gescheiden van die van de finale applicatie. Zoniet creëer je verkeerde verwachtingen.
Ohja. Kan goed zijn dat een heleboel andere mensen allang deze waarheden ontdekt hebben... maar in dat geval, zoveel te beter. Als meerdere mensen onafhankelijk van elkaar tot dezelfde ideeën komen, is dat meestal een teken dat er wel wat in zit.