januari 23, 2018
door Ron Yang

verhalen. Je hebt honderden van hen als je een product manager. Elk beschrijft de geweldige ervaringen die u wilt dat uw klanten te hebben tijdens het gebruik van uw product. En zoals elke goede verhalenverteller, moet je verhalen duidelijk en impactvol zijn.

alle beste productmanagers die ik ken zijn verantwoordelijk voor het delen van wat klanten echt willen via gebruikersverhalen.

maar hier is wanneer een product manager is hard werken. Er zijn ook momenten waarop van u wordt verwacht dat u de vereisten definieert voor wat uw ontwikkelingsteams moeten bouwen — zonder het ‘waarom’ te geven vanuit het perspectief van de gebruiker.

hoewel de meeste nieuwe functionaliteit moet worden gedefinieerd vanuit het perspectief van de gebruiker, is dat niet altijd haalbaar of zelfs nuttig. Denk bijvoorbeeld aan beveiligingskenmerken of infrastructuurvereisten die niet altijd met de klant worden geconfronteerd.

dus de vraag wordt: wanneer gebruikt u deze verschillende vaten? Voordat je dat kunt beantwoorden, moet je begrijpen wat ze anders maakt.

er is één belangrijk onderscheid tussen gebruikersverhalen en behoeften: de doelstelling.

het verhaal van de gebruiker richt zich op de ervaring — wat de persoon die het product gebruikt wil kunnen doen. Een traditionele eis richt zich op functionaliteit — wat het product moet doen. De resterende verschillen zijn een subtiele, maar belangrijke lijst van “hoe”, ” wie ” en “wanneer”.”

hier is hoe gebruikersverhalen en vereisten verschillen:

Hoe is het geschreven?

gebruikersverhalen MOETEN in één of twee zinnen worden geschreven en vastleggen wie de gebruiker is, wat hij wil en waarom. Een eenvoudige structuur voor het definiëren van functies of gebruikersverhalen kan er ongeveer als volgt uitzien: als een ____, wil ik ____ bereiken, zodat ik het volgende voordeel van ____realiseer.

voorbeeld: als gebruiker wil ik mijn wachtwoord opnieuw kunnen instellen zodat ik weer in het systeem kan komen als ik het vergeet.

de vereisten zijn vaak zeer gedetailleerd en nemen meer tijd in beslag om te schrijven. Deze gaan vaak in specifieke detail (soms zeer technische) over hoe de software moet werken. Die details begeleiden vervolgens het ontwikkelingsteam over het bouwen van een nieuwe functie of functionaliteit.

voorbeeld: de gebruiker mag zijn wachtwoord opnieuw instellen zodra hij een e-mail voor het opnieuw instellen van het wachtwoord heeft ontvangen. De e-mail moet een unieke link bevatten voor het resetten van het wachtwoord en die link moet verlopen na twee uur.

Wie schrijft het?

gebruikersverhalen kunnen geschreven worden door bijna iedereen die dicht bij de software — ontwikkelaars staat en problemen oproept, een QA — tester die een fout ontdekt in de UX-zolang het het perspectief van de eindgebruiker vertegenwoordigt. Maar het is de product manager of eigenaar die de achterstand van de gebruiker verhalen onderhoudt.

de vereisten worden geschreven door de productmanager, de producteigenaar of de business analist. Technische leads zijn vaak betrokken, evenals de ingenieurs die verantwoordelijk zullen zijn voor het werken aan de functies of verbeteringen.

wanneer zijn ze geschreven?

gebruikersverhalen worden door het hele gebouw van een product geschreven. En het updaten van de verhalen (of het toevoegen van nieuwe) kan op elk moment gebeuren. Voor agile teams, de product backlog dient als een geprioriteerde lijst van de functionaliteit die moet worden ontwikkeld. Dit is waar de gebruiker verhalen worden bewaard totdat ze worden gewerkt aan-meestal tijdens de ontwikkeling sprints.

eisen kunnen ook te allen tijde worden vervaardigd. Het is echter het beste om eerst te definiëren wat vanuit het standpunt van de gebruiker gewenst is als zowel de verhalen als de vereiste definitie vereist is. Hoe verder een team is met hun planning, hoe meer het team begrijpt de gebruiker en zakelijke behoeften. Dus, het definiëren van harde eisen te vroeg kan resulteren in het hebben om ze later te veranderen — of het bouwen van iets dat niet volledig het gewenste resultaat van de klant levert.

hoewel het doel van een gebruikersverhaal of — eis verschilt, is het doel altijd hetzelfde-het bouwen van een product waar klanten van houden.

of u nu een gebruikersverhaal of een vereiste schrijft, u moet zich concentreren op wat het belangrijkst is: het beschrijven van het gewenste resultaat voor de klant en het geven van de ontwikkeling wat ze nodig hebben om het succesvol te bouwen.

ik weet dat het verwarrend kan zijn om te beslissen wat te schrijven. Dus hier is een eenvoudige gids voor het maken van die keuze.

als wat u wilt bouwen een direct voordeel heeft voor uw eindgebruikers, schrijf dan een gebruikersverhaal. Als het meer centraal staat in de kern van een product of Infrastructuur, ga dan naar het definiëren van eisen.

welke verschillen zou u aan de lijst toevoegen?

Geef een antwoord

Het e-mailadres wordt niet gepubliceerd.