Hoe maak je een document met productvereisten (PRD)?

Belangrijke leerpunten

• Een document met productvereisten (PRD) definieert het doel, de kenmerken en het gedrag van een product, waarbij belanghebbenden op elkaar worden afgestemd en de ontwikkeling wordt begeleid.

• Agile-PRD's zijn gericht op gedeeld inzicht, klantbehoeften en flexibiliteit, waarbij te gedetailleerde specificaties worden vermeden.

• Effectieve PRD's omvatten doelen, veronderstellingen, userstory's, ontwerp en duidelijke items die buiten het bereik vallen, waardoor samenwerking en aanpassingsvermogen worden bevorderd.

• Werk samen met je team om een beknopt PRD op te stellen en regelmatig bij te werken, zodat het hele project duidelijk en afgestemd is.

Het bouwen van een succesvol product begint met een duidelijke richting en afstemming. Daar komt een productvereistendocument (PRD) van pas.

Een PRD schetst de essentiële functies, doelen en functionaliteit van een product, wat dient als een productroadmap voor teams om ideeën om te zetten in werkelijkheid. Dit is een cruciale stap voor elke productmanager die teams, belanghebbenden en de algemene doelen op één lijn moet brengen.

In dit artikel leggen we uit wat een productvereistendocument is, waarom het belangrijk is en hoe het de basis legt voor effectieve productontwikkeling.

Wat is een document met productvereisten (PRD)?

Een productvereistendocument (PRD) definieert het product dat je gaat bouwen: het beschrijft het doel van het product, de functies, functionaliteiten en gedrag van het product.

Het definieert het doel van het product, belangrijke productfuncties, gebruikersbehoeften en succescriteria, en biedt één bron van waarheid voor multifunctionele teams.

Door vereisten en verwachtingen duidelijk te documenteren, helpt een PRD ervoor te zorgen dat iedereen—van ontwerpers en ontwikkelaars tot belanghebbenden—op één lijn blijft gedurende het hele productontwikkelingsproces.

Productvereistendocument voor agile werk

Hoe ziet het proces voor het verzamelen van vereisten eruit in een agile wereld? Het klinkt lastig, en dat is het ook. Maar maak je geen zorgen.

Bij Atlassian weten we alles over het aanmaken van PRD's in een agile omgeving. Agile vereisten zijn de beste vriend van een producteigenaar.

Producteigenaren die geen agile vereisten gebruiken, worden in beslag genomen door het specificeren van elk detail om de juiste software te leveren (en gaan vervolgens zitten duimen in de hoop dat ze de juiste dingen hebben opgenomen in de specs). Aan de andere kant zijn agile vereisten ook afhankelijk van een gedeeld begrip van de klant.

Dit wordt gedeeld tussen de producteigenaar, designer en het ontwikkelteam. Door dat gedeelde begrip en empathie voor de doelklant krijgen producteigenaren toegang tot verborgen mogelijkheden.

Ze kunnen zich richten op hogere eisen en implementatiedetails overlaten aan het ontwikkelingsteam, dat volledig is uitgerust om dit te doen, vanwege dat gedeelde begrip.

Tips voor het aanmaken van een effectief productvereistendocument

Als je enthousiast bent over het idee van gedeeld begrip, maar geen idee hebt hoe je het bereikt, probeer dan enkele van deze tips:

• Vraag bij gesprekken met de klant of een lid van de ontwerp- en ontwikkelingsteams kan aanschuiven, zodat ze rechtstreeks van de klant kunnen horen wat de bedoeling is in plaats van te vertrouwen op de notities van de producteigenaar. Het geeft hen ook de kans om door te vragen terwijl het onderwerp nog op het netvlies van de klant staat.

• Maak van het ontwikkelen en gebruiken van klantpersona's een teaminspanning. Elk teamlid heeft unieke perspectieven en inzichten en moet begrijpen hoe de persona's de productontwikkeling beïnvloeden.

• Maak ook een teamsport van de triage van werkitems en het groomen van de backlog. Dit zijn geweldige kansen om ervoor te zorgen dat iedereen hetzelfde voor ogen heeft en te begrijpen waarom de producteigenaar prioriteit heeft gegeven aan werk zoals dat is gedaan.

Wil je het uitproberen? Registreer je voor Confluence.

Maak een sjabloon voor klantgesprekken om de verkregen klantinzichten te documenteren. Volg onze tutorial om aan de slag te gaan met het voeren van waardevolle klantgesprekken:

• Maak inzichtelijke pagina's aan voor gesprekken met klanten

• Zet informatie om in inzichten met de Pyramide voor een klantgesprek

Je hebt een reeks userstory's besproken met je engineer en ontwerper. Er is wat discussie geweest, je hebt een paar whiteboardsessies georganiseerd en concludeert dat er nog wat dingen zijn waar rekening mee gehouden moet worden voor deze functie waaraan jullie werken.

Jullie moeten enkele aannames verder uitwerken, dieper nadenken over hoe dit past in het totaalplaatje en alle open vragen bijhouden die jullie moeten beantwoorden. Hoe nu verder?

Wat moet een PRD bevatten?

Bij het opstellen van een document met vereisten is het handig om met het hele team een consistente sjabloon te gebruiken, zodat iedereen de voortgang kan volgen en feedback kan geven. Bij Atlassian gebruiken we Confluence om productvereisten op te stellen met de sjabloon voor documenten met productvereisten.

We hebben ontdekt dat het onderstaande gedeelte 'net genoeg' context biedt om de vereisten van een project en de impact ervan op gebruikers te begrijpen:

1. Definieer de kenmerken van je project

We raden aan om de volgende algemene informatie als volgt bovenaan de pagina op te nemen:

• Deelnemers: Wie zijn erbij betrokken? Vermeld de producteigenaar, het team en de belanghebbenden

• Status: Wat is de huidige status van het programma? Op schema, in gevaar, vertraagd, uitgesteld, enz.

• Beoogd releasemoment: Wanneer wordt het product naar verwachting geleverd?

2. Teamdoelen en bedrijfsdoelstellingen

Kom meteen ter zake. Informeer, maar hou het leuk. De juiste software hebben om deze doelen gedetailleerd weer te geven—in een overzichtelijke weergave—is nuttig voor alle betrokkenen.

Bedrijfsdoelstellingen moeten kort en bondig zijn, maar ook informatief genoeg om belanghebbenden op één lijn te krijgen. Geef anderen geen kans om aannames te maken.

3. Achtergrond en strategisch belang

In het gedeelte ‘Achtergrond’ wordt uitgelegd wat de drijfveer achter het product of de functie is en hoe deze aansluit bij de bredere bedrijfsdoelstellingen. Het biedt context voor waarom het project belangrijk is en welke problemen het wil oplossen.

Door de strategische aansluiting uit te werken, zorg je ervoor dat iedereen begrijpt hoe dit werk de visie en prioriteiten van de organisatie ondersteunt. Deze duidelijkheid helpt teams gefocust te blijven op het leveren van waarde die ertoe doet.

4. Aannames

Dit gedeelte beschrijft alle aannames die het team maakt over technologie, zakelijke behoeften of gebruikersgedrag. Het duidelijk vermelden van aannames helpt bij het identificeren van potentiële risico's en gebieden die mogelijk nog getoetst moeten worden.

Het zorgt er ook voor dat iedereen op de hoogte is van de factoren die beslissingen en planning beïnvloeden. Het opnieuw bekijken van deze aannames gedurende het project kan teams helpen zich aan te passen wanneer nieuwe informatie naar voren komt.

5. Userstory's

Maak een lijst of link naar de betrokken userstory's. Link ook naar gesprekken met klanten en voeg screenshots toe van wat je hebt gezien. Geef voldoende details om een complete story te maken en voeg successtatistieken toe.

6. Gebruikersinteractie en ontwerp

Nadat het team de oplossing voor elke userstory heeft uitgewerkt, link je ontwerpverkenningen en wireframes aan de pagina.

7. Vragen

Omdat het team de problemen begrijpt die moeten worden opgelost, hebben ze vaak vragen. Maak een tabel met 'dingen die we moeten beslissen of onderzoeken' om deze items te volgen.

8. Wat we niet doen

Houd het team gefocust op het voor handen liggende werk door duidelijk aan te geven wat je niet gaat doen. Bespreek zaken die op dit moment buiten het aandachtsgebied vallen, maar die op een later tijdstip kunnen worden overwogen.

Voordelen van een goed geschreven productvereistendocument

Als er iets is wat je van deze blog kunt leren, is dat het 'waarom' en niet het 'wat' belangrijk is, omdat het 'waarom' je zal helpen ontdekken wat het beste is voor je team.

Dit zijn de voordelen en uitdagingen die we hebben bepaald met de aanpak met een dashboard met één pagina:

1. Eén pagina, één bron

Houd het simpel. Het document met productvereisten wordt de 'landingspagina' voor alles wat te maken heeft met de reeks problemen binnen een bepaalde epic.

Het bieden van een centrale locatie bespaart je teamleden tijd bij het raadplegen van deze informatie en geeft ze een beknopt overzicht.

2. Extra flexibel

Een van de geweldige dingen van het gebruik van een eenvoudige pagina om samen te werken (in plaats van een speciale tool voor het beheer van vereisten) is dat je agile kunt zijn over je documentatie. Je hoeft niet elke keer hetzelfde format te volgen. Doe wat je moet doen, wanneer dat nodig is en wees flexibel. Durf te kiezen voor verandering waar dat nodig is.

3. Net genoeg context en details

We vergeten vaak hoe krachtig een simpele link kan zijn. We nemen heel veel links op in onze documenten met productvereisten. Hierdoor wordt een document minder complex en kan de lezer er zelf voor kiezen om bepaalde informatie geleidelijk tot zich te nemen.

Het linken naar gedetailleerde resources is bijvoorbeeld handig in deze gevallen:

• Klantgesprekken voor achtergrond, validatie of verdere context voor de functie

• Pagina's of blogs waar soortgelijke ideeën worden voorgesteld

• Eerdere discussie of technische documentatie en diagrammen

• Video's van productdemo's of andere gerelateerde inhoud uit externe bronnen

4. Actuele story's

Zodra de story's in hoofdlijnen klaar zijn en als werkitems zijn ingevoerd in Jira, koppelen we ze op onze pagina (waardoor er, heel handig, ook een link van de werkitems naar de pagina wordt aangemaakt).

De tweerichtingssynchronisatie tussen Confluence en Jira betekent dat we automatisch de huidige status van elk werkitem te zien krijgen vanaf de pagina met vereisten.

5. Collectieve wijsheid

Het vastleggen van productvereisten in Confluence maakt het voor andere mensen in verschillende teams gemakkelijk om bij te dragen en suggesties te geven. Ik ben verbaasd over het aantal keren dat iemand van een ander team een bijdrage heeft geleverd aan het gesprek met geweldige feedback, suggesties of lessen die zijn geleerd van vergelijkbare projecten.

Het helpt een grote organisatie zich als klein team te voelen.

6. Boeiende 'extra's'

Diagrammen die zijn gemaakt met tools zoals Confluence Whiteboards communiceren de problemen beter naar je team. Je kunt ook externe afbeeldingen, video's en dynamische inhoud insluiten.

7. Samenwerking

Het belangrijkste aspect van dit alles is om iedereen erbij te betrekken. Schrijf een document met productvereisten nooit alleen. Je moet altijd de hulp van een ontwikkelaar inroepen en het document samen schrijven. Deel de pagina met je team en vraag om feedback.

Reageer, stel vragen, moedig anderen aan om bij te dragen met gedachten en ideeën. Dit is vooral belangrijk voor verspreide teams die niet vaak de kans krijgen om projecten persoonlijk te bespreken.

De uitdagingen van productvereistendocumenten

Elke aanpak heeft ook nadelen. Dit zijn twee belangrijke uitdagingen die we zelf hebben meegemaakt en ook van klanten te horen hebben gekregen:

1. Documentatie kan verouderen

Wat gebeurt er als je een story implementeert en feedback krijgt en de oplossing vervolgens aanpast? Is er dan iemand die de pagina met vereisten bijwerkt met de definitieve implementatie?

Dit is een uitdaging met elk type documentatie, en het is altijd de moeite waard om je af te vragen wat hier de beste oplossing is. Praat met je team over wat je zou doen in een dergelijk scenario.

2. Gebrek aan participatie

"Wat kan ik doen om mensen aan te moedigen commentaar te geven?", "Hoe kan ik mensen aanmoedigen om meer specificaties toe te voegen en story's op ons intranet te schrijven?"

Dit is een lastige uitdaging en de oplossing ligt in het toepassen van verschillende technieken voor het implementeren van wikipagina's in de organisatie. Er zijn genoeg middelen om je hiermee te helpen. Er kunnen hier ook diepere culturele kwesties een rol spelen.

Ga aan de slag met je PRD met Jira en Confluence

Wanneer de vereisten agile zijn, heeft de producteigenaar meer tijd om de markt te begrijpen en hiermee gelijke tred te houden. En door de vereisten informatief maar beknopt te houden, kan het ontwikkelingsteam de implementatie gebruiken die het beste past bij hun architectuur en technologiestack.

Zodra de vereisten van een project redelijk op orde zijn, raden we aan de userstory's in sectie 5 hierboven te koppelen aan de bijbehorende story's in de werktracker van het ontwikkelingsteam.

Dit maakt het ontwikkelingsproces transparanter: het is gemakkelijk om de status van elk stuk werk te zien, wat zorgt voor beter geïnformeerde beslissingen van de producteigenaar, evenals van stroomafwaartse teams zoals marketing en support.

Vergeet niet om agile te zijn in de ontwikkeling van vereisten voor een project. Het is prima om userstory's te veranderen terwijl het team bouwt, levert en feedback krijgt. Zorg er altijd voor dat je de lat hoog legt en een gezonde engineeringcultuur stimuleert, zelfs als dat betekent dat een release minder functies bevat.