Het verschil tussen succesvolle mensen en echt succesvolle mensen is dat echt succesvolle mensen tegen bijna alles nee zeggen.
Warren Buffet, Amerikaans investeerder en filantroop
Of je nu nee zegt tegen bijna alles of niet, er is één ding dat je succesvol zal maken: Bewust kiezen wat je doet.
Met andere woorden, prioriteit geven aan het werk dat je doet is de basis van succes.
Deze stelregel geldt vooral voor productontwikkeling. In deze blogpost bespreken we waarom, wanneer en hoe je prioriteiten kunt stellen bij het bouwen van succesvolle softwareproducten.
Inzicht in de raamwerken voor productprioritering
Productprioritering is een gestructureerde aanpak die engineering teams gebruiken om beslissingen te nemen over welke functies te bouwen, wanneer en waarom.
In een typisch productontwikkelingsscenario zijn er tientallen bugs, verbeteringen en functies die de aandacht van het team nodig hebben. Productprioritering helpt teams hun aandacht te richten op het werk dat er toe doet.
Voorbeeld: Stel je bouwt een mobiele app voor gebruikers om het kaartspel Solitaire te spelen. Gebruikers vragen misschien om een knop om het spel ongedaan te maken. Adverteerders vragen misschien om een manier om video's toe te voegen tussen de spellen door.
Voor de prestaties van je app moet je misschien sommige functies in kleinere eenheden opsplitsen. Het productteam heeft misschien zijn eigen set nieuwe functies voor het spel. Wat doe je als eerste? Hoe stel je prioriteiten?
Goede ontwikkelteams gebruiken een nummer van beproefde agile prioriteringstechnieken om beslissingen te nemen. Deze raamwerken bouwen:
- Samenwerking: Het raamwerk geeft iedereen een gemeenschappelijke basis voor besluitvorming, waardoor onnodige meningsverschillen worden vermeden
- Consistentie: Wanneer dezelfde aanpak wordt gebruikt voorfunctieprioritering in elke Sprint, hebben teams consistentie en voorspelbaarheid op de lange termijn
- Duidelijkheid: Als het hele team weet waarom een beslissing wordt genomen, is er strategische afstemming op de product roadmap
- Snelheid: Met frameworks kunnen beslissingen sneller worden genomen, waardoor vergaderingen en ander heen-en-weergeloop tot een minimum worden beperkt
- Traceerbaarheid: Frameworks dienen ook als registratie van beslissingen uit het verleden, wat nieuwe leden van het team kan helpen om snel aan boord te komen
Dat is allemaal geweldig, maar wat zijn die frameworks precies? 🤔
Laten we dat eens uitzoeken.
Populaire kaders voor productprioritering
Er is niet één raamwerk voor productprioritering dat voor iedereen het beste is. In feite zijn er, afhankelijk van de situatie, de middelen en de te nemen beslissingen, verschillende raamwerken die teams voor productontwikkeling gebruiken. Hier zijn een paar sleutel raamwerken voor productprioritering die kunnen helpen bij uw reis.
1. MoSCoW-methode
MoSCoW - kort voor must-have, should-have, could-have en won't-have - is een eenvoudig en gemakkelijk te gebruiken prioriteringsraamwerk. Zoals de naam al zegt, helpt het Teams om functies in te delen in:
- Must have: Functies waarover niet te onderhandelen valt en die van cruciaal belang zijn voor de vergadering van de behoeften van de gebruiker
- Zou moeten hebben: Noodzakelijk maar niet zo tijdkritisch als de must-have functies
- Zou kunnen hebben: Good-to-have functies waar de gebruiker zonder kan leven
- Niet hebben: Niet belangrijk genoeg om op de radar van het team te staan
Dit is een geweldige methode om te volgen als de behoeften van de gebruiker duidelijk zijn en ook de primaire overweging voor de besluitvorming. Het dynamic systems development method (DSDM) agile raamwerk voor projectoplevering geeft de voorkeur aan MoSCoW als raamwerk voor prioritering.
| Pros | Cons |
|---|---|
| Eenvoudig en gebruiksvriendelijk | Beslissingen kunnen willekeurig zijn zonder gegevens over de behoeften van de gebruiker |
| Duidelijk en klantgericht | Makkelijk om het aantal must-have functies te overschatten |
| Binnen elke categorie is verdere prioritering onmogelijk |
voor- en nadelen van de MoSCoW-methode
2. RICE scoremodel
RICE staat voor bereik, impact, vertrouwen en inspanning. De RICE prioritering het model kent waarden toe aan elk van deze parameters en berekent een gecombineerde score op basis van welke functies prioriteit krijgen.
- Reach verwijst naar het aantal mensen/gebruikers die beïnvloed zullen worden door de functie (in een specifiek tijdsbestek)
- Impact verwijst naar de mate waarin gebruikers beïnvloed zullen worden, vaak gescoord op een schaal van 0,25 tot 3 (waarbij 3 staat voor een enorme impact)
- Confidence verwijst naar de mate van zekerheid van bereik- en impactschattingen, meestal weergegeven als een percentage
- Effort is de hoeveelheid werk die de functie vereist, meestal geschat in mensmaanden
Zodra je deze nummers hebt, bereken je de RICE-score met de volgende formule.
RICE score = (Bereik × Impact × Vertrouwen) / Inspanning
De RICE score vertegenwoordigt de potentiële waarde van de functie ten opzichte van de ontwikkelingsinspanning/middelen. Functies met een hogere RICE-score krijgen prioriteit.
| Pros | Cons |
|---|---|
| Kan complex zijn om te berekenen, vooral als er veel functies zijn | |
| De betrouwbaarheidswaarde compenseert eventuele onzekerheid in de schatting. Het inschatten van bereik, impact, inspanning, enz. kan moeilijk zijn, waardoor willekeurige scores ontstaan | |
| De waarde wordt weergegeven als functie van de inspanning (helpt ook het rendement op investering te meten). Afhankelijkheid die van invloed kan zijn op de prioriteit wordt niet meegenomen |
voor- en nadelen van het RICE score model
3. Kano-model
Net zoals MoSCoW rekening houdt met de behoeften van gebruikers, geeft het Kano-model prioriteit aan functies op basis van klanttevredenheid. Dit model is ontwikkeld door kwaliteitsmanagementexpert Noriaki Kano en categoriseert functies in:
- Basisfuncties: Zonder deze functies zal de klant ontevreden zijn
- Noden: Deze functies verbeteren de klanttevredenheid
- Delighters: Deze gaan verder dan dat om klanttevredenheid te creëren
Soms, productactiviteiten teams kunnen ook nog twee categorieën gebruiken, zoals 'onverschillige kwaliteit', functies die klanten tevreden noch ontevreden stellen, en 'omgekeerde kwaliteit', functies die bij implementatie tot ontevredenheid kunnen leiden.
| Pros | Cons |
|---|---|
| Gebruikersgericht met een duidelijk zicht op klanttevredenheid. Het prioriteringsproces en het verzamelen van CSAT-gegevens kan tijdrovend zijn | |
| Feedback van klanten wordt verzameld met behulp van de Kano-vragenlijst onder echte gebruikers. Het is mogelijk dat gebruikers die worden ondervraagd de functies die in de toekomst worden ontwikkeld niet begrijpen of zich niet kunnen voorstellen | |
| Verbindt gebruikerservaring (UX) met productkwaliteit | Richt zich alleen op klanttevredenheid zonder rekening te houden met inspanningen of middelen |
voor- en nadelen van het Kano-model_
4. Waarde versus inspanning kwadrant
Het waarde versus inspanning kwadrant is een eenvoudigere versie van het RICE scoringsmodel. Het vergelijkt de waarde van een functie, zoals inkomsten, winst, klantenwerving, kostenbesparingen enz. met de moeite die het kost om deze functie te ontwikkelen, inclusief risico's, afhankelijkheid en complexiteit.
Gebaseerd op de waarde versus de inspanning score, worden functies in vier kwadranten geplaatst, zoals de Eisenhower matrix. De functies met de hoogste score voor waarde versus inspanning krijgen prioriteit voor ontwikkeling.
| Pros | Cons |
|---|---|
| Waarde en inspanning kunnen ruim worden gedefinieerd, wat resulteert in willekeurige schattingen | |
| Helpt om beperkte middelen en inspanningen toe te wijzen aan aspecten die de meeste waarde vertegenwoordigen | 'Business waarde' kan vaak de focus wegnemen van de klantervaring |
| Aangezien hoge en lage inspanningen of waarde subjectief zijn, kunnen meningsverschillen ontstaan, waardoor beslissingen worden vertraagd | |
| Functies met een technische schuld en prestaties kunnen worden geprioriteerd vanwege het onvermogen om waarde in te schatten |
voor- en nadelen van het Waarde versus Inspanning Kwadrant_
ClickUp Matrix sjabloon voor prioriteiten
Probeer voor een meer eenvoudige versie van dit model de ClickUp Matrix met prioriteiten sjabloon . Bij deze methode categoriseert u functies op basis van twee dimensies: prioriteit en belang. Je legt ze visueel uit in een matrix van 2×2 en werkt ze vervolgens een voor een af.
5. ICE Score
ICE, zoals je misschien al geraden hebt, is vergelijkbaar met het RICE scoringsmodel, met kleine verschillen. ICE staat voor impact, vertrouwen en gemak.
- Impact: Potentieel effect of waarde van de functie voor het bedrijf
- Vertrouwen: Zekerheid over geschatte impact en gemak
- Gemak: Gemak waarmee deze functie kan worden ontwikkeld, rekening houdend met de risico's, middelen en complexiteit
ICE score = impact x vertrouwen x gemak
Functies met een hogere ICE-score krijgen voorrang boven functies met een lager nummer.
| Pros | Cons |
|---|---|
| Impact en gemak zijn subjectief, wat resulteert in willekeurige scores | |
| Vertrouwelijkheidsscore helpt bij het compenseren van onnauwkeurigheden in schattingen | |
| Wat u definieert als impact kan beslissingen over prioriteitstelling onevenredig beïnvloeden |
voor- en nadelen van ijsscores_
6. Opportunity scoren
Ontleend aan het baanbrekende boek "Resultaatgerichte innovatie" van Anthony Ulwick, rangschikt het opportunity scoring model functies op schalen van tevredenheid en belang. De eigenlijke rangschikking wordt gedaan door klanten. Teams stellen klanten dus twee vragen:
- Hoe belangrijk is een functie of de functie die het biedt?
- Hoe tevreden is de klant met de huidige oplossingen om hetzelfde resultaat te bereiken?
Dit helpt bij het identificeren van functies die het belangrijkst zijn maar de laagste tevredenheid hebben. Deze kun je prioriteren.
| Pros | Cons |
|---|---|
| De klant staat centraal, wat de kans op het creëren van waarde voor de business vergroot. Het is afhankelijk van de input van een klant, die al dan niet een mening heeft over functies die goed zijn om te hebben | |
| Eenvoudig en gemakkelijk te gebruiken | Enquêtes voor elke functie in de product roadmap kan vervelend zijn voor het ontwikkelteam en de klant |
| In kaart gebracht in een eenvoudige 2×2 grafiek voor visuele analyse |
voor- en nadelen van opportunity scoring_
7. Verhaal in kaart brengen
Story mapping is een raamwerk voor prioritering dat is opgebouwd rond de reis van de gebruiker door het product.
Simpel gezegd maken productmanagementteams kolommen voor elke belangrijke mijlpaal in het traject van de gebruiker.
Als je bijvoorbeeld het spel Solitaire aan het bouwen bent, kunnen de kolommen login, kaartontwerp, instellingen, het stapelen van kaarten, animaties voor het voltooien van het spel, enz. omvatten.
Onder elk van deze kolommen maken de teams een lijst met functies en prioriteren ze deze op basis van hun belang voor de algehele gebruikerservaring.
Story mapping wordt het meest gebruikt om de functies in het minimaal levensvatbare product (MVP) te identificeren. Als het product echter eenvoudig genoeg is, kan dit framework ook verder dan de MVP fase worden gebruikt.
| Pros | Cons |
|---|---|
| Gericht op het traject van de gebruiker, voor een maximale dekking. Als het traject van de gebruiker veelzijdig en complex wordt, kan deze methode zijn eenvoud verliezen | |
| Eenvoudig in gebruik en visueel - het is gemakkelijk om (letterlijk) de lijn te trekken rond wat je wel en niet gaat doen. Volledig intern gericht, houdt geen rekening met de waarde of middelen van de business | |
| Teams kunnen prioriteiten stellen op basis van activiteiten, taken en subtaken |
voor- en nadelen van story mapping_
8. Kosten van vertraging
Alle bovenstaande raamwerken richten zich op de pay-offs van de functie, zoals de zakelijke waarde of de verhoging van de klanttevredenheidsscore. De prioritering van vertragingskosten draait dat om.
Als je het vertragingskostenmodel gebruikt, geef je prioriteit aan functies op basis van de gevolgen van het niet bouwen ervan, bijvoorbeeld: wat gebeurt er als de klant deze functie vandaag nog niet heeft? Of hoeveel nieuwe gebruikers zullen verloren gaan als we een aantal basisfuncties niet hebben?
Rekening houden met de financiële en opportuniteitskosten van het niet doen van het werk motiveert teams om de belangrijkste dingen eerst Klaar te krijgen.
| Pros | Cons |
|---|---|
| De kosten van het niet doen van iets houdt teams alert op de kans die ze mislopen. Monetaire waarden die aan functies worden toegekend kunnen willekeurig zijn, waardoor het hele proces contraproductief wordt | |
| Focussen op de kosten van vertraging kan leiden tot negatieve gevoelens over waarom het team het product bouwt | |
| De focus van het team ligt op procesefficiëntie, snelheid en waarde |
voor- en nadelen van vertragingskosten_
De bovenstaande lijst is slechts een greep uit de meest populaire prioriteringstools die momenteel beschikbaar zijn voor engineering teams. Op basis van uw product, klant en behoeften kunt u een framework kiezen dat voor u werkt.
Teams gebruiken bijvoorbeeld het 100-dollar-testmodel of het buy-a-feature-model als ze concurrerende prioriteiten hebben . In elk van deze gevallen nemen teams beslissingen over prioriteiten op basis van waar ze hun budgetten ($100) aan zouden besteden.
Als productprioritering nieuw voor je is, kun je beginnen met een eenvoudige Eisenhower matrix . Er zijn tientallen sjablonen voor prioritering om uit te kiezen.
Ongeacht het framework dat je gebruikt, zijn er een aantal sleutel factoren om te overwegen. Laten we ze eens nader bekijken.
Het juiste raamwerk voor prioriteitstelling kiezen
Er is niet één universeel perfect raamwerk voor prioritering. Als je eenvoud nodig hebt, werkt het MoSCoW-model het beste. Als je beperkte middelen hebt, is het waarde versus inspanning model meer geschikt. En als de kwaliteit van je product van het grootste belang is, helpt het Kano-model.
Het kiezen van het juiste raamwerk voor prioritering hangt dus af van een aantal factoren, zoals de volgende.
Doelen
Wat zijn uw business doelen? Wat zijn je productdoelen? Als je in een zeer vroege fase zit, kan je primaire doel zijn om een MVP binnen een deadline te lanceren.
Hiervoor kan het framework voor het in kaart brengen van gebruikersverhalen de meest geschikte keuze zijn.
Bronnen
Als je een kleine organisatie bent met beperkte middelen voor ontwikkeling, kan je doel zijn om functies te bouwen die een maximale impact hebben met minimale middelen. Je prioriteringsraamwerk moet daarmee rekening houden.
In zulke gevallen is het RICE-model of de waarde versus inspanning matrix het meest geschikt.
Volwassenheid van teams
De beste manier om prioriteiten te stellen is door samen te werken. We hebben echter niet altijd teams met de volwassenheid om sleutelbeslissingen te doen.
Een voorbeeld: een team van jonge ontwikkelaars is misschien niet in staat om de lijn te zien van inspanning naar waarde voor de business.
In zulke gevallen nemen productmanagers vaak beslissingen namens het team. Dan zijn prioriteringsframeworks zoals RICE of waarde versus inspanning nuttig om het team te voorzien van de rationale voor beslissingen.
Beschikbare gegevens
De meeste kwantitatieve raamwerken, zoals RICE of ICE, vertrouwen op de kracht van gegevens.
Je moet bijvoorbeeld met redelijke zekerheid kunnen berekenen wat het bereik of de impact van een bepaalde functie is.
Als dergelijke gegevens niet beschikbaar zijn, kan de beslissing willekeurig worden en kunnen meningen hoog oplopen.
Als je de gegevens niet hebt, zijn samenwerkingsmethoden zoals MoSCoW of story mapping een betere keuze.
Productstrategie
Elke organisatie heeft een productmanagementstrategie . Het ene product wil misschien een handvol functies op een heerlijke manier aanbieden. Een ander product wil misschien de alles-in-één app zijn, volgestopt met functies. Weer een ander zou kunnen vertrouwen op wat klanten verwachten. Goede prioritering moet in lijn zijn met de productstrategie.
Als je eenmaal de prioriteringsstrategie hebt gekozen, is het tijd om deze effectief te implementeren.
Het implementeren van productprioritering in echte wereldscenario's
Een prioriteringsraamwerk is gewoon een hulpmiddel dat je helpt om beslissingen te nemen. Je succes hangt af van hoe je het hulpmiddel consistent en effectief gebruikt. Hiervoor moet je het grondig implementeren in je organisatie met een projectmanagement tool zoals ClickUp voor productteams . Zo werkt het.
Taken identificeren en categoriseren
Goede prioritering vereist een goede backlog. Voordat je iets doet, moet je ervoor zorgen dat je een sterke backlog hebt van functies die door je team moeten worden gebouwd.
Backlog maken
Geef elk backlog item een aparte naam en voeg er een duidelijke beschrijving aan toe. Deze sjablonen voor taakbeheer bieden een goed startpunt.
De beste manier om dit te doen is door gebruik te maken van een tool voor taakbeheer zoals ClickUp . Maak een taak voor elk backlog item, voeg een beschrijving toe, maak aangepaste velden en houd alle ideeën overzichtelijk bij.
Een dynamische backlog met ClickUp Taken
Taken weergeven
Geef nu al uw Taken op één plaats weer, zodat u gemakkelijker beslissingen kunt nemen. ClickUp's lijst-, kalender- en bordweergaven zijn hier fantastisch voor. Ze helpen u om uw taken te visualiseren en stellen u in staat om functies naar uw prioriteiten te slepen.
Taken categoriseren
Categoriseer nu de taken als uw prioriteitsraamwerk dat nodig heeft.
Als u bijvoorbeeld kiest voor het story mapping model, moet u uw taken categoriseren onder elke mijlpaal in het traject van de gebruiker. ClickUp's matrix sjabloon voor actieprioriteiten biedt een eenvoudige manier om taken te categoriseren op basis van inspanning en impact. Dit sjabloon vereenvoudigt beslissingen over prioriteiten en biedt duidelijkheid over de volgende stappen.
Prioriteit en eigenaar toewijzen
Zodra de basis is gelegd, is het tijd om de Taken te prioriteren in de categorieën die u hebt gekozen.
Prioriteren
Kom samen als een team, geef alle taken weer en verplaats ze naar de juiste prioriteit. Gebruik ClickUp-taak prioriteiten om prioriteitsniveaus buiten de box in te stellen.
Uit de doos prioriteiten stellen op ClickUp
Daarnaast kunt u ook aangepaste velden maken voor gepersonaliseerde prioriteitsniveaus.
U kunt bijvoorbeeld een Aangepast veld maken voor MoSCoW-prioritering en opties hebben voor moeten, zouden moeten, zouden kunnen en zullen.
Probeer voor een visuele benadering van dit proces eens Sjabloon voor de prioriteitenmatrix van ClickUp . Met dit sjabloon kunt u functies slepen en neerzetten op een 2×2 matrix voor prioritering. En wat is er nog meer? Je kunt ook je ideeënpool bijhouden in hetzelfde Whiteboard.
Eigendom toewijzen
Wijs op basis van je discussies de verantwoordelijkheid voor Taken toe aan de leden van je team.
Prioriteiten herzien en aanpassen
Elke Sprint is een oefening in prioriteiten stellen. Wat in de vorige Sprint niet zo belangrijk was, kan al snel belangrijk worden. Producteigenaren moeten zich dus kunnen aanpassen om van tijd tot tijd prioriteiten te herzien en aan te passen.
ClickUp maakt dat gemakkelijker. ClickUp Dashboards bieden een realtime weergave van de voortgang van elke taak, zodat u de prioriteiten kunt bekijken en aanpassen als dat nodig is.
Als u bijvoorbeeld ziet dat een functie meer tijd in beslag neemt dan verwacht, kunt u snel de RICE-score herberekenen en opnieuw prioriteiten stellen.
Sprint rapportage over ClickUp Dashboards
Met ClickUp Automatiseringen kunt u ook processen stroomlijnen om betere prioritering en levering te ondersteunen. Als een functie er bijvoorbeeld te lang over doet, kan dit worden gemeld aan de eigenaar van het product om de prioriteit aan te passen. Als iets afhankelijk is van een onvolledige Taak, kunnen ontwikkelaars worden gewaarschuwd voor aanpassingen. Of als de klanttevredenheidsscore voor een bepaalde functie daalt, kan deze automatisch hoger op de prioriteitenlijst worden gezet.
Met alle frameworks, tools en best practices die u nu onder de knie hebt hoe u prioriteit kunt geven aan uw werk . Hoe weet je nu of het effectief is? Hier zijn enkele ideeën.
Het succes van productprioritering meten
Voor veel teams, projectprioritering is een subjectieve oefening. Het antwoord op de vraag wat er nu gebouwd moet worden is vaak een beste gok. Zelfs met beproefde raamwerken is de besluitvorming willekeurig.
De enige manier om dat te vermijden is om het succes van de prioriteringsoefening zelf te evalueren. Dit is hoe.
Vergelijk met doelen
Een sleutel om te overwegen bij het prioriteren van productfuncties is het zakelijke doel. Meet het succes van je prioriteringsraamwerk door je af te vragen of je de genoemde doelen hebt bereikt.
Als het zakelijke doel bijvoorbeeld is om de klanttevredenheid te verbeteren en je hebt het Kano-model gebruikt, meet dan de toename in CSAT-scores na het implementeren van de functie.
Waarde meten
Veel prioriteringsmodellen, waaronder RICE, ICE, waarde versus inspanning, enz. zijn gebaseerd op de impact van de functie op de business. De beste manier om de effectiviteit van prioritering te meten is dus bijhouden of de waarde daadwerkelijk is gerealiseerd.
Als u bijvoorbeeld verwachtte dat het aantal aanmeldingen van nieuwe gebruikers zou toenemen na de nieuwste versie met prestatieverbeteringen, gebruik dan een widget op het ClickUp Dashboard om dit bij te houden vanaf de datum van de release van de functie.
Bijhouden van de nauwkeurigheid van gegevens
Als u een model gebruikt dat inspanningen meeneemt in prioriteringsbeslissingen, dan kan het ook nuttig zijn om de efficiëntie bij te houden.
Vergelijk bijvoorbeeld de geschatte tijdsinschatting met de werkelijk benodigde tijd om ervoor te zorgen dat de gegevens die u hebt gebruikt voor het prioriteren zo nauwkeurig mogelijk zijn.
Teamprestaties
Een van de dingen die niet vaak gemeten wordt, zijn de prestaties en tevredenheid van het team. Voelt het team zich overbelast met het prioriteringsraamwerk? Neemt het te veel tijd in beslag? Is het prioriteringsraamwerk geschikt voor de beschikbare middelen?
Om de effectiviteit van je prioritering te meten, is het ook nuttig om je team in gedachten te houden. Voer korte enquêtes uit om te begrijpen hoe prioritering van invloed is op werklastbeheer . Pas dienovereenkomstig aan.
Prioriteer succes met ClickUp
Het bouwen van geweldige software is afhankelijk van een aantal factoren: klantgerichtheid, technische uitmuntendheid, beschikbaarheid van middelen, een goed gedefinieerde strategie, de markt en nog veel meer. Om deze bewegende delen in evenwicht te brengen en de functies te bouwen die een maximale impact hebben, hebt u twee dingen nodig: Het juiste prioriteringsraamwerk en een krachtig hulpmiddel om het te implementeren.
In deze blogpost leer je enkele van de populairste raamwerken voor prioritering die worden gebruikt door goed presterende teams. Voor effectieve prioriteitenbeheer integreer uw kader in uw projectplanning met het alles-in-één platform voor projectmanagement van ClickUp.
Gebruik ClickUp om uw backlog te documenteren, visualiseren, categoriseren en prioriteren voor een effectieve productontwikkeling. Probeer ClickUp vandaag gratis uit .