Documenten met productvereisten, maar dan beknopt

Niemand vindt het leuk om vuistdikke, vreselijk gedetailleerde documenten met productvereisten op te stellen. En er is ook niemand die het leuk vindt om ze te gebruiken.

Dan Radigan By Dan Radigan
Onderwerpen zoeken

Samenvatting: een document met productvereisten (PRD) definieert de vereisten van een bepaald product, inclusief het doel, de functies, de functionaliteit en het gedrag van het product. Het dient als gids voor zakelijke en technische teams om het product te helpen bouwen, lanceren of op de markt te zetten.

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

Een document met productvereisten definieert het product dat je gaat bouwen: het beschrijft het doel van het product, de functies, functionaliteiten en gedrag van het product.

Documenten voor agile productvereisten | Atlassian agile coach

Vervolgens deel je de PRD met belanghebbenden en vraag je hen om input. Belanghebbenden zijn in dit geval de zakelijke en technische teams die gaan helpen bij het bouwen, lanceren of op de markt brengen van het product.

Zodra alle belanghebbenden het met elkaar eens zijn, dient het PRD als een kompas, dat duidelijke richting geeft aan het doel van een product en tegelijkertijd een gedeeld begrip creëert tussen zakelijke en technische teams.

Vereisten verzamelen in een agile wereld

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 afhankelijk van een gedeelde begrip van de klant dat wordt gedeeld tussen de producteigenaar, 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.

Zorgen voor een gedeeld begrip tussen teams

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 issues 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:

Antipatronen om op te letten
  • Het hele project is al tot in detail uitgewerkt voordat er is begonnen met engineeringwerkzaamheden
  • Alle teams moeten voordat het werk zelfs maar begonnen is een diepgaande evaluatie uitvoeren en hun onomkeerbare fiat geven
  • Ontwerpers en ontwikkelaars weten niet wanneer en of vereisten zijn bijgewerkt
  • Vereisten worden überhaupt niet bijgewerkt (omdat iedereen ze heeft goedgekeurd, weet je nog?)
  • De producteigenaar stelt vereisten op zonder het team hierbij te betrekken

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?

Vereisten overzichtelijk houden met een dashboard van één pagina

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. Specifieke kenmerken van het project definiëren
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?
Agile vereisten | Atlassian agile coach

2. Teamdoelen en bedrijfsdoelstellingen
Kom meteen ter zake. Informeer, maar hou het leuk.

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

Agile productvereisten | Atlassian agile coach

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

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.

Verhalen over agile vereisten | Atlassian agile coach

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

vergelijkingsdiagram

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.

Tip van pro's:

Het Agile-manifest herinnert ons eraan dat we flexibel kunnen zijn met hoe we vereisten definiëren. Sommige teams doen oefeningen voor het in kaart brengen van userstory's om problemen en oplossingen te identificeren. Soms bezoekt de volledige producttriade (producteigenaar, ontwikkelaar en ontwerper) een klant en brainstormt vervolgens over oplossingen voor een bepaald probleem dat speelt bij de klant.

Het maakt niet uit hoe vereisten ontstaan, het is belangrijk dat het team ze beschouwt als een van de vele manieren waarop ze klantproblemen kunnen definiëren en communiceren. Zie onze sectie over agile ontwerp om te leren hoe producteigenaren Keynote en Powerpoint kunnen gebruiken om echte ervaringen als vereisten te presenteren.

Voorbeeld van een PRD van één pagina

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.

Voorbeeld van document met productvereisten | Atlassian agile coach
Document met productvereisten | Atlassian agile coach

Wil je het eens proberen? Meld je aan of log in op Confluence >>

Kies vervolgens de blauwdruk voor productvereisten en volg de onderstaande tutorial om aan de slag te gaan met het instellen van je vereisten:

Belangrijke leerpunten van de aanpak met één pagina:

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
Hou 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 formaat 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
Ik zie dat veel klanten dit ook doen. Zodra de story's in hoofdlijnen klaar zijn en als issues zijn ingevoerd in Jira Software, koppelen we de story's op onze pagina (waardoor er, heel handig, ook een link van de issues naar de pagina wordt aangemaakt). De tweerichtingssynchronisatie tussen Confluence en Jira Software betekent dat we automatisch de huidige status van elke issue 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.

Uitdagingen

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 informatiebronnen om je hiermee te helpen. Er kunnen hier ook diepere culturele kwesties een rol spelen.

Aan het werk nu!

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

Tip van pro's:

Volg niet de userstory's die voortkomen uit projectvereisten in het ene systeem en defecten in een ander systeem. Het beheren van werk over twee systemen is onnodig uitdagend en is gewoon tijdverspilling.

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.