Het concept 'prototype' aan een klant uitleggen

Ik maak schermen met Balsamiq Mockups, ipv werkende schermen. Dan begrijpen ze het vaak wel. Een onvolledige applicatie demonstreren wekt verwachtingen, zoals je zelf al hebt ondervonden, dus daar ben ik snel vanaf gestapt.

Ten eerste kun je in de planning aangeven wanneer je het prototype oplevert en wanneer het eindproduct wordt opgeleverd. Aan de periode die daar nog tussen zit zou de klant toch moeten inzien dat het eindproduct nog lang niet af is. Bij 'gehaaste' klanten is het werken met een goede planning heilig.

Als de klant toegang heeft tot het prototype zullen ze er vaak naar kijken (en aan anderen laten zien) en eerder ongeduldig worden. Geef ze dus geen directe toegang vanaf het web tot het prototype.

Blijkbaar schept zo'n prototype applicatie teveel verwachtingen. Misschien kun je screenshots van alle schermen maken en die verwerken in het functioneel/technisch ontwerp. Dan lijkt een werkende applicatie tenminste nog wat verder weg.

Als een klant écht niet snapt dat een prototype wat anders is dan een werkende applicatie, dan is het gewoon beter om geen prototype te laten zien.

Het probleem is dat je klanten al iets werkends laat zien, je kan wat invoeren in de velden, het wordt verwerkt => Dus het is goed (voor de klant)
Die heeft geen kijk op het verdere verloop en alle controles die in het systeem gedaan moeten worden voordat de data ook daadwerkelijk opgeslagen kan en mag worden. Als een applicatie dan al (bijna) lijkt te werken schept dat het beeld van een "applicatie die bijna klaar is".

Waar je ze op kan wijzen (dat doe ik zelf ook regelmatig) is dat het in principe wel te gebruiken is, maar als de controles er niet in zitten komen er vroeg of laat fouten in de data die er niet in moeten kunnen. Ik heb wel eens aangegeven dat ze het best mogen gebruiken, maar dat het niet is getest en dat de uren voor het herstellen van de data dan wel voor hun eigen rekening zijn. (dit hoef je overigens niet aan te geven)
Dan snappen ze het vaak wel, tijd die besteed wordt aan het zoeken naar inconsistente data ten gevolge van een systeem zonder controles, kan niet aan ontwikkeling worden besteed.

Je hebt een ander probleem: je moet een planning aan de hand van de requirements opstellen. Prototype is leuk en aardig, maar dan kan de klant alsnog zeggen "doe $feature er ook maar in". Je gaat dus eerst inventariseren wat het produkt moet kunnen, daarna maak je een planning. In die planning moet je een aantal "testmomenten" opnemen, waarbij je vantevoren al tegen de klant zegt "dan krijg je dit en dit".

Als je geen requirements hebt voor je software, kan er altijd worden gezegd "doe er maar bji". Met requirements/featurelist kan je zeggen "dit stond niet in de eisen, is meerwerk, dokken of doei". Zolang je dat niet eerst doet, is het onmogelijk om een klant terug te fluiten.

MueR schreef op dinsdag 18 mei 2010 @ 17:15:
Je hebt een ander probleem: je moet een planning aan de hand van de requirements opstellen. Prototype is leuk en aardig, maar dan kan de klant alsnog zeggen "doe $feature er ook maar in". Je gaat dus eerst inventariseren wat het produkt moet kunnen, daarna maak je een planning. In die planning moet je een aantal "testmomenten" opnemen, waarbij je vantevoren al tegen de klant zegt "dan krijg je dit en dit".

Als je geen requirements hebt voor je software, kan er altijd worden gezegd "doe er maar bji". Met requirements/featurelist kan je zeggen "dit stond niet in de eisen, is meerwerk, dokken of doei". Zolang je dat niet eerst doet, is het onmogelijk om een klant terug te fluiten.

Dat is niet helemaal waar. Een prototype of proof of concept maken is ook handig als je wil laten zien dat iets in de basis kan en ook door de programmerende partij geprogrammeerd kan worden. Dat kan een goed moment zijn om een go / no-go beslissing af te dwingen en dan de rest (adh de redelijk gedetailleerde requirements, waarbij de rest van je verhaal wel opgaat) te bouwen, goed te implementeren.

