Techniki priorytetyzowania wymagań i funkcjonalności dla produktów cz.1

Jedne z głównych założeń manifestu Agile mówią, aby często dostarczać funkcjonujące oprogramowanie – w kilkutygodniowych lub kilkumiesięcznych odstępach. Im częściej, tym lepiej. Dodatkowo najwyższy priorytet ma dla nas zadowolenie klienta dzięki wczesnemu i ciągłemu wdrażaniu wartościowego oprogramowania.

Mimo, że sam Manifest powstał w środowisku programistycznym i bezpośrednio nawiązuje do pracy nad wytwarzaniem oprogramowania, jego przesłanie można rozpatrywać uniwersalnie. Potrzeba nadawania priorytetu zadań (funkcjonalności) wynika z bardzo prostego faktu: po prostu nie mamy wystarczających zasobów, by pracować nad wszystkim, co możemy sobie wyobrazić i co wymyśli pojedynczy klient.

Problem z nadawaniem zadaniom priorytetów ma wielu z nas i rodzi on szereg negatywnych konsekwencji. Złe planowanie, nie tylko powoduje brak realizacji tego co jest najważniejsze w odpowiednim terminie, ale też przesunięcia takiego zadania na bliżej nieznany nikomu termin.

Przyjmuje tutaj, że zadania oznaczają funkcjonalności, bo każde z nich będzie prowadziło do „ulepszenia” naszego produktu. Tak więc priorytetyzacja funkcjonalności dla danego produktu jest jednym z największych i najważniejszych problemów Menedżerów Produktu. To zdecydowanie jeden z najpopularniejszych tematów podejmowany wśród product managerów na konferencjach czy branżowych spotkaniach. Nawet najbardziej doświadczony menedżer produktów zmaga się z określeniem, które funkcjonalności i gdzie, powinny znaleźć się w roadmapie produktu, którą zarządza.

Priorytetyzacja jest kluczowa w naszej pracy, umożliwia nam bowiem osiągnięcie głównego celu: „stworzenia udanych produktów, które przynoszą wartość naszym klientom i przedsiębiorstwu”. W tym artykule przedstawiam kilka metod priorytetyzowania wymagań i funkcjonalności, które pomagają Product Managerom wybierać te, które mają największy wpływ na produkt, a wykluczać takie, które nie powinny się w ogóle w nim znaleźć. Jest to pierwsza część serii artykułów, w której podzielę się technikami priorytetyzacji wymagań i funkcjonalności dla produktu.

MODEL KANO

Zacznijmy od modelu KANO, który został już szczegółowo opisywany przez Damiana w tym artykule. Poniżej przypomnę jednak najważniejsze informacje na temat tej metody.

Model Kano został stworzony pod koniec XX wieku przez Noriaki Kano. Jest to zestaw pomysłów i technik, które są pomocne przy mierzeniu i analizie satysfakcji klientów.

Główne założenia modelu:

•  satysfakcja klienta z produktu zależy od ilości oraz jakości dostarczonych funkcji,
•  funkcje produktu są sklasyfikowane w 4 kategoriach

Funkcje fundamentale

Funkcje te są wymagane przez klientów. W przypadku gdy produkt nie będzie ich posiadał, zostanie określony jako niekompletny lub niezdatny do użytku. Implementacja tych funkcji nie spowoduje wysokiej satysfakcji u użytkowników.

Funkcje wydajności

Funkcje te nie są wymagane przez użytkowników natomiast ich brak powoduje obniżenie satysfakcji. Im więcej będzie ich dostarczonych tym większe zadowolenie zostanie osiągnięte i więcej klientów będzie chętnych aby kupić produkt.

Funkcje atrakcyjne

Funkcje te są zazwyczaj nieoczekiwane u użytkowników i powodują pozytywną reakcję. W związku z tym, że użytkownicy nie myślą o tych funkcjach, ich brak nie spowoduje obniżenia poziomu satysfakcji.

Funkcje obojętne

Ostatnią kategorią są funkcje, których wartość nie ma większego znaczenia na poziom satysfakcji klientów. Obecność lub brak nie stanowi większej różnicy (linia pozioma). Nie warto inwestować czasu na takie funkcje.

Przynależność funkcji do danej kategorii oceny można ustalić poprzez zadawanie odpowiednich pytań użytkownikom produktu,

Istnieje wiele ścieżek, które doprowadzą Cię do odpowiedniego priorytetyzowania funkcjonalności. Jedną z możliwości jest skorzystanie z kolejności (od lewej): funkcje fundamentalne -> wydajności -> atrakcyjne -> obojętne.

W przypadku nowego produktu liczba funkcji fundamentalnych będzie z całą pewnością przeważała nad resztą. W miarę rozwoju aplikacji rozwijane będą głównie funkcje wydajności. Nie możesz zapominać także o funkcjach atrakcyjnych z perspektywy użytkownika. To właśnie one powodują największy wzrost poziomu satysfakcji. Unikaj jednak funkcji obojętnych.

Więcej informacji na temat priorytetyzacji zadań w modelu KANO znajdziesz tutaj.

METODA MoSCoW

Metoda MoSCoW jest techniką priorytetyzacji wymagań stosowaną w wielu dziedzinach zarządzania, która pozwala osiągnąć porozumienie co do tego, co jest najważniejsze dla zainteresowanych stron biznesu (managerów, klientów, programistów, itp).

Termin ten jest akronimem każdej litery dotyczącej jednej z kategorii priorytetów.  Wymagania produktu są więc klasyfikowane jako:

• Musi mieć (Must have) – są krytyczne i muszą być zawarte w produkcie.
• Powinien mieć (Should have) – te wymagania są ważne, ale nie kluczowe dla wydania produktu. Są to funkcjonalności, które są pożądane przez użytkownika.
• Może mieć (Could have) – te wymagania są pożądane, ale nie konieczne dla produktu. Są to zazwyczaj dodatkowe opcje dla produktu ulepszenia produktu.
• Nie będzie mieć (Won’t have) – są uważane za najmniej krytyczne lub nawet niezgodne ze strategią produktu. Mają zostać zdecydowanie porzucone lub zostać ponownie rozpatrzone w przyszłych sprintach.

Priorytetyzacja wymagań dla gry metodą MoSCoW

Ta metoda oferuje szybkie i proste zdefiniowanie priorytetów. Problem polega na braku dodatkowej klasyfikacji w obrębie kategorii. Na przykład, w jaki sposób możemy wiedzieć, które wymagania SHOULD lub COULD są ważniejsze niż inne? Z tego powodu metoda MoSCoW lepiej nadaje się do projektów wewnętrznych zamiast produktów realizowanych przy współpracy z zewnętrznymi klientami.

MODEL SYSTEMICO

Patrząc na rozwój i tworzenie nowych produktów można zauważyć, że Product Managerowie często skupiają się na zarządzaniu kosztami wytworzenia produktu a nie nad wartością jaką może on przynieść użytkownikowi. Kiedy opisywana jest historyjka  – słyszymy najczęściej: “Jak długo zajmie” co w skrócie możemy określić jako: “Ile to będzie kosztować?”

Nie wolno zapominać, że rozwój oprogramowania jest procesem tworzenia wartości, a nie zarządzania jego kosztem. Tym samym celem naszego podejścia powinno być koncentrowanie się wokół tworzenia i realizowania wartości ważnych zwłaszcza z punktu widzenia użytkowników.

Aby wizualizować pojęcie “tworzenia wartości” jako systemu nastawiony na wymagania użytkownika, a nie szacowanie samych kosztów, został opracowany Model Systemico. Model ten ma na celu sprawdzenie, czy wymagania produktowe (pod względem priorytetów i wartości) są podobnie interpretowane przez zespół (product managera, designerów itp)  jak i przez użytkowników.

Model Systemico jest szczególnie użyteczny i ważny podczas pracy nad nowymi produktami, które aby zaistnieć powinny spełniać wymagania strategicznych klientów, w odpowiednich ramach czasowych.

Model Systemico związany jest z mapowaniem historyjek. Product Manager tworzy dwuwymiarową siatkę, która ułatwia wizualizację zakresu funkcjonalności produktu i różnych poziomów priorytetu.

Cele użytkownika – produkt jest zdefiniowany nie w kategoriach „Co robi”, ale w kategoriach „Dlaczego niektóre funkcje są konieczne”.

Zaangażowanie użytkowników – drugi wymiar wykorzystuje zaangażowanie użytkowników jako miarę poziomu interakcji między użytkownikiem, a produktem. Istnieją cztery stopnie opisujące funkcjonalności:

• Core: To Funkcjonalności, które zaspokajają podstawowe potrzeby użytkowników. Są to minimalne oczekiwane funkcje, które użytkownicy uważają za standardowe we wszystkich produktach w określonym kontekście, np. logowanie użytkownika.
• Use: To ulepszona funkcjonalność, która zwiększa użyteczność produktu. Bez tych cech produkt ma minimalne znaczenie dla użytkownika, np. wyświetlanie zawartości na stronie, funkcje edytowania.
• Engage: To funkcjonalności pociągające użytkownika do większej interakcji z produktem i zachęcające go do powrotu w przyszłości, np pozostawienia recenzji.
• Explore: To funkcjonalności, które zachęcają użytkownika do wykraczania poza proste interakcje. Funkcje te zwiększają siłę połączenia między użytkownikiem, a produktem, np. podejście indywidualne do użytkownika poprzez system nagradzania jego zaangażowania.

Historyjki użytkowników umieszczane są w różnych wymiarach tablicy, w zależności od celu i zaangażowania użytkownika w stosunku do tworzonego produktu.

W efekcie końcowym możliwe jest utworzenie planu wydania (wdrożenia), który zwiększa wartość produktu dla klienta w każdym wydaniu. Product Manager może podzielić wydania w zależności od priorytetu, który został oszacowany na podstawie historyjek od użytkowników.

Mapa historyjek, która powstaje na podstawie modelu Systemico jest niezwykle użyteczna i daje kompleksowy pogląd na funkcjonalności produktu. Pozwala przede wszystkim na odpowiednie umiejscowienie ich w roadmapie produktu.

Podsumowując, Model Systemico wizualizuje różne poziomy wpływu funkcjonalności produktu na zaangażowanie użytkowników oraz daje możliwość szczegółowego poznania wymagań użytkowników, co ułatwia zaplanowanie nowych wydań dla produktu.

METODA „KUP FUNKCJONALNOŚĆ” (BUY A FEATURE)

Kup funkcjonalność to innowacyjna gra, w którą można grać indywidualnie lub zespołowo.

Przed rozpoczęciem gry należy przygotować wymagania wobec produktu, które będą zapisane na kartach do gry, uwzględniając przy tym:

• funkcje sugerowane przez użytkowników,
• funkcje, które zostały wdrożone przez konkurencyjne rozwiązania,
• funkcje, które zostały odkryte podczas wewnętrznej analizy produktu,

Każda z kart do gry powinna zawierać nazwę funkcji, krótki opis przedstawiający na czym ona polega i jakie są główne korzyści wynikające z niej  dla użytkownika. Dla każdej karty konieczne będzie również przypisanie kosztów związanych ze złożonością funkcji  w celu wdrożenia do produktu.

Zasady gry w skrócie:

1. Funkcje prezentowane są w zespole, który może być złożony z klientów, programistów, designerów oraz inne osoby związane z tworzeniem produktu
2. Każdy gracz otrzymuje budżet na grę, aby móc wdrożyć funkcje.
3. Każda funkcja jest wyceniana przez organizatora gry przy konsultacji z zespołem (najczęściej jest nim Product Owner lub Product Manager) według pewnej miary kosztów (złożoność, rzeczywisty koszt opracowania itp.) – kryteria wyceny powinny być równe dla danej funkcji i ustalone wśród graczy wcześniej.
4. Budżet każdego gracza powinien wynosić od jednej trzeciej do połowy całkowitego kosztu wszystkich funkcji.

Możliwe jest granie w jeden z dwóch sposobów:

1. Indywidualnie – gracze są zobowiązani do korzystania wyłącznie z ich budżetu, aby kupić funkcje, które są dla nich najważniejsze.
2. Współpraca – ​​niektóre funkcje są zbyt drogie dla poszczególnych kupujących do zakupu. Wymaga to współpracy i negocjacji między graczami, aby kupić funkcje, które są oceniane przez wielu graczy.

Gdy gracze kupują funkcje należy zebrać od nich pieniądze i poprosić o wyjaśnienie, dlaczego zdecydowali się właśnie na tę, a nie inną oraz co dzięki niej zyskają.

Gra kończy się, gdy pieniądze się wyczerpują lub gdy gracze kupili wszystkie funkcje, które ich interesują. Zabawa nie powinna trwać dłużej niż 30 minut (przy większych grupach można trochę przedłużyć).

Aby uzyskać więcej danych, można grę podzielić na wiele faz (w grupach maksymalnie 6 – 8 osób). W przypadku dużej ilości funkcji, można skonfigurować mistrzostwa, w których popularne funkcje są przepuszczane przez kolejne fazy gier, aż do wyłonienia najważniejszych.

Gra pozwala wyznaczyć najważniejsze funkcjonalności dla produktu, które zostały wybrane przez zespół produktowy i stakeholderów (warto przemyśleć kto powinien w danej grze uczestniczyć). Możemy analizować, które funkcje zostały kupione najszybciej oraz jakie były przyczyny ich zakupu, co pozwoli na priorytetyzowanie wprowadzenia danych funkcjonalności do produktu.

PODSUMOWANIE

W artykule przedstawiłem pierwszą część technik priorytetyzowania wymagań i funkcjonalności dla produktów. Działania tego typu nigdy nie są łatwe dla Product Managera. Często wymagają bolesnych decyzji i trudnych kompromisów. Zwłaszcza w przypadku małych firm, w których czas, zasoby oraz przestrzeń do popełniania błędów są mocno ograniczone. Aby produkt osiągnął sukces, Product Manager musi postawić wyłącznie na funkcjonalności, które rzeczywiście mają znaczenie i będą miały maksymalny wpływ na być albo nie być produktu. Umiejętność priorytetyzowania wymagań czy funkcjonalności przez Product Managera jest w tym przypadku bardzo ważna.

Już wkrótce pojawi się kolejna część ukazująca metody priorytetyzacji. Trzymaj rękę na pulsie 😉