styczeń 23, 2018
autor: Ron Yang

historie. Masz ich setki, jeśli jesteś menedżerem produktu. Każdy z nich opisuje niesamowite doświadczenia, które chcesz, aby Twoi klienci mieli podczas korzystania z twojego produktu. I jak każdy dobry gawędziarz, potrzebujesz, aby twoje historie były jasne i wpływowe.

wszyscy najlepsi menedżerowie produktów, których znam, są odpowiedzialni za dzielenie się tym, czego naprawdę chcą klienci, poprzez historie użytkowników.

ale tu jest, gdy bycie product managerem to ciężka praca. Czasami oczekuje się, że zdefiniujesz wymagania dotyczące tego, co Twoje zespoły programistyczne muszą zbudować — bez podawania „dlaczego” z perspektywy użytkownika.

chociaż większość nowych funkcji powinna być zdefiniowana z perspektywy użytkownika, nie zawsze jest to wykonalne, a nawet pomocne. Weźmy na przykład pod uwagę funkcje zabezpieczeń lub wymagania infrastrukturalne, z którymi nie zawsze borykają się klienci.

więc powstaje pytanie: Kiedy używasz tych różnych naczyń? Zanim na to odpowiesz, musisz zrozumieć, co je wyróżnia.

istnieje jedno główne rozróżnienie między historiami użytkowników a wymaganiami: cel.

Historia użytkownika koncentruje się na doświadczeniu — tym, co osoba korzystająca z produktu chce być w stanie zrobić. Tradycyjny wymóg koncentruje się na funkcjonalności – co produkt powinien zrobić. Pozostałe różnice to subtelna, ale ważna lista „jak”, „kto” i „kiedy”.”

oto jak różnią się historie użytkowników i wymagania:

Jak to jest napisane?

historie użytkowników powinny być napisane w jednym lub dwóch zdaniach i uchwycić, kim jest użytkownik, czego chce i dlaczego. Prosta struktura definiowania funkcji lub user stories może wyglądać mniej więcej tak: jako ____, chcę osiągnąć____, aby zrealizować następującą korzyść z____.

przykład: jako użytkownik chcę być w stanie zresetować hasło, aby móc wrócić do systemu, jeśli go zapomnę.

wymagania są zazwyczaj bardzo szczegółowe i zajmują więcej czasu na napisanie. Często są one szczegółowo (czasami wysoce techniczne) na temat tego, jak oprogramowanie powinno działać. Te szczegóły następnie kierują zespołem programistów, w jaki sposób zbudować nową funkcję lub funkcjonalność.

przykład: użytkownik może zresetować hasło po otrzymaniu wiadomości e-mail z resetowaniem hasła. E-mail powinien zawierać unikalny link do zresetowania hasła i ten link powinien wygasnąć po dwóch godzinach.

kto to pisze?

historie użytkowników mogą być pisane przez prawie każdego, kto jest blisko programistów, którzy zgłaszają problemy, testera QA, który odkrywa wadę w UX — o ile reprezentuje perspektywę użytkownika końcowego. Ale to menedżer produktu lub właściciel utrzymuje zaległości w historiach użytkowników.

wymagania są pisane przez menedżera produktu, Właściciela Produktu lub analityka biznesowego. Przewody techniczne są często zaangażowane, jak również inżynierów, którzy będą odpowiedzialni za pracę nad funkcjami lub ulepszeniami.

kiedy są pisane?

historie użytkowników są pisane w całym budynku produktu. Aktualizowanie historii (lub dodawanie nowych) może nastąpić w dowolnym momencie. W przypadku zespołów zwinnych lista zaległości produktowych służy jako lista priorytetów funkcji, które należy opracować. W tym miejscu historie użytkowników są przechowywane do czasu ich opracowania — zazwyczaj podczas sprintów programistycznych.

wymagania można również opracować w dowolnym momencie. Jednak najlepiej jest najpierw zdefiniować, co jest pożądane z punktu widzenia użytkownika, jeśli wymagane są zarówno historie, jak i definicja wymagań. Im dalej zespół zajmuje się planowaniem, tym bardziej rozumie potrzeby użytkowników i biznesu. Tak więc zbyt wczesne zdefiniowanie trudnych wymagań może skutkować koniecznością ich późniejszej zmiany-lub zbudowaniem czegoś, co nie przyniesie w pełni pożądanego rezultatu klientowi.

chociaż cel historii użytkownika lub wymagania różnią się, cel jest zawsze ten sam — budowanie produktu, który klienci kochają.

niezależnie od tego, czy piszesz historię użytkownika, czy wymagania, musisz skupić się na tym, co najważniejsze: opisaniu pożądanego rezultatu dla klienta i zapewnieniu rozwoju tego, czego potrzebuje, aby go pomyślnie zbudować.

wiem, że to może być mylące zdecydować, co napisać. Oto prosty przewodnik po dokonaniu tego wyboru.

jeśli to, co chcesz zbudować, ma bezpośrednie korzyści dla użytkowników końcowych, napisz historię użytkownika. Jeśli jest bardziej centralny dla rdzenia produktu lub infrastruktury, przejdź do definiowania wymagań.

jakie różnice dodałbyś do listy?

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany.