user story

Historyjka, user story bądź feature – określeń i sposobów prezentacji nowych funkcjonalności produktu jest zdecydowanie więcej. Z punktu widzenia programisty jest to najczęsciej “robota do zrobienia”. Z punktu widzenia Product Managera bardzo istotny element rozwijanego produktu. Jednak czy każda z nich powinna pojawić się w jego nowej wersji? Czy warto poświęcać dwa tygodnie pracy zespołu na wdrożenie czegoś, co de facto jest zbędne? Jak oddzielić ziarno od plew? Poniżej 5 najważniejszych przyczyn przez które nowa funkcja nie powinna zostać wdrożona.

1. Kiedy użytkownik jej nie potrzebuje

Kluczowym elementem produktowej układanki jest użytkownik. Bez względu na to czy jest to pracownik innego działu tej samej firmy, zewnętrzny kontrahent czy nastolatek po drugiej stronie globu. Zamiast spędzać czas na formułowaniu kolejnych, bardzo często błędnych hipotez znajdź i poznaj rzeczywiste potrzeby użytkownika. Kawa i pięć minut rozmowy na korytarzu może dać więcej niż wielogodzine sesje z papierem i długopisem.

2. Kiedy nie wpisuje się w wizję rozwoju

Kiedy nowa funkcjonalność nie wpisuje sie w wizję zespołu odpowiedzialnego za zarządzanie produktem. Zrezygnowanie z nowego elementu kosztem czyjegoś “wyobrażenia” produktu należy do jednych z trudniejszych decyzji, które nierzadko spotykają się ze sprzeciwem innych, a co gorsze nie pozwalają na przyszłą weryfikację ich słuszności.

3. Kiedy nie przełoży się na wzrost

Bez względu czy jest to gruntowna zmiana układu interfejsu użytkownika czy przepisanie drobnego fragmentu kodu po stronie serwera. Jeżeli refaktoryzacja kodu przełoży się na przyśpieszenie działania produktu, a to zachęci użytkownika do częstszego bądź dłuższego korzystania z produktu warto to rozważyć, w przeciwnym razie lepiej skupić się na czymś innym.

4. Kiedy nie umiemy czegoś wystarczająco dobrze

Rozwiązanie w technologii, w której żaden członek zespołu nie ma doświadczenia? Wdrożenie systemu zarządzania treścią kiedy do tej pory sami nie korzystaliśmy z żadnego? To przykłady kiedy w głowie każdego Product Managera powinna zapalić się lampka kontrolna. Nie oznacza to, że nie powinniśmy się podejmować nowych wyzwań. Przed rozpoczęciem pracy nad funkcjonalnościami, które znajdują się w zupełnie nowych obszarach warto rozważyć wydzielenie zadań, których celem będzie przestudiowanie i lepsze zrozumienie danego zagadnienia.

➔ Product Management Academy (8.10 - 26.11) ✨ - 7-tygodniowy program warsztatów z product managementu

5. Kiedy wysiłek jest większy niż nagroda

Każda nowa funkcjonalność charakteryzuje się innym stopniem trudności oraz w innym stopniu wpływa na postrzeganie produktu. Istotnym element pracy Product Managera jest analiza kosztowo-korzyściowa, która w uproszczeniu polega na znalezieniu odpowiedzi na dwa pytania:

  • Jak użyteczna z punktu widzenia użytkownika jest nowa funkcjonalność?
  • Ile czasu zajmie jej wdrożenie?

Analizując poniższy wykres każdemu powinno zależeć na dostarczaniu prostych rozwiązań dających w zamian duży zysk. Jest to prawda, jednak jednocześnie należy pamiętać o tym, że część kluczowych funkcjonalności produktu na pewno okaże się czasochłonnych, a nagroda nie będzie wystarczająco zadowalająca.

Kiedy nie wdrażać nowej funkcji produktu?
Źródło: Intercom on Product Management, 2015 Intercom Inc.

Kiedy jeszcze?

Z pewnością nie są to wszystkie scenariusze, kiedy należy przynajmniej dwukrotnie zastanowić się przed wdrażaniem nowej funkcjonalności, jednak według mnie jedne z bardziej istotnych. Jeżeli chcesz dowiedzieć się jeszcze więcej o “zarządzaniu” funkcjonalnościami zapraszam do lektury darmowej książki Intercom on Product Management.[sc:newsletter_scrum ]

➔ Product Management Academy (8.10 - 26.11) ✨ - 7-tygodniowy program warsztatów z product managementu

Dołącz do naszych czytelników

Dołącz do 7 000+ subskrybentów otrzymujących nasz newsletter z inspiracjami do tworzenia coraz lepszych produktów i rozwoju swojej kariery.
Od najmłodszych lat związany z Internetem. Doświadczony programista aplikacji internetowych zarówno po stronie serwera jak i klienta. Na co dzień pracuję wykorzystując praktyki Agile - ciągłą integrację, regularny refaktoring oraz przegląd kodu. Po pracy czytam o i eksperymentuje z nowymi technologiami.

ZOSTAW ODPOWIEDŹ

Proszę wpisać swój komentarz!
Proszę podać swoje imię tutaj

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.