Wymagania biznesowe mogą być przygotowane przy pomocy różnych narzędzi - od user story, przez klasyczny use case aż po opis według własnej, samodzielnie wypracowanej metody. Forma nie jest tak bardzo istotna. Zdecydowanie ważniejsze jest, czy wymagania odzwierciedlają potrzebę biznesową zgłoszoną przez interesariuszy i czy realizacja wymagań tę potrzebę spełni. Za każdą potrzebą stoi jednak coś o wiele potężniejszego od niej samej. To wartość biznesowa. Czym ona jest? Jak ją zdefiniować i wytworzyć w projektach IT?
źródło fotki: Christine Hume / Unsplash
Lubię myśleć o swojej pracy pozytywnie, szukać w niej zadań twórczych i ciekawych. Wciąż niezmiennie twierdzę, że zadania Product Managera mogą być pasjonujące i nierzadko przypominają robotę Sherlocka Holmesa lub Angusa McGyvera. Bo przecież czasami wykonujemy robotę detektywa, szukając źródeł i celów projektu, odkrywamy ukryte komnaty pełne powiązanych ze sobą systemów i zależności między nimi, ale również walczymy z brakiem informacji i dokumentacji, w wyniku czego sklejamy wymagania jak rozdartą mapę, na rewersie której ktoś zamieścił zaszyfrowaną wiadomość. Jak na tej, nierzadko, niekompletnej mapie odnaleźć wartość biznesową?
Pozyskiwanie i definiowanie wymagań biznesowych i współpraca z zespołem deweloperskim nad ich realizacją wymagają wiedzy, doświadczenia, umiejętności analitycznych, twórczego myślenia i szerokich kompetencji miękkich. Nie dość, że trzeba kompletnie i w sposób zrozumiały zdefiniować, co i po co powinno być wytworzone, to jeszcze naszym zadaniem jest przekonanie ludzi do tego, że to wytwarzanie ma sens i przyniesie nam, firmie i użytkownikom konkretne korzyści.
Jak zdefiniować i wytworzyć wartość biznesową w IT?
Wartość biznesowa - brzmi fajnie, ale co to właściwie znaczy? Nachodzi mnie czasem myśl, że wielu z nas żongluje tym pojęciem, a niewielu zastanawia się, co się właściwie pod nim kryje.
Company business value jest określana przez PMBOK jako suma wszystkich wartości materialnych i niematerialnych w organizacji. Na poziomie firmy, wartość biznesowa będzie rozumiana jako aktywa pieniężne, kapitał udziałowców, sprzęty i narzędzia na wyposażeniu, a w aspekcie niematerialnym będą to wszystkie atrybuty marki - jej osobowość, rozpoznawalność, znaki szczególne (znaki towarowe) oraz jej rozumienie, postrzeganie i odbiór wśród odbiorców.
Pracując nad tą wartością warto mieć świadomość, że może być ona czymś subiektywnym, dynamicznym i zmiennym. Co nie znaczy, że nie można jej zmierzyć. Otóż można i trzeba. Kiedy następuje moment, w którym należy określić tę wartość i sposób jej mierzenia?
Pierwszym momentem definiowania business value organizacji jest moment określania jej strategii, misji i wizji. Wtedy właśnie następuje określenie celów strategicznych firmy, które z kolei wyznaczają kierunki jej rozwoju, zapewniają firmie wzrost, dobrostan i głęboko ją kształtują (od celów może zależeć dodatkowe zatrudnienie, pozyskanie specjalistów z nowymi kompetencjami lub podpisanie kontraktu z partnerem biznesowym). Cele powinny być zgodne z misją organizacji (czyli z wartościami, które firma chce chronić lub tworzyć) oraz z jej wizją (czyli z pożądanym obrazem firmy na rynku). Oczywiście, aby misja i cele zostały spełnione, potrzebne są inicjatywy podejmowane przez firmę - w firmie IT będą to różnego rodzaju projekty umieszczone w jej kwartalnym lub rocznym planie (Road Mapa).
Nakreśliłam tło kształtowania się wartości biznesowej po to, byście mogli jej szukać i ją odkryć w każdym projekcie, którego podejmujecie się, pracując nie tylko jako Product Manager, ale również jako UX, Designer, Project Manager czy Deweloper. Świadomość tego, że ona istnieje i powinna być znana w firmie i jej projektach, pomoże Wam odkryć, że czasami jej nie ma i że należy się jej domagać. Zupełnie serio - dla ludzi, którzy chcą spędzać czas w pracy z sensem, brak tej wartości może być problematyczny. Bo business value odpowiada nie tylko na pytanie co należy wytworzyć (jaką funkcjonalność), ale również na pytanie po co należy tę funkcjonalność wytworzyć.
Wartość biznesową można określić różnie dla organizacji, często jednak na wspólnej liście wartości wielu z nich będą pojawiać się takie, jak:
Revenue - dochód z prowadzonej działalności
Profitability - rentowność firmy, czyli w najprostszym ujęciu - stosunek efektów pracy do nakładów pracy
Market share - udział w rynku
Brand recognition - rozpoznawalność marki
Customer loyalty - lojalność użytkowników
Customer retention - jak długo użytkownicy korzystają z usługi i dokonują na styku z nią kolejnych pożądanych czynności (np. kolejnych zakupów w sklepie)
Customer satisfaction - satysfakcja użytkowników z usługi, mierzona np. w przebiegu badania NPS
Customer referral - jak wielu użytkowników usługi poleca ją innym użytkownikom
Jak działy produktu radzą sobie z określaniem wartości biznesowej w wymaganiach?
Podane wyżej wartości nie są jedynymi, które mogą pojawić się w projektach i wymaganiach biznesowych. Istnieje wiele innych, zależnych od typu organizacji, jej strategii, misji, a nawet trybu czy sposobu działania. Najtrudniejsza wydaje się być walka z perspektywą. Co mam tu na myśli? Otóż - nie każdy na co dzień myśli "o matko, moja firma ma takie a nie inne wartości biznesowe, to siądźmy i zapewnijmy je, projektując i kodując usługę w taki a nie inny sposób". Trudne jest przejście z bardzo szerokiego myślenia o organizacji do myślenia o projektach i o zadaniach w projekcie. Sama wiele lat miałam z tym problem, ja nie utonąć w zbyt szerokim myśleniu i skoncentrować się na tym, co i po co mam do zrobienia tu i teraz. I wiem, że część znajomych z branży ma ten... albo totalnie odwrotny problem, tj. jak pomyśleć szeroko i rozejrzeć się wokół, skoro tyle zadań w kolejce i wszystkie "na wczoraj"? Czy patrzysz szeroko, czy raczej koncentrujesz się na codziennych zmaganiach, i tak dopada Cię efekt perspektywy własnej.
W poszukiwaniu business value w wymaganiach biznesowych pomagają dwa modele określania metryk dla wartości biznesowej:
HEART - ten model pomaga mi w definiowaniu wartości biznesowej dla inicjatyw związanych z utrzymaniem i rozwojem produktu oraz z poprawą jego "używalności"
AARRR - tego modelu używam częściej dla wymagań związanych z inicjatywami sprzedażowymi i marketingowymi
Jednocześnie, uwaga! W IT nie jest możliwe zapewnianie wartości biznesowej, nie zapewniając technicznych wartości, takich jak wydajność usługi (performance), jej dostępność (accessibility), bezpieczeństwo (security) oraz użyteczność (usability).
Jak znaleźć wartość biznesową w wymaganiach?
Ha! Najpierw trzeba wiedzieć, że można i należy jej tam szukać. Product Manager, definiując wymaganie i jego wartość, może sięgnąć właśnie do modelu HEART lub AARRR. Spójrz, jakie mierniki się kryją w tych modelach:
H - Happiness
E - Engagement
A - Adoption
R - Retention
T - Task accomplished
A - Acquisition
A - Activation
R - Revenue
R - Retention
R - Referral
Szerzej te mierniki opiszę w kolejnym artykule, dzisiaj przećwiczę z Tobą przykład definiowania business value na prostym wymaganiu.
Wyobraźmy sobie właściciela portalu z zdjęciami do pobrania do komercyjnego użytku. Większość zdjęć jest płatna, a część można pobrać bezpłatnie. Właściciel widzi, że konwersja na poziomie rejestracji użytkowników do panelu, z poziomu którego można pobrać zdjęcia, jest niska - tylko 5% napływających do portalu użytkowników rejestruje się z sukcesem i wchodzi na stronę, na której system wyświetla zdjęcia i daje możliwość ich pobrania. Warto dodać, że rejestrowanie się następuje przez podanie adresu email i hasła oraz zaznaczenie zgód marketingowych. Opisywany system nie ma zbyt wielu funkcjonalności - użytkownicy mają możliwość pobrania zdjęć i zapłaty za nie za pomocą bramki płatniczej, mogą wyszukiwać zdjęcia za pomocą wyszukiwarki, oznaczać je jako ulubione i przeglądać rekomendowane przez system zdjęcia na podstawie wcześniejszych wyborów i wyszukiwań. Właściciel zastanawia się, za pomocą jakich wymagań podniesie konwersję na poziomie pozyskiwania nowych, rejestrujących się użytkowników.
Wartość biznesowa to oczywiście revenue, czyli dochód pozyskiwany ze ściągnięć płatnych zdjęć. Product Manager nie będzie w tym przypadku rozwiązywał problemu związanego z niskimi wskaźnikami na poziomie akwizycji (A - Aquisition) - tu wyniki są zadowalające, bo do portalu napływają użytkownicy. Nie będzie też zajmował się poprawą wyników na poziomie zaangażowania użytkowników (E - Engagement) ani ich retencją (R - Retention). Product Manager powinien poprawić adopcję podstawowej funkcjonalności (A - Adoption), czyli sprawić, że większy % napływających użytkowników zacznie z sukcesem rejestrować się do systemu. Bez wyższej adopcji nie ma wyższego zaangażowania (czyli częstszego wykonywania pożądanej czynności), nie mówiąc już o retencji (użytkownicy nie będą lojalni i nie będą powracać ani zwiększać wartości swoich koszyków, skoro nie przeszli przez bramę do systemu, czyli rejestrację).
W celu rozwiązania problemu w usłudze, możemy podjąć się kilku działań:
jeśli formularz rejestracji jest dobrze otagowany w GTM i zostały dla niego założone poprawnie zdefiniowane zdarzenia w Google Analytics (events), to z wyników w Google Analytics można wyczytać, na którym kroku czy polu formularza użytkownik porzuca proces rejestracji; jeśli wyniki w GA dostarczają informacji, że problemem jest konkretny krok lub pole formularza, należy poprawić formularz
jeśli liczba użytkowników, która kończy wypełnianie formularza z sukcesem jest zbliżona do liczby użytkowników rozpoczynających ten proces, to nie formularz jest problemem; kolejny krok naszej detektywistycznej zabawy z GA, to zbadanie, dlaczego tylko 5% użytkowników w ogóle zaczyna wypełniać formularz - być może jest on mało widoczny? może brakuje kluczowej informacji, na jakich zasadach następuje rejestracja? może potrzebne jest zapewnienie, że sama rejestracja jest bezpłatna?
warto również zbadać demografię użytkowników i dowiedzieć się o nich nieco więcej - jeśli usługę kierujemy do młodych ludzi z dużych miast, a w wyniku działań akwizycyjnych przychodzą do nas starsi ludzie z małych miejscowości i wsi, to należy poprawić targetowanie kampanii marketingowych
jeśli targetowanie okaże się trafione i skuteczne i formularz jest również ok, to... należy znów pomyśleć o użytkownikach i ich potrzebach i przyjrzeć się założeniom biznesowym i funkcjonalnym produktu - rejestracja następuje poprzez podanie adresu email i hasła, prawda? Czy to nie są zbyt ubogie możliwości? Stawiałabym, że tak! jeśli użytkownikami są ludzie, którzy pobierają płatne zdjęcia, to z pewnością będą to osoby zajmujące się marketingiem, właściciele małych przedsiębiorstw, graficy i wszelkie inne postaci wykonujący pracę twórczą. Te osoby z pewnością mają konta social mediowe w usługach Facebook, Linkedin, Instagram i innych cudach do udostępniania treści i zasilania marki w nowych followersów i fanów. Oni z pewnością chcieliby się rejestrować w sposób szybki i prosty, używając danych dostępowych swoich kont social mediowych, zamiast tworzyć nowe.
Jeśli jako Product Manager zdecyduję się na poszerzenie funkcjonalności o nowe formy rejestracji, to w moim wymaganiu powinny znaleźć się zapisy:
Business value:
zapewnienie wyższego revenue z usługi (dochód z płatnych zdjęć udostępnionych w systemie)
Cele biznesowe (why):
poprawa adopcji systemu przez użytkowników - zwiększenie stosunku napływających użytkowników do tych, co zakończą z sukcesem proces rejestracji, gdzie punkt odbicia to 5% konwersji
Kryteria akceptacji (what):
użytkownik ma możliwość zarejestrowania się do systemu za pomocą swoich danych dostępowych do kont social media - Facebook, Linkedin, Instagram
Oczywiście, wymaganie powinno być dużo szersze (zawierać chociażby info o wyjątkach i ścieżkach alternatywnych użytkownika) i powinno spełniać kryteria SMART, ale to tekst o poszukiwaniu i definiowaniu wartości biznesowej, a nie o tym, jak pisać wymagania. Dlatego, pokuszę się o podsumowanie tekstu jednym zdaniem:
Dostarczanie wartości biznesowej to dodawanie użytkownikom tego, po co przyszli, w zgodności i wsparciem dla wartości biznesowej organizacji i zgodnie z jej biznesowymi celami.
Chcesz poszerzyć wiedzę z dziedziny Product Management?
Napisz do mnie na adres info@everydayrocket.com lub subskrybuj nasz newsletter! :)
Przeczytaj również:
Autor:
Marta Steiner
Comments