Er zijn redelijk wat bedrijven / organisaties die zo werken tegenwoordig. Je moet het wel duidelijk afspreken. In dit specifieke geval zou ik, als je met legacy code, of code-wads werkt het zeker zo voorstellen: eerst een proof of concept om te kijken of het uberhaupt nog kan met een bestaande codebase en dan na een go beslissing het ding afbouwen. Communicatie van known issues en openstaande punten en zeggen dat de rest x tijd kost is het allerbelangrijkste.

Maxonic schreef op dinsdag 18 mei 2010 @ 16:20:
Klanten denken dat het prototype het eindproduct is en nagenoeg af is. [...]
Nu kan ik me niet anders voorstellen of meerdere mensen moeten deze vraag hier regelmatig beantwoorden.

Mijn oplossing:

Maak lelijke prototypes.

Schets een prototype of grote vellen papier. Knutsel schermvoorbeelden in Powerpoint. Of nog beter: gebruik Excel en vooral veel schreeuwerige kleuren en dikke cellborders.

Mensen zien gelijk dat het een voorbeeld is, dat het nog lang niet af is, maar je kan er perfect over discussieren en je zet 't in no-time in elkaar.

Het heeft allemaal met verwachtingmanagement te maken. Als jij iets laat zien dat er bijna-af uit ziet, dan denken mensen dat het bijna af is. Als jij iets laat zien dat nog lang niet af is, maar wel uitbeeldt dat je helemaal snapt waar ze naar toe willen, dan scoor je punten.

Ik weet er alles van... ik zit momenteel met zo'n project. We plukken er nu nog steeds de vruchten van, so to say. De hele applicatie is niet juist opgezet, en is ook nog eens verrekte langzaam.

Het beste wat je inderdaad kunt doen, is zorgen dat de applicatie er niet af uitziet. Laat fonts ontbreken, gebruik allerlei placeholders voor plaatjes, laat de applicatie crashen (bijvoorbeeld: de verwijderknop doet het nog niet, maar gooit een exception). Al dat soort dingen versterken het beeld dat het nog niet af is, terwijl de klant wel een impressie kan krijgen.

Hou met opzet je prototype erg abstract; liefst schetsen op papier en anders zijn er tools die UI's als "schets" kunnen presenteren.


Zoiets. Daarmee is 't de klant meteen, en tijdens het hele proces, duidelijk dat het om een prototype gaat.

[ Voor 60% gewijzigd door RobIII op 18-05-2010 22:22 ]

Oh, RobIII, vergeet SketchFlow in Expression Blend niet.

Wij maken sinds kort FO's met behulp van DFD schema's en de 1e de beste klant voor wie ik een FO optie manier schreef (weinig tekst, veel plaatjes ) gaf aan dat ze nu direct begrepen waar het over ging. Voorheen bestond ons FO (meer een half TO eigenlijk) uit belachelijk veel tekst en ieder scherm volledig uitgewerkt. Klanten begrepen het niet, consultants begrepen het niet, en de programmeur dacht pfff dat is veel tekst,..

Ik had dit FO op gezet met DFD schema's waarbij op het laagste niveau in korte steekwoorden stond beschreven wat er moest gebeuren (Lees dit, bereken dat, etc). Als bijlage wat schermvoorbeelden om het visueel te maken hoe het in de bestaande applicatie zou vallen, en niets dan lof, iedereen die het moest lezen heeft het gelezen (omdat er lekker veel plaatjes instonden ) en het was voor iedereen duidelijk, (hebben we nog nooit gehad ).

Een prototype werkt zodra het enigsinds werkend is de indruk dat het bijna af is. Een opmerking als 'de datavalidatie zit er nog niet in' is voor ons begrijpbaar, maar de gemiddelde klant zal niet begrijpen waarom die validatie nog 4 weken werk is... Ik zou dan ook geen prototype maken, maar met schermafdrukken werken. Alleen voor die complexe schermen waarbij je van te voren graag alvast wat user interactie wilt hebben zou ik misschien een prototype maken, of dit benoemen en tegen de tijd dat je in de applicatie aan die schermen toebent, een sessie houden met de klant.

Ik weet niet meer precies welke het was - waarschijnlijk joelonsoftware of coding horror of zo'n soort weblog - die het ook had over dit probleem. De stelling was daar dat je alleen een GUI maakt voor de dingen die echt af zijn - dwz dat zaken die niet werken ook geen GUI hebben.

Nu is dat misschien niet helemaal hierop van toepassing, maar vooruit. Je zou met hele kleine mini-prototypes kunnen gaan werken, die slechts een demo van een kleine requirement geven.

En natuurlijk een goed requirements document met de daarvoor benodigde tijd (qua uren), en op basis daarvan een planning maken.

Wat betreft requirements die de klant erbij bedenkt, dat kun je gewoon meenemen in je ontwikkelingsproces. Las elke zoveel tijd (bijvoorbeeld elke maand) een punt in waarop je aan de klant laat zien wat er af is (en dat dan met die gedeeltelijke GUI, anders krijgen ze de indruk dat het al heel ver is - een a-technische klant beoordeelt functionaliteit op wat ze kunnen zien, niet op wat jij zegt) en ze de mogelijkheid geeft om de requirements aan te passen of aan te vullen.

Als een requirement zodanig aangepast wordt dat het meer tijd kost (maar ook minder), pas je ook de offerte aan. Het is misschien een paar uurtjes / week (als het al zoveel is) extra administratie, maar die kun je ook gewoon in rekening brengen. Uiteindelijk is de klant koning, en je wilt dat die aan het eind van het traject tevreden is - uitspraken als 'dat doen we niet want dat staat niet in de requirements' zijn daar weer niet goed bij.

Je kunt ook een versie 1.0 maken en evt extra features die ze willen hebben doorschuiven naar een 1.1, en die apart in rekening brengen.

Het tonen van een volledig werkende GUI geeft de klant de indruk dat het meeste werk gedaan is.
Lever gewoon screenshots aan voor de presentatie van de GUI met een aantal schermen als werkend prototype.

Vervolgens ga je regelmatig terug naar je klant waarbij het "prototype" telkens meer mogelijkheden heeft, mogelijkheden die ook ontwikkeld zijn op de back-end.

Op die manier kan de klant heel goed de huidige evolutie zien en schep je geen te hoge verwachtingen.

Hebben alle schets maar raak mensen ook bedacht dat juist het meeste werk zit in de intermediate code? Een gui in elkaar zetten voor business apps is t werk niet echt imho. Juist alle code naar je datawarehouse of om je domeinprobleem op te lossen moet je in kaart brengen en communiceren / prototyperen aangezien daaar het meeste tijd, de meeste foutgevoeligheid en het meeste onbegrip in zit.

RedRose schreef op woensdag 19 mei 2010 @ 23:28:
Een gui in elkaar zetten voor business apps is t werk niet echt imho.

Dat is het idee van een prototype; je brengt een (niet werkende) UI aan de vergadertafel (ook wel mockup) waardoor mensen sneller een idee krijgen van wat ze gaan krijgen; daardoor komen eerder bepaalde zaken aan 't licht die anders pas bij/vlak voor oplevering opgemerkt gaan worden. En een prototype moet in een fractie van de totale projectduur natuurlijk wel te realiseren zijn; een prototype is dan ook niet meer dan een lightweight schets van hoe iets gaat worden. Je moet dan ook vooral niet te veel (liefst geen) tijd steken in knopjes en tierlantijntjes die de boel leuker/makkelijker maken om met het product te werken; all it needs to do is (to demonstrate how to) get the job done (in een "mockup way" dus niet al in achterliggende DB's gaan rommelen etc; "hardcoded" waardes in alle windows/pagina's/screenshots zijn dan ook geen probleem). Geen icoontjes, geen mooie uitlijning, geen definitieve knopopschriften, menustructuren etc.

Het is een beetje afhankelijk van je definitie van prototype, maar een UI met wat controls erop die niets doen en hooguit naar een nieuw(e) form/pagina gaan waar (weer) mockup data in staat geeft je al een idee van hoe iets gaat functioneren. Daarbij krijg je zelf al vroeg in het traject een idee of je UI ook gaat aansluiten op je businesslogic zoals je dat graag zou willen.

RedRose schreef op woensdag 19 mei 2010 @ 23:28:
dat juist het meeste werk zit in de intermediate code?

Dat was juist de kern van 't probleem; klanten zien een al 'werkende' UI en denken dat 't haast klaar is. Je brengt, imho, nog het beste over dat je nog in prototype fase zit als je juist met "schetsen" aan komt zetten en niet met af (lijkende) forms/paginas.

RedRose schreef op woensdag 19 mei 2010 @ 23:28:
Juist alle code naar je datawarehouse of om je domeinprobleem op te lossen moet je in kaart brengen en communiceren / prototyperen aangezien daaar het meeste tijd, de meeste foutgevoeligheid en het meeste onbegrip in zit.

Da's leuk maar de gemiddelde klant heeft, behalve op het hoogste 'business niveau' niet vaak echt geen benul (zoals je zelf ook aangeeft met het "onbegrip stukje") wat er allemaal moet gebeuren om X gedaan te krijgen. Ook dat dien je, inderdaad te prototyperen maar dat is op een heel ander (abstracter) niveau.

Het is dan ook dit stuk waar we op reageren:

Maxonic schreef op dinsdag 18 mei 2010 @ 16:20:
zijn we met prototypes gaan werken. We maken een GUI, flatsen er snel wat code achter om de basisfunctionaliteit te kunnen demonstreren en klaar.
...
Klanten denken dat het prototype het eindproduct is en nagenoeg af is. Ze snappen vaak niet waar alle ontwikkelingstijd in gaat zitten. Nu probeer ik de klant dan uit te leggen dat hetgeen ze zien nog lang niet af is. Ik doe dat meestel door de vergelijking te trekken met een prototype van een model van een auto welke in een kleimodel is uitgevoerd. Je ziet misschien niet dat het geen echte auto is, maar ermee rijden zal niet lukken.

[ Voor 45% gewijzigd door RobIII op 20-05-2010 00:07 ]

RobIII schreef op woensdag 19 mei 2010 @ 23:57:
[...]

Da's leuk maar de gemiddelde klant heeft, behalve op het hoogste 'business niveau' niet vaak echt geen benul (zoals je zelf ook aangeeft met het "onbegrip stukje") wat er allemaal moet gebeuren om X gedaan te krijgen. Ook dat dien je, inderdaad te prototyperen maar dat is op een heel ander (abstracter) niveau.

Eens met je hele verhaal. Op de manier waarop jij het nu wat duidelijker uitlegt kan ik daar ook in meegaan; een mockup gui zou misschien twee dagen ontwikkel tijd moeten zijn, zeker voor een presentatie.

Toch blijf ik het ook belangrijk vinden om open te zijn over waar je staat in termen van echt te programmeren functionaliteit, bijvoorbeeld aan de hand van flowcharts of uml diagrammen (die helder zijn) waarbij je zegt: ok, dit is er al, en dit nog niet en om het te laten werken voor jullie moeten we dat echt hebben en jullie zien dat ten opzichte van de hele codebase dat best nog wel wat werk is. En dat lijkt me nou weer typisch een taak voor een goede project manager in plaats van een developer.

AtleX schreef op dinsdag 18 mei 2010 @ 16:33:
Ik maak schermen met Balsamiq Mockups, ipv werkende schermen. Dan begrijpen ze het vaak wel.

Tijden op zoek geweest naar een dergelijk programma! Dit werkt echt super Heb in een half uurtje al een nieuwe applicatie in elkaar 'gemockuped', super. Ga het meteen aanschaffen

Alex) schreef op dinsdag 18 mei 2010 @ 22:31:
Oh, RobIII, vergeet SketchFlow in Expression Blend niet.

Inderdaad, als je WPF-gebaseerde applicaties schrijft voor klanten is dit voor klanten die prototypes niet begrijpen een must, een vriend liet me snel de werking zien op een LAN Party en het zag er echt wel handig uit, zo noem ik de drie dingen die het handigste leken op: Wisselen tussen prototype en echte lay-out is bij wijze van spreken maar een vingerklik, je kan tijdens een presentatie dingen markeren en commentaar typen die je wanneer je weer op kantoor bent kan herbekijken; het prototype functioneel gebruiken werkt ook wat het eens zo knap maakt.

Voor SketchFlow is WPF niet een must. Je kan ook klassieke Windows Forms prototypen in Sketchflow, de basic controls zijn hetzelfde.

Misschien hebben wij (we doen in business software) geen veeleisende klanten, maar als ik bij een klant om de tafel zit om te bespreken wat hij wil en men (hij of ik) wil het gevisualiseerd hebben, dan teken ik zoiets als RobIII demonstreerde op papier.

Vaak is het dan al sprekend genoeg.
Je prototypes moeten niet te mooi zijn en al helemaal geen bewegende dingen kunnen. Ook moet het bij voorkeur vooral niet lijken op iets dat je al hebt, anders wek je de indruk dat je het kunt kopiëren.

TaraWij schreef op vrijdag 28 mei 2010 @ 17:05:
[...]
Wisselen tussen prototype en echte lay-out is bij wijze van spreken maar een vingerklik

Dat is dan weer iets wat ik niet zou doen... mockups en prototypes zijn handig om iets te laten zien, maar om er daadwerkelijk op voort te bouwen? Dan hoop ik dat je prototype al enorm goed is qua architectuur, anders stoot je jezelf later enorm voor het hoofd.

je kan tijdens een presentatie dingen markeren en commentaar typen die je wanneer je weer op kantoor bent kan herbekijken; het prototype functioneel gebruiken werkt ook wat het eens zo knap maakt.

Dat is inderdaad wel weer handig, ja.

Alex) schreef op vrijdag 28 mei 2010 @ 22:24:
[...]
Dat is dan weer iets wat ik niet zou doen... mockups en prototypes zijn handig om iets te laten zien, maar om er daadwerkelijk op voort te bouwen? Dan hoop ik dat je prototype al enorm goed is qua architectuur, anders stoot je jezelf later enorm voor het hoofd.

Uiteindelijk gaat er wel een finaal prototype zijn waar je op voort gaat kunnen bouwen, met dat prototype uit te werken vorm je de architectuur van de GUI. Het is gewoon het punt dat als je het één hebt dat je dan simpelweg het andere kan verkrijgen zonder zelf alles over te gaan nemen. Een goed voorbeeld is denk ik een prototype van Adobe Photoshop, dat manueel overnemen zal wel even duren.

Alex) schreef op vrijdag 28 mei 2010 @ 22:24:
[...]
Dat is dan weer iets wat ik niet zou doen... mockups en prototypes zijn handig om iets te laten zien, maar om er daadwerkelijk op voort te bouwen? Dan hoop ik dat je prototype al enorm goed is qua architectuur, anders stoot je jezelf later enorm voor het hoofd.

Wat heeft een mockup van je UI te maken met architectuur?
En daarnaast zijn de meeste prototypes vaak om te bewijzen dat een bepaalde architectuur gaat voldoen aan de requirements .
Dus zo raar is die workflow in Expression nog niet.

Net iets op Twitter opgevangen wat misschien wel interessant kan zijn in de context van SketchFlow in dit topic:

RT @SilverlightNews Announcing Sketchables – Rapid Mockup Creation with SketchFlow - http://bit.ly/9eJQMi

Alex) schreef op dinsdag 18 mei 2010 @ 22:31:
Oh, RobIII, vergeet SketchFlow in Expression Blend niet.

Inderdaad, SketchFlow is een krachtig product om prototypes te ontwerpen (voorbeeld). Door geschetste letters en andere vormen krijgt de klant het idee dat het geen nog lang niet af is.

Overigens is wat in SketchFlow ontwikkeld wordt als prototype breed inzetbaar. Zo kan het als een Silverlight applicatie worden geëxporteerd en vervolgens kan de klant "notities" aanmaken. Ofwel: je zet het prototype online voor de klant en hij kan zelf commentaar toevoegen gaandeweg.

En als laatst, toon eens een blik op: Rapid Application Development. Dat is een soort van 'prototyping'. Op elk prototype zal worden verder ontwikkeld. En gaandeweg ziet de klant het project groeien en kan hierop commentaar leveren.

EDIT: Het is ook mogelijk om schermen aan elkaar te koppelen, zodat de klant kan zien wanneer op knop x of knop y zal worden gedrukt.

[ Voor 8% gewijzigd door Velth op 14-06-2010 23:24 ]

Ik kwam zojuist wel een aardig artikeltje tegen dat hier wel past.