In een eerdere artikel legde ik uit waarom Nick Fury (bekend van de Avengers) de ultieme product owner is. Een van de belangrijkste redenen is dat hij een team wist samen te stellen die zijn visie kon waarmaken. De Avengers zijn natuurlijk dat ultieme dreamteam voor Nick Fury.
Net als Nick Fury, heeft iedere product owner zijn eigen dreamteam nodig. Afhankelijk van het type product dat je wilt laten maken, heb je bepaalde type specialisten nodig die in het team zitten. In dit artikel vertel ik over de belangrijkste focuspunten van het design & development team en licht ik de meest voorkomende rollen uit.
Focus 1: Backlog planning
Waar de product owner zich vooral richt op het maken van de goede onderdelen, richt het team zich op de onderdelen goed te maken. Maar wanneer is iets goed genoeg? En wanneer is het écht duidelijk wat het team moet bouwen? Het design en development team houdt zich in eerste instantie met deze vragen bezig.
Het team dient de visie van de product owner te vertalen in duidelijke onderdelen die ontworpen, gebouwd, getest en gelanceerd kunnen worden. Dit wordt allemaal beheerd in een product backlog. Een product backlog bestaat dus uit features (ofwel ‘stories’), taken om deze features af te ronden en mogelijk subtaken wanneer een taak op zichzelf te groot is.
Het beheer van een product backlog wordt in samenspraak met de product owner gedaan.
| De backlog verandert constant Je krijgt continue nieuwe informatie over de behoeften van je eindgebruikers, de manier waarop het product gebruikt wordt, de veranderingen vanuit de organisatie die impact hebben op het product, nieuwe technologische ontwikkelingen, etc. Er zijn dus heel veel factoren die impact hebben op hoe het product dient te werken en wat je ervoor dient aan te passen. Wanneer je ervan uitgaat dat je de backlog één keer goed op moet zetten en erna klaar bent, zal je product vrijwel zeker falen. Het beheren van de backlog is een terugkerend proces waar zowel de product owner, als het design en development team verantwoordelijk voor zijn. |
Backlog vullen met story mapping
Er zijn verschillende methodes voor het invullen van een goede backlog. Een van de agile methodes is story mapping. Hiermee focus je als team op het doel van de eindgebruiker, welke stappen deze gebruiker moet nemen om het doel te behalen en wat er per stap zou kunnen helpen dit proces te vergemakkelijken. De onderstaande illustratie geeft een voorbeeld van een story map van een webshop.
Meer informatie over story mapping
Kaders bepalen met definition of done en definition of ready
Mooie hippe termen natuurlijk, maar waar gaat het over. De betekenis hiervan is redelijk simpel.
| Definition of done Met de definition of done bepaal je de eisen waar een onderdeel aan dient te voldoen. Ofwel; wanneer mag dit item als afgerond beschouwd worden? Stel dat je een zoekfunctie in de site wilt hebben. Wanneer je als taak alleen opschrijft ‘zoekfunctie’ is dit natuurlijk niet duidelijk genoeg. Wat kan iemand zoeken? Producten? Webpagina’s? Blogartikelen?Bestanden? Hoe ziet de zoekbalk eruit en waar wordt deze getoond? Hoe zien de zoekresultaten eruit? Wat is überhaupt het doel voor de eindgebruiker? In welke browsers dient het allemaal te werken? Je snapt het punt denk ik. Er zijn dus een enorme hoeveelheid zaken die je duidelijk moet maken zodat een developer goed begrijpt wat van hem gevraagd wordt. En wanneer je hier zelf geen duidelijk antwoord op hebt, is dit punt dus nog niet ver genoeg om gemaakt te kunnen worden. |
| Definition of ready In veel gevallen heeft een developer bijkomende en praktische informatie nodig om aan een onderdeel te kunnen beginnen. Stel dat je de website wilt koppelen aan het CRM systeem van de organisatie. Een developer heeft hiervoor informatie nodig zoals: – Development documentatie van het CRM – Goed geformuleerde Definition of Done (wanneer is de koppeling af?) – Inloggegevens voor de site en het CRM – Een technische contactpersoon die het CRM beheert – Wellicht wat testdataMet de definition of ready geeft het design en development team aan welke informatie er nodig is om aan een onderdeel te kunnen starten. |
Documenteren door requirements schrijven
Hoe complexer project is en hoe langer een project duurt, des te waardevoller is het om projectdocumentatie op te stellen en bij te houden. Hiermee documenteert het design en development team voor iedere onderdeel de specifieke eisen waar het aan dient te voldoen. Dit geeft het team de juiste focus, voorkomt enorm veel misverstanden en dwingt de product owner beter na te denken over zijn verzoeken, ideeën en wensen.
Bij Elephant hanteren we in vrijwel ieder project development documentatie. In dit artikel ga ik uitgebreid in op het nut van documenteren in webprojecten.
De juiste balans tussen snel, goed en goedkoop
Dit is een belangrijke spanningsveld voor het team. Hoe perfect moet iets zijn? Hoeveel mag het kosten? Wat zijn hier de gevolgen van voor het eindproduct en de organisatie? Wat als we het ‘quick & dirty’ oplossen? De meeste product owners willen features zo snel mogelijk hebben, voor een zo laag mogelijke prijs. Echter, wanneer je iets te snel aanpakt, zonder het goed uit te denken, komt het later hoogstwaarschijnlijk weer terug op de product backlog. Waarschijnlijk in de vorm van één of meerdere bugs.
Focus 2: Maak het goed
Als je alles goed hebt voorbereid en hebt bepaald waaraan je als eerst gaat werken, is het tijd om te beginnen. Als design & development team, werk je meestal in sprints. Dat zijn ontwikkel rondes van 1, 2, 3 of 4 weken. In deze periode werk je gericht aan een set van onderdelen die je eerder hebt gedefinieerd. Een dergelijke sprint ziet er idealiter als volgt uit:
| Sprint planning Iedere sprint begint met een sprint planning sessie. Dit duurt vaak een uur of 3 met het hele team. Tijdens de sprint planning legt de product owner uit welke onderdelen er opgeleverd dienen te worden en heeft het team de ruimte om alle onderdelen grondig te bespreken. Iedere sprint heeft tevens een doel dat de product owner en het team met elkaar af stemmen. Op basis van dit doel kunnen er ook gerichter prioriteiten gesteld worden aan de verschillende onderdelen. Na een sprint planning moet het design en development team zonder al te veel vragen de gehele sprint af kunnen ronden. |
| Daily standups Wanneer een sprint is gestart, houdt het team iedere ochtend een korte stand up. Iedere teamlid vertelt waar hij of zij aan gewerkt heeft, waar ze vandaag aan gaan werken en wat hun werk eventueel blokkeert. Zo houdt het team elkaar dagelijks op de hoogte van de ontwikkelingen. |
| Sprint demo Tijdens de sprint demo laat het team zien wat ze hebben gemaakt. Bij de sprint demo is de product owner uiteraard aanwezig. Het is ook wenselijk dat de belangrijkste stakeholders van het project aanwezig zijn zodat ze direct input kunnen leveren. Is er bijvoorbeeld een CRM integratie opgeleverd, dan zou het waardevol zijn als het salesteam aansluit bij de demo. Zij gebruiken het CRM dagelijks en kunnen direct waardevolle input leveren. Sprint demo’s zijn dus opleveringen waarin we direct feedback bij proberen te verzamelen. |
| Sprint retrospectives In een retrospective evalueert het team het proces van de afgelopen sprint. Wat ging er goed, wat ging er niet goed en hoe kunnen we de volgende sprint efficiënter maken? Het doel van retrospectives is om iedere keer een kleine verbetering in de aankomende sprint aan te brengen. Zo wordt het team steeds beter op elkaar ingespeeld en kan er uiteindelijk ook meer werk verzet worden in dezelfde periode. |
| Backlog grooming Tussen de sprints door zal er kritisch gekeken moeten worden naar de backlog. Er zijn constant nieuwe ontwikkelingen vanuit de markt, de organisatie, de technologie of vanuit het team die de product backlog beïnvloeden. De product owner pakt dit periodiek met het team aan om te kijken of er nieuwe ontwikkelingen zijn die op de backlog dienen te komen en of de prioriteiten nog kloppen. Door dit goed bij te houden, kan de product owner een werkvoorraad aanhouden van meerdere sprints. Dit houdt in dat het team voor een langere periode effectief door kan werken. |
Rollen in een design & development team
Per type product kunnen de rollen natuurlijk anders zijn. Echter zijn er in grote lijnen een aantal rollen die altijd nodig zijn. Iedere organisatie heeft zo haar eigen benamingen voor de daadwerkelijke functies, dus let niet al te letterlijk op deze labels. Het komt in grote lijnen op de volgende rollen neer:
UX designer
Een UX designer houdt zich bezig met de gebruikerservaring van het product. Dat heeft o.a. te maken met hoe het eruit ziet (visueel design), hoe de interactie aanvoelt (interaction design), hoe eenvoudig het in gebruik is (usability) en hoe alle informatie gestructureerd is (information architectuur). Een grote misvatting is dus dat een UX designer zich bezig houdt met ontwerpen. Dat is niet het geval. Een UX designer houdt zich vooral bezig met de gebruikers van het product en zorgt ervoor dat zij de meest optimale ervaring hebben bij het gebruik van het product.
UI / Visual designer
Een visual designer richt zich met name op het esthetische aspect van het product. Hoe ziet het eruit ? Hoe voelt het aan? Wat is het ‘karakter’ van het product? Moet het speels zijn? Of juist serieus? Of ergens tussenin? Hoe moet zich dit dan uiten in de user interface? Hier zit uiteraard best wat overlap in met een UX designer. In sommige gevallen valt dit ook onder één persoon, maar in de meeste gevallen is het logischer om dit wel gescheiden te houden. Waar een UX designer vooral veel tijd nodig heeft voor research, zal een visual designer vooral veel tijd nodig hebben voor het uitwerken van visuele componenten. Wanneer je dit gaat combineren, zal het ten koste gaan van diepgang of van snelheid. Één persoon heeft natuurlijk minder tijd en expertise dan twee personen.
Technical lead
Een technical lead is verantwoordelijk voor het technische concept en uitwerking van het product. Hij of zij kiest welke technieken er gebruikt zullen worden, hoe de developers hun werk dienen aan te leveren en adviseert de product owner op het gebied van implementatie. In sommige gevallen is de technical lead ook verantwoordelijk voor het goed functioneren van de andere teamleden en evalueert hij of zij hun voortgang.
Front-end developer
Een front-end developer is verantwoordelijk voor de ‘voorkant’ van het product. Hij of zij implementeert het design naar een interactief geheel en zorgt ervoor dat de gebruiker de informatie te zien krijgt die hij verwacht. Binnen deze discipline zijn er verschillende specialisaties, maar daar ga ik in dit artikel niet op in. Daar kan een volledig apart artikel aan gewijd worden ;).
Back-end developer
Een back-end developer is verantwoorden voor de ‘achterkant’ van het product. Denk hierbij aan de database structuur, de werking van koppelingen tussen verschillende systemen en het beheer van verschillende componenten. Ook binnen deze discipline zijn er verschillende specialisaties.
Tester
Een tester is verantwoordelijk voor de stabiliteit van het product. Vooraf de implementatie denkt de tester mee in de technische eisen en schrijft hij of zij hier een testplan voor. Tijdens de implementatie voert hij of zij de testen uit in samenwerking met de developers. Deze rol wordt heel vaak overgeslagen of gecombineerd met een development rol. Het wordt vaak ook onder het takenpakket van een product owner geplaatst.
Copywriter
Niet in ieder traject een fullt-time rol, maar vaak wel een belangrijke. Iedere digitale product heeft eenduidige copy nodig. Een copywriter werkt idealiter met de UX designer en visual designer, waarin een duidelijke tone-of-voice belangrijk is. Het kan hier om informatieve teksten gaan (binnen webpagina’s), om wervende teksten (landingspagina’s), maar ook om functionele copy (bijvoorbeeld teksten die je in een foutmelding ziet of in een notificatie).
Valkuilen bij design & development teams
Geen affiniteit voor het product of branche
Wanneer het team aan een product moet werken, maar geen gevoel heeft voor de branche kan het lastig worden iedereen goed aan boord te houden. Het is niet perse een vereiste dat het team de branche volledig kent. Het is wel belangrijk om hier in het traject aandacht aan te geven. Zorg ervoor dat je het team de branche leert begrijpen. Bereid presentaties voor en geef ze inzicht in wat er speelt. Een team met gevoel voor de branche, zal zelf sneller met betere oplossingen kunnen komen en beter betrokken zijn. En dit is een belangrijke succesfactor voor jouw succes.
Geen technical lead
Bij het ontbreken van een technical lead, wordt het lastig om een visie voor jouw product op te stellen en te waarborgen. Een technical lead is tevens jouw adviseur op technologisch gebied. Wanneer je dit niet hebt, wordt het voor het team lastig goed mee te denken. Je creëert zo een samenwerking waarin het team steeds meer als uitvoerend gezien zal worden. En dit zal op termijn zorgen voor lagere betrokkenheid.
Niet betrokken bij product roadmap vorming
Wat ik regelmatig ben tegengekomen in de afgelopen 10 jaar als projectmanager is dat opdrachtgevers het design en development team te laat of helemaal niet betrekken bij de ideevorming voor het product. Dit is een cruciale fout. Ten eerste loop je een heleboel expertise mis. Het design en development team kent jouw organisatie of branche misschien niet, maar zij weten als de beste wat de mogelijkheden en valkuilen zijn bij het implementeren van een idee. En hoe sneller je het team in je proces betrekt, hoe beter je ze op langer termijn betrokken kunt houden.
Te snel beginnen met maken
Iets wat ik ook vaak tegenaan ben gelopen, is dat er te snel gestart wordt met de implementatie. Om budget of planning redenen wordt besloten om de strategie fase te versnellen en zo snel mogelijk over te gaan naar design en development. Dit resulteert vaak in onvolledige opleveringen en een mindere gebruikerservaring. Vaak komen er later dan ook punten terug die opnieuw bedacht moeten worden. Onder aan de streep is de implementatie over een langere periode dan ook duurder. Zorg dus dat je genoeg tijd neemt om je product conceptueel én technisch goed uit te denken, voordat je echt start.
Inhuren vs. in-house nemen
Een belangrijke overweging is of je een development team wilt gaan vormen binnen je organisatie, of dat je een team of bureau inhuurt. De overweging hiervoor is vooral op financieel vlak. Voor het maken van een digitaal product heb je al snel vier verschillende disciplines nodig. Dat betekent dat je ongeveer vier mensen nodig hebt.
Team in-house nemen
Wanneer je overweegt dit team in dienst te nemen, moet je rekening houden met minimaal vier salarissen. Afhankelijk van het niveau dat je wilt hebben, zul je ongeveer 120.000 tot 200.000 per jaar aan kosten moeten rekenen.
Naast salarissen, heb je natuurlijk allerlei andere kosten die hier ook bij komen. Denk aan nodige software pakketten, werkplekken, juiste computers, trainingen voor het team. Naast directe kosten, heb je dus een heleboel indirecte kosten die erbij komen doordat je het team goed moet kunnen faciliteren.
Een derde factor is dat je het team uitgedaagd moet kunnen houden. Is het product relatief eenzijdig en verandert het niet erg veel? Dan bestaat de kans dat teamleden sneller om zich heen zullen gaan kijken. Het recruiten van designers en developers is vaak een grote uitdaging. Een team in-house nemen is dus pas rendabel wanneer je zoveel werkzaamheden ‘op de plank’ hebt liggen waarmee je een dergelijk team kunt uitdagen.
Team / bureau inhuren
In de meeste gevallen is dit de beste oplossing om mee te beginnen. Omdat het financieel en organisatorisch enorm lastig is om snel een eigen team op te zetten, is het inhuren van een bureau vaak minder riskant.
Uiteraard betaal je op uurbasis een stuk meer. Maar hiervoor heb je de flexibilteit van bij en af schalen van de capaciteiten. Daarbij heeft een bureau vaak alle nodige expertises in huis (UX, Design, Development, projectmanagement).
Wanneer je gaat starten aan een digitaal product, is er nog veel onzeker. Je weet niet of je genoeg klanten zult krijgen en of er écht constant werk nodig is om het product verder te ontwikkelen. Het is dan beter om te starten met een bureau, waarbij je in een later stadium kunt starten om een eigen team te bouwen.
Conclusie
Een design en development team is een multidisciplinair team dat jouw digitaal product daadwerkelijk bouwt. Dit team focust zich op het zo goed mogelijk bouwen van jouw product. Het is belangrijk het team al in de strategische fase te betrekken. Hiermee creëer je direct betrokkenheid bij het team en zorg je ervoor dat de gewenste ‘features’ beter worden uitgedacht.
In de meeste gevallen loont het zich om een bureau in te huren voor de ontwikkeling van je product. Een eigen team opzetten vergt niet alleen een financiële investering, maar brengt direct meerdere HR uitdagingen met zich mee. Daarnaast moet het team ook continue uitgedaagd kunnen worden om te voorkomen dat teamleden vertrekken.
Een design en development team is dus echt de kern van je product waar je goed mee om dient te gaan.
