Succesvolle releases beginnen met een product requirements document (PRD) dat deze vijf stappen bevat:
- Definieer het doel van het product.
- Breek het doel op in features.
- Stel de doelen voor de release criteria.
- Bepaal de tijdlijn.
- Zorg ervoor dat stakeholders reviewen.
We duiken hieronder in elk van deze stappen. Lees verder of spring vooruit naar de sectie die u wilt:
- Wat is een PRD (Product Requirements Document) Excel
- Hoe zit het met een Agile Requirements Document?
- Hoe schrijf je een PRD (Product Requirements Document)
- PRD Template: A Product Requirements Document Example
- Een PRD en traceerbaarheid
Wat is een Product Requirements Document (PRD)?
Een PRD (producteisen document) schetst de eisen van wat je gaat bouwen, zodat mensen weten wat het voltooide product moet doen.
Een PRD is de beste vriend van een productmanager. Het bepaalt de koers van de release. En het zorgt ervoor dat je levert wat klanten willen – op tijd.
Iedere stakeholder die bij de release is betrokken – ontwikkelaars, testers, projectmanagers – moet weten wat er in de PRD staat.
PRD’s bevatten doorgaans de volgende elementen:
- Doel – Voor wie is het bedoeld en waarom bouw je het.
- Features – Wat ga je bouwen.
- Releasecriteria – Doelen voor de release (bijv, functionaliteit).
- Timeline – Een ruw venster voor de release.
Wat dacht je van een Agile Requirements Document?
Documentatie is typisch het tegenovergestelde van Agile. Maar ook Agile ontwikkelteams hebben baat bij het gebruik van PRD’s.
Bij Agile-ontwikkeling maak je user stories in plaats van traditionele requirements. Een Agile requirements document verzamelt dus de user stories die essentieel zijn voor een release.
Het bevat nog steeds dezelfde elementen – doel, kenmerken, releasecriteria, tijdlijn. Maar een Agile requirements document doet dit meestal in een task board of interactief document, in plaats van in een statisch document.
Een PRD hoeft tenslotte geen roman te zijn. Je kunt de essentie van een productrelease in een one-pager behandelen – en ervoor zorgen dat je ontwikkelteam de Agile-koers blijft volgen.
👉🏼 LEES OOK: Hoe doe je een Agile hybride in een gereguleerde industrie >>
Hoe schrijf je een PRD (Product Requirements Document)
Het schrijven van een effectieve PRD is belangrijk.
Hoewel u de taak krijgt om het document zelf te schrijven, moet dit een gezamenlijke inspanning zijn. Je werkt samen met meerdere belanghebbenden binnen de ontwikkeling. Dit zorgt ervoor dat iedereen op dezelfde lijn zit wat betreft de doelen van de productrelease. En het zorgt ervoor dat wat u ontwikkelt voldoet aan de behoefte van de klant – en op tijd kan worden voltooid.
Houd in gedachten: het algemene doel van een PRD is te definiëren wat u gaat bouwen – niet hoe u het gaat bouwen.
Hier volgen vijf stappen voor het schrijven van een effectieve PRD voor een succesvolle productrelease.
Definieer het doel van het product
Iedere ontwikkelaar moet het eens zijn over het doel van het product. Het doel moet de features aansturen.
Het doel zou moeten schetsen:
- Welke problemen lost dit product op.
- Wie zal het product gebruiken.
- Waarom is het belangrijk.
Iedere stakeholder zou het eens moeten zijn over het doel – en zich ervan bewust moeten zijn naarmate de ontwikkeling vordert.
Break the Purpose Downto Features
De volgende stap is het bepalen van de feature requirements voor de release. Elke feature moet het algemene doel van je product ondersteunen.
Een best practice voor het bepalen van feature-eisen is om eerst thema’s en initiatieven te definiëren.
Een thema lijnt de organisatie voor jaren uit.
Een aantal voorbeelden van een thema zou kunnen zijn:
- API
- Performance
- Mobile
Thema’s kunnen meerdere jaren en releasecycli doorkruisen.
Initiatieven worden gebruikt om de ontwikkelingsinspanningen af te stemmen op het bereiken van een thema. En initiatieven zorgen ervoor dat je weet dat dingen in de goede richting gaan. Een initiatief kan meerdere thema’s omvatten, bijvoorbeeld het integreren van functies voor API, prestaties, en mobiel.
Van daaruit wordt een initiatief opgesplitst in feature-eisen.
▶️ WATCH: Van het plannen van een thema tot het stellen van eisen >>
Stel de doelen voor de releasecriteria
Het stellen van de juiste doelen voor de releasecriteria zal je helpen het doel van de productrelease te bereiken.
Jouw doelen moeten:
- Gemakkelijk te begrijpen.
- Actioneerbaar.
- Aanvaardbaar.
- Maatbaar.
En release criteria moeten vijf gebieden bestrijken.
Functionaliteit
Je moet de minimale functionaliteit definiëren die je nodig hebt om het product te kunnen releasen. Een voorbeeld is het definiëren van eisen die kritisch zijn voor de release.
Usability
U moet ervoor zorgen dat het product gemakkelijk te gebruiken is. Een voorbeeld hiervan is het bepalen van de omvang van gebruikerstests – en wat u met de resultaten gaat doen.
Betrouwbaarheid
U moet ervoor zorgen dat uw product betrouwbaar is. U moet er bijvoorbeeld voor zorgen dat het product kan herstellen na een systeemstoring.
Prestaties
U moet een basislijn voor prestaties vaststellen. Een voorbeeld is bepalen hoe snel uw product moet laden.
Ondersteunbaarheid
U moet bepalen of de release kan worden ondersteund. Een voorbeeld is ervoor zorgen dat het kan worden geïnstalleerd en geconfigureerd door gebruikers.
Bepaal de tijdslijn
Elke productrelease heeft een doelreleasedatum nodig – zelfs als het een ruwe schatting is.
Dit moet u flexibiliteit geven om u aan te passen aan een verandering in prioriteiten. Maar het moet ook de scope creep beperken door te beperken hoeveel features belanghebbenden kunnen toevoegen.
Het beheren van het releaseproces – en het halen van de beoogde releasedatum – kan lastig zijn.
▶️WATCH: How to Fix Your Release Process >>
Make sure Stakeholders Review It
Wanneer u een PRD opstelt, is het van vitaal belang dat de belangrijkste belanghebbenden het document beoordelen.
Dit kan lastig zijn als je een requirementsdocument in Microsoft Word beheert.
Het is een best practice om een centrale oplossing te hebben waar je requirements reviews online kunt beheren. Dan weet je zeker dat iedereen naar de meest recente versie van het document kijkt.
Het is ook belangrijk dat iedereen die betrokken is bij de ontwikkeling van het product weet wat er in de PRD staat. Het moet worden gedeeld met iedereen, van ontwikkelaars tot testers tot managers.
📑 GET WHITE PAPER: 9 Tips voor het schrijven van bruikbare requirements >>
PRD-sjabloon: A Product Requirements Document Example
Veel teams gebruiken Microsoft Word voor het maken en beheren van PRD’s.
Hier volgt een voorbeeld van een document met producteisen in Microsoft Word:
Het up-to-date houden van een PRD is moeilijk in een tool als Microsoft Word. Het is moeilijk om de nauwkeurigheid te waarborgen wanneer de vereisten op één plek worden bijgehouden – weg van de rest van de ontwikkeling. Ervoor zorgen dat iedereen toegang heeft tot de laatste versie is een uitdaging. Het is moeilijker om samen te werken. En het is praktisch onmogelijk om Agile te zijn.
Daarom gebruiken veel ontwikkelteams requirements management software om een PRD te maken. Het haalt ze weg uit de silo’s van informatie. Requirements zijn altijd up-to-date. En het kan door elk ontwikkelteam worden gebruikt, of ze nu Waterval- of Agile-ontwikkelprocessen volgen.
Hier volgt een voorbeeld van diezelfde PRD in Helix ALM:
Een Agile-eisen-document kan ook worden gemaakt in een takenbord. Dit geeft u in één oogopslag inzicht in de status van requirements.
In dit Kanban-bord ziet u bijvoorbeeld hoe user stories (vereisten) worden beoordeeld en geïmplementeerd.
Als u ontwikkelt in sprints (zoals de meeste Agile-teams), kunt u Helix ALM gebruiken om de voortgang van elke sprint te bewaken. U ziet welke user stories zijn geïmplementeerd en gevalideerd.
Een PRD en traceerbaarheid
Het schrijven van een PRD is slechts één stap op weg naar efficiënte ontwikkeling en een beter releaseproces. Succesvolle releases zijn ook afhankelijk van grondig testen en het snel oplossen van bugs.
Het is dus een best practice om een tool te hebben – zoals Helix ALM – waarmee je user stories (of requirements), tests en issues allemaal op dezelfde plek kunt bijhouden. Vervolgens kun je zelfs je PRD gebruiken om testdekking te garanderen door testgevallen te creëren op basis van user stories. En je kunt de resultaten volgen tot en met het oplossen van bugs.
✏️ Leer 6 oefeningen om traceerbaarheid te versterken >>
In Helix ALM gebeurt dit via een traceerbaarheidsmatrix (die automatisch door de tool wordt gegenereerd):