januar 23, 2018
Av Ron Yang

Historier. Du har hundrevis av dem hvis du er en produktleder. Hver og en beskriver de fantastiske opplevelsene du vil at kundene skal ha mens du bruker produktet. Og som enhver god historieforteller, trenger du historiene dine til å være klare og virkningsfulle.

Alle de beste produktsjefene jeg kjenner er ansvarlige for å dele hva kundene virkelig ønsker gjennom brukerhistorier.

men her er når det å være produktleder er hardt arbeid. Det er også tider når du forventes å definere kravene til hva utviklingsteamene dine trenger å bygge — uten å gi» hvorfor » fra brukerens perspektiv.

selv om de fleste nye funksjoner bør defineres fra en brukers perspektiv, er det ikke alltid mulig eller til og med nyttig. Vurder for eksempel sikkerhetsfunksjoner eller infrastrukturkrav som ikke alltid er kundevennlige.

så spørsmålet blir: Når bruker du disse forskjellige fartøyene? Før du kan svare på det, må du forstå hva som gjør dem forskjellige.

det er et stort skille mellom brukerhistorier og krav: målet.

brukerhistorien fokuserer på opplevelsen-hva personen som bruker produktet ønsker å kunne gjøre. Et tradisjonelt krav fokuserer på funksjonalitet – hva produktet skal gjøre. De resterende forskjellene er en subtil, men viktig, liste over «hvordan», «hvem» og » når.»

her er hvordan brukerhistorier og krav er forskjellige:

Hvordan er det skrevet?

brukerhistorier skal skrives i en eller to setninger og fange hvem brukeren er, hva de vil, og hvorfor. En enkel struktur for å definere funksjoner eller brukerhistorier kan se slik ut: Som en____, vil jeg oppnå _ _ _ _ slik at jeg innser følgende fordel med ____.

Eksempel: Som bruker vil jeg kunne tilbakestille passordet mitt slik at jeg kan komme tilbake til systemet hvis jeg glemmer det.

Krav pleier å være svært detaljerte og ta lengre tid å skrive. Disse går ofte inn i spesifikke detaljer (noen ganger svært teknisk) om hvordan programvaren skal fungere. Disse detaljene veileder deretter utviklingsteamet om hvordan man bygger en ny funksjon eller funksjonalitet.

Eksempel: brukeren kan tilbakestille passordet når de har mottatt en e-post for tilbakestilling av passord. E-posten skal inneholde en unik lenke for å tilbakestille passordet, og den lenken skal utløpe etter to timer.

Hvem skriver det?

brukerhistorier kan skrives av omtrent alle i nærheten av programvareutviklerne som reiser problemer, EN QA — tester som oppdager en feil i UX-så lenge den representerer sluttbrukerens perspektiv. Men det er produktsjefen eller eieren som opprettholder backlog av brukerhistorier.

Kravene er skrevet av produktsjef, produkteier eller forretningsanalytiker. Tekniske leads er ofte involvert, så vel som ingeniører som vil være ansvarlige for å jobbe med funksjonene eller forbedringene.

Når er de skrevet?

brukerhistorier er skrevet gjennom hele byggingen av et produkt. Og oppdatere historiene (eller legge til nye) kan skje når som helst. For agile-team fungerer produktkøen som en prioritert liste over funksjonaliteten som må utvikles. Det er her brukerhistoriene holdes til de blir jobbet på-typisk under utviklingspurter.

Krav kan også utformes når som helst. Det er imidlertid best å definere hva som er ønsket fra brukerens synspunkt først hvis både historier og kravdefinisjon er nødvendig. Jo lenger et team er med sin planlegging, jo mer teamet forstår brukeren og forretningsbehov. Så, definere harde krav for tidlig kan resultere i å måtte endre dem senere-eller bygge noe som ikke fullt levere kundens ønsket resultat.

selv om målet med en brukerhistorie eller krav er forskjellig, er målet alltid det samme-å bygge et produkt som kundene elsker.

enten du skriver en brukerhistorie eller et krav, må du fokusere på det som betyr mest: beskrive ønsket utfall for kunden og gi utvikling det de trenger for å bygge det vellykket.

jeg vet at det kan være forvirrende å bestemme hva jeg skal skrive. Så her er en enkel guide til å gjøre det valget.

hvis det du ber om å bygge har en direkte fordel for sluttbrukerne, skriv en brukerhistorie. Hvis det er mer sentralt i kjernen av et produkt eller infrastruktur, hoppe til definere krav.

Hvilke forskjeller vil du legge til i listen?

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert.