Hoe maak je een document met productvereisten (PRD)?

Het bouwen van een geweldig product vereist veel onderzoek en uitgebreide planning. Maar waar begin je? Productmanagers beginnen vaak met een PRD.

A product requirements document defines the product you are about to build: It outlines the product's purpose, its features, functionalities, and behavior.

Next, you share the PRD with (and seek input from) stakeholders - business and technical teams who will help build, launch or market your product.

Once all stakeholders are aligned, the PRD serves as a compass, providing clear direction toward a product's purpose while creating a shared understanding among business and technical teams.

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 samenstellen van PRD's in een agile omgeving. Dit zijn een paar dingen om in gedachten te houden:

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).

Agile vereisten zijn daarentegen ook afhankelijk van een gedeeld begrip van de klant dat wordt gedeeld tussen de producteigenaar, de ontwerper en het ontwikkelingsteam. 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. Inderdaad, vanwege dat gedeelde begrip.  

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 eens proberen? Meld je aan of log in op 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:

• Ontwerp inzichtelijke pagina's voor gesprekken met klanten

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

Goed. Je hebt een reeks userstory's besproken met je engineer en ontwerper. Er is wat discussie geweest, je hebt een paar whiteboard-sessies 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?

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.

3. Achtergrond en strategisch belangWaarom doen we dit? Hoe past dit binnen de algemene doelstellingen van het bedrijf?

4. Aannames

Maak een lijst van de aannames die je mogelijk doet vanuit technisch, zakelijk of gebruikersoogpunt.

5. Userstory's

Maak een lijst van of link naar de betrokken gebruikersverhalen. 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.

Hieronder zie je een volledig uitgewerkt document met productvereisten dat we hebben samengesteld met Confluence. Belangrijk om te onthouden is dat twee productvereisten nooit precies hetzelfde zullen zijn. Gebruik dit voorbeeld om de verschillende elementen te begrijpen die in een PRD aanwezig moeten zijn, maar zie dit niet als de enige manier om dit te doen.

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 gemaakt met tools zoals Visio, Gliffy of Balsamiq helpen problemen beter over te brengen aan je team. Je kunt ook externe afbeeldingen, video's en dynamische content 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.

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.

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.