Een project voor snelle prototypering uitvoeren

Maar eerst: wat is snel prototypen?

Snel prototypen verwijst naar het proces dat wordt toegepast bij het bouwen van een proof-of-concept of snelle prototypes. Een prototype is geschikt om de geldigheid van een concept te testen. Hiermee kun je sneller meer functies ontwikkelen, maar dat gaat meestal ten koste van de kwaliteit en om die reden zal het product grotendeels wegwerpbaar zijn.

Prototypes zijn er in verschillende vormen en maten

Hoewel er verschillende manieren zijn om de levensvatbaarheid van een product te onderzoeken, zijn dit drie duidelijk verschillende benaderingen:

• Proof-of-concept – Een proof-of-concept is een zeer lichte, wegwerpbare demonstratie van het product, bedoeld om het idee achter het product te testen voordat het wordt gebouwd.
• Snel prototype – Een snel prototype is een lichte eerste versie van het product die met echte gebruikers kan worden getest om meer vertrouwen in het product te krijgen voordat de volledige versie wordt gebouwd.
• Minimaal levensvatbaar product (MVP) – Een MVP is de eerste versie van het product met productiekwaliteit, waarin volledig werkende functies voor gebruikers worden opgebouwd.

Je vertrouwen in het product moet de belangrijkste factor zijn bij het bepalen van de aanpak.

Hoe riskanter het idee = hoe sneller je te werk moet gaan.

Sommige mensen zullen zeggen dat je, als een idee riskant is, er meer tijd aan moet besteden om erover na te denken voordat je het bouwt. In zekere zin hebben ze gelijk. Je kunt een behoefte bijna volledig valideren zonder iets te bouwen. Er zijn talloze voorbeelden van validatietests die het waard zijn om te onderzoeken.

Maar zodra je weet dat er een behoefte bestaat, is de enige manier om die behoefte te bewijzen iets te bouwen, het zo snel mogelijk in de meest basale vorm uit te brengen, feedback te verzamelen en te itereren. We hebben vaak genoeg meegemaakt dat een klant tijdens het onderzoeken van een idee onvermijdelijk zegt: “Dat zou ik kopen”, maar dat de verkoopcijfers vervolgens niet stijgen wanneer het product wordt uitgebracht.

“Dat zou ik absoluut kopen” – 100 mensen

Mensen die het daadwerkelijk zullen kopen = 10

Jeff Sheldon (@ugmonk) 1 september 2016

Snel prototypen beperkt risico telkens opnieuw door de feedbacklus te verkorten en ervoor te zorgen dat je een product bouwt dat zal verkopen.

Hoe weet je welke aanpak geschikt is voor jou?

Om dingen snel te kunnen bouwen, moet je openstaan voor het ontwikkelen van nieuwe processen en manieren van werken.

Richtlijnen voor het beheren van projecten voor snel prototypen

Werken op de hieronder beschreven manieren vereist een nieuwe mindset. Ik raad aan je project te beginnen met een interne kick-off om deze principes door te nemen en uit te leggen waarom ze belangrijk zijn. Dit helpt ervoor te zorgen dat het hele team vanaf het begin op één lijn zit, weet wat er van hen wordt verwacht en zich bewust is van waar en waarom het project kan afwijken van wat ze gewend zijn.

1. Wees bereid om minder te doen

Dit betekent waarschijnlijk minder planning vooraf dan je gewend bent en houdt in dat je je comfortabel voelt bij:

• Geen of minimale acceptatiecriteria
• Geen subtaken bij user stories
• Geen schattingen

Wat je bij een rigide proces aan flexibiliteit verliest, win je terug in snelheid, vertrouwen en communicatie. Omarm het gebrek aan controle.

Dit principe herinnert het hele team eraan dat het oké is om bekende processen los te laten ten koste van het sneller opleveren van werkende software. Het is goed om jezelf en het team regelmatig te vragen: “is dit de snelste manier om x te doen?”.

2. Laat het zien, vertel het niet

Omdat je vooraf minder plant, zul je tijdens de ontwikkeling meer praten en tekenen. Misschien wil je je stand-ups uitbreiden, zodat je wat meer details over de functionaliteit kunt bespreken voordat je team die die dag gaat bouwen. Zoals het gezegde luidt: een beeld zegt meer dan duizend woorden. Soms is een schets van de pagina, een inhoudsmodel of een diagram dat laat zien hoe het systeem wordt gebouwd voldoende om te beginnen met bouwen, waarna je daarop kunt voortbouwen.

Dit principe wekt vertrouwen bij jou en de klant. Iedereen ziet graag vooruitgang en door regelmatig werk te laten zien, ontstaat de mogelijkheid om tijdig feedback te geven, waardoor verspilling tot een minimum wordt beperkt.

3. Vraag om vergiffenis, niet om toestemming

Bij de meeste grondige softwareontwikkelingsprocessen is consensus essentieel. Je wilt dat de product owner de acceptatiecriteria goedkeurt en als PM wil je weten dat je team de vereisten heeft begrepen voordat er een regel code wordt geschreven.

Bij snelle prototypes is het belangrijk dat je team zich gemachtigd voelt om het gewoon zo goed mogelijk te bouwen op basis van het huidige begrip ervan, vervolgens het werk zo snel mogelijk te laten zien, feedback te verzamelen en te itereren.

Consensus vanaf het begin zal de zaken vertragen en werk gaat zelden verloren als het team vroeg en vaak laat zien waaraan het werkt.

Dit principe is vooral nuttig voor ontwikkelaars: het legt de verantwoordelijkheid bij hen om in eerste instantie een functionaliteit te ontwerpen en te bouwen met weinig invloed van buitenaf. Vaak bouwen we te veel en maken we dingen te ingewikkeld, omdat we de technische complexiteit van onze verzoeken niet altijd zien. Daarom is het een goede aanpak om erop te vertrouwen dat de ontwikkelaars in het team bepalen wat de meest basale implementatie is en die eerst bouwen.

Om dit te laten werken, is het essentieel dat je ontwikkelaars een diepgaand begrip van het project hebben, zodat ze de juiste beslissingen voor het project kunnen nemen en altijd slechts voldoende  bouwen.

4. Moedig het team altijd aan om te laten zien waaraan het werkt (zelfs als het er niet mooi uitziet)

Dit proces is geïnspireerd op de prototypingprincipes van de Government Digital Services.

Doorgaans laten we klanten pas functionaliteiten zien wanneer ze af zijn. Bij projecten met snelle prototyping is het belangrijk om ze te laten zien zodra ze werken, zodat je verspilling kunt beperken, kunt itereren en indien nodig van koers kunt veranderen.

Laat het werken. Laat het zien.
Maak het mooi. Laat het zien.
Maak het schaalbaar. Laat het zien.

Dit principe bevrijdt teamleden van het gevoel dat ze werk pas mogen laten zien nadat het door een ontwerper is beoordeeld of volledig is getest. Vier werk in uitvoering.

5. Kies voor fysieke processen in plaats van onlineprocessen

Zoals Brett Harned het zegt: we beheren projecten met ons verstand, niet met onze tools. Wees niet bang om je tools voor projectmanagement los te laten. Visualiseer het werk, gebruik een fysieke backlog, hang schetsen, gebruikersstromen en persona’s aan de muur en houd daar je stand-up omheen. Verwijs er vaak naar en moedig mensen aan om verantwoordelijkheid te nemen voor het verplaatsen van kaarten en het vieren van het uitrollen van nieuwe functionaliteiten. Als je klant niet op dezelfde locatie werkt, fotografeer dan alles en deel alles via Slack, zodat diegene niet wordt buitengesloten.

Een nieuw proces uitproberen kan lastig zijn. Het visualiseren van het werk zal waarschijnlijk gesprekken op gang brengen die niet zouden ontstaan als je via Hangouts naar een digitaal bord keek. Het wordt snel duidelijk als een fysieke kaart een dag lang niet is verplaatst of als er te veel werk in uitvoering is. Het gebruik van fysieke processen zorgt voor een extra laag transparantie waarvoor je me, wanneer alles vaag aanvoelt, eeuwig dankbaar zult zijn.

6. Behandel elkaar uitstekend

Het is natuurlijk om je overweldigd te voelen wanneer je een nieuw proces en een nieuwe manier van werken probeert te verankeren, vooral wanneer dit ook voor jou nieuw is. Geef echter zelfverzekerd leiding en moedig het team aan wanneer het moeite heeft. Luister aandachtig naar hun zorgen en wees bereid het proces gaandeweg bij te stellen. Zorg ervoor dat het proces geen extra druk op je team legt: snelle prototyping draait om slimmer werken, niet om harder werken.

Afhankelijk van de persoonlijkheden in je team zullen sommige teamleden deze nieuwe manier van werken omarmen, terwijl anderen zich er misschien tegen verzetten. We leren allemaal in een verschillend tempo en elke discipline zal met andere uitdagingen te maken krijgen bij de overstap naar een nieuwe manier van werken. Houd hier als PM rekening mee en zorg voor een ondersteunende en veilige omgeving voor het team – zit samen, drink thee en check regelmatig bij iedereen in om te zien hoe het gaat.

7. Beperk afleidingen

Als PM is het soms lastig om te weten waar je bij een nieuw proces compromissen kunt sluiten en waar je voet bij stuk moet houden. Als het gaat om het accepteren van nieuwe wijzigingen halverwege een sprint, blijf dan weerstand bieden en nee zeggen. Het is belangrijk dat je team bij de start van een sprint niet wordt gestoord; hun tijd beschermen is het waardevolste wat je kunt doen.

Dit principe geeft het team de mogelijkheid om verzoeken af te wijzen. Waarschijnlijk werk je met sprints van één week. Met zo’n kort tijdsvenster kun je het je niet veroorloven tijd te verliezen. Zorg voor draagvlak binnen het bredere bedrijf, zodat mensen interne vergaderingen of extra verantwoordelijkheden kunnen uitstellen en zich gedurende die periode volledig op hun werk kunnen richten.

Snel prototypen voor jou laten werken

Ik heb deze nieuwe manier van werken als bijzonder bevredigend ervaren; soms voelde het chaotisch, rommelig en onbeheersbaar. Het is lastig om te weten waar en in welke mate je van je huidige proces moet afwijken, maar ik wil je aanmoedigen om te experimenteren, snel te falen en open te zijn tegenover je team over wat je van hen nodig hebt.

Soms verwijderden we een essentieel onderdeel van het proces en voerden we het later opnieuw in, omdat duidelijk werd dat ik het project zonder dat onderdeel moeilijk kon managen. Op die momenten in het project zorgde ik ervoor dat ik de gevolgen van het verwijderen van dit proces duidelijk aan de rest van mijn team kon uitleggen. Als team bespraken we of er een andere manier was waarop ik die informatie kon verkrijgen. Als we geen betere oplossing konden vinden, voerden we het proces opnieuw in. Op momenten als deze pluk je de vruchten van het opbouwen van een ondersteunende omgeving gebaseerd op wederzijds vertrouwen en respect. Bij elke stap leren, verbeteren en gaan we als één team verder.

Met dank aan Chris Thorpe voor deze principes; alles wat ik weet, komt door hem